diff --git a/howto/retire-a-user.md b/howto/retire-a-user.md
index 5972fac11ad6f6f5d27111a3ea9d643f290ca2cf..154bec8fb09668b1cdf19e45f1297689a79205d2 100644
--- a/howto/retire-a-user.md
+++ b/howto/retire-a-user.md
@@ -5,60 +5,96 @@
 
  * "disabled", which immediately disables everything
 
+At least, that's in theory: in practice, the userdir-ldap code seems
+to just immediately disable a user when we "lock" it, so that
+distinction doesn't actually exist and it is unclear where the above
+actually is coming from.
+
 # How to retire a user
 
-This is done by "locking" the account in [howto/ldap](howto/ldap), so it should simply
-be:
+Typically, the first step in retiring a user is to "lock" their user
+account, which keeps them from logging in. But the user still lives in
+the LDAP database, and it might be better to delete it completely. The
+user also needs to be checked against all other services that might
+have their own account database.
+
+## Locking an account
+
+So the first step is to lock the account (as in [howto/ldap](howto/ldap)):
 
     ssh db.torproject.org ud-lock account
 
+A ticket number can be provided with `-r` and another state (than
+"retired") can be specified with `-s`, for example:
+
+    ud-lock -r tpo/tpa/team#666 -s inactive account
+
+Note that this only keeps the user from accessing servers, it does
+*not* remove the actual account from LDAP nor does it remove it from
+the `passwd` database on servers. This is because the user might still
+own files and we do not want to have files un-owned.
+
 Note that it's unclear if we should add an email alias in the
 `virtual` file when the account expires, see [ticket #32558](https://bugs.torproject.org/32558) for
 details.
 
-# How to un-retire a user
+## Deleting an account
 
-To reverse the above, you need to restore those LDAP fields the way
-they were before. You can only do this by restoring from the [howto/LDAP](howto/LDAP)
-database. No, that is not fun at all. Be careful to avoid duplicate
-fields when you re-add them in ldapvi.
+You may also want to delete the user if it's clear they are unlikely
+to come back again. For this, the actual LDAP entries for the user
+must be removed with `ldapvi`, but only after the files for that user
+have been destroyed or given to another user.
 
-If the user was just "locked", you might be able to re-enable it by
-doing the following:
+## Retiring from other services
 
- * delete the `accountStatus`, `shadowExpire` fields
- * add the `keyFingerprint` field matching the (trusted) fingerprint
- * change the user's password to something that is not locked
-
-To set a password, you need to find a way to generate a salted UNIX
-hashed password, and there are many ways to do that, but if you have a
-copy of the userdir-ldap source code lying around, this could just do
-it:
+Then you need to go through the [service list](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service) and pay close
+attention to the services that have "authentication" enabled in the
+list.
 
-    >>> from userdir_ldap import HashPass, GenPass
-    >>> print("{crypt}" + HashPass(GenPass()))
+In particular, you will want to:
 
-# How to disable a user
+ 1. Login as admin to [GitLab](howto/gitlab), [disable](https://docs.gitlab.com/ee/user/admin_area/moderate_users.html#deactivate-a-user) the user account, and
+    remove them from critical groups. another option is to [block](https://docs.gitlab.com/ee/user/admin_area/moderate_users.html#block-a-user)
+    or [ban](https://docs.gitlab.com/ee/user/admin_area/moderate_users.html#ban-and-unban-users) a user as well.
+ 2. Remove the user from aliases in the virtual alias map
+    (`modules/postfix/files/virtual` in `tor-puppet.git`)
+ 3. remove the user from [mailing lists](service/lists), on eugeni:
 
-This is done by removing all traces of the account:
+        sudo remove_members <list names> <email address>
 
- 1. Login to alberti.torproject.org and lock the LDAP account using `ud-info -u`
- 2. Login as admin to gitlab.torproject.org and disable the user account.
- 3. Login to eugeni.torproject.org.
-    - edit `/etc/postfix/virtual` and remove the account alias.
-    - run `sudo postmap virtual` to rebuild the virtual users table.
-    - run `sudo remove_members <list names> <email address>`
- 4. make sure they don't have keys and accounts in Puppet
+ 4. grep for the username in `tor-puppet.git`, typically you may find
+    a sudo entry
  5. remove the key from `acccount-keyring.git`
 
 There are other manual accounts that are *not* handled by LDAP. Make
 sure you check:
 
- * Nextcloud
- * Trac
- * Gitolite
- * Gitlab - remove the user from the config, as a cleanup (disabled
-   users already do not have access to gitolite)
+ * [Nextcloud](service/nextcloud)
+ * [Gitolite](howto/git)
 
 TODO: list is incomplete, need to audit [the service list](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service) and see
 which services are in LDAP and which aren't. See [ticket #32519](https://bugs.torproject.org/32519).
+
+# How to un-retire a user
+
+To reverse the above, if the user was just "locked", you might be able
+to re-enable it by doing the following:
+
+ * delete the `accountStatus`, `shadowExpire` fields
+ * add the `keyFingerprint` field matching the (trusted) fingerprint
+   (from `account-keyring.git`)
+ * change the user's password to something that is not locked
+
+To set a password, you need to find a way to generate a salted UNIX
+hashed password, and there are many ways to do that, but if you have a
+copy of the userdir-ldap source code lying around, this could just do
+it:
+
+    >>> from userdir_ldap import HashPass, GenPass
+    >>> print("{crypt}" + HashPass(GenPass()))
+
+If the user was completely deleted from the LDAP database, you need to
+restore those LDAP fields the way they were before. You can do this by
+either restoring from the [howto/LDAP](howto/LDAP) database (no, that is not
+fun at all -- be careful to avoid duplicate fields when you re-add
+them in `ldapvi`)  OR just [create a new user](howto/create-a-new-user).