Wandering Thoughts archives

How we disable accounts here (and why)

In my opinion, the hardest part of disabling accounts is deciding what 'disabled' means, which can be surprisingly complex. These days, most of the time we're disabling an account as a prelude to removing it entirely, which means that the real purpose of disabling the account is to smoke out anything that would cause people to not want the account to be deleted after all. Thus our goal is to make it look as much as possible as if the account has been deleted without actually deleting anything.

These days, what this means is:

• scrambling their password, so they cannot log in to our Unix systems, access their files through our Samba servers, read their email via IMAP, and so on. If necessary, this gets 'reverted' through our usual password reset process for people who have eg forgotten their password.

  (Given that Samba has its own password store, it's important for us to actively use passwd to scramble the password instead of just editing /etc/shadow to lock or disable it (cf).)

• making the user's home directory and web pages completely inaccessible (we 'chmod 000' both directories). This blocks other people's access to files that would be (or will be) deleted when the account gets deleted. Explicitly removing access to the account's web pages has been important in practice because people sometimes forget or miss that deleting an account deletes its web pages too.

  (I believe this will stop passwordless SSH access through things like authorized keys, but I should actually test that.)

• making the user not exist as far as the mail system is concerned, which stops both email to them and email through any local mailing lists they may have.

  (This automatically happens when someone's home directory is mode 000, and automatically gets reverted if their home directory becomes accessible again.)

• entirely removing their VPN credentials and DHCP registrations. Both of these can be restored through our self-service systems, so there's no reason to somehow lock them instead.

• find and comment out any crontab entries, and stop any user-run web servers they have. All of this should normally stop anyways because of mode 000 home directories, but better safe than sorry.

• set their Unix shell to a special shell that theoretically prints a message about the situation. We use this more as a convenient marker of disabled accounts than anything else; the scrambled password means that the user can't see the message even if they actually tried to log in to our Unix systems (which they may not really do these days).

We don't try to find and block access to any files owned by the user outside of their home directory, because we don't normally remove such files when we do delete the account (which is one reason we need filesystem scans to find unowned files).

If we're disabling an account for some other reason, such as a security compromise, we generally skip making the user's files inaccessible. This also keeps email flowing to them and their mailing lists. In this case we generally specifically disable any SSH authorized keys and so on.

Sidebar: Keeping web pages without the rest of the account

This is actually something that people ask for. Our current approach is to leave the Unix login there, scramble the password and so on, and empty out the user's regular home directory and set it to mode 000 (to block email). This leaves the web pages behind and keeps the actual ownership and login for them (which is important because we still use Apache's UserDir stuff for people's web pages).

We haven't yet had a request to keep web pages for someone with CGIs or a user-run web server, so I don't know how we'd deal with that.