Disabling an account can be kind of complex
Question 31 on Tom Limoncelli's sysadmin test is:
G.31: Can a user's account be disabled on all systems in 1 hour?
This may be more complex than you think. I'll use our local environment as an illustration.
We have a central password distribution system.
It'd take me about thirty seconds to edit the master
in order to lock someone's password in it (and then a couple of
minutes for this to get propagated around). Some people would
confidently stop here, and for many situations and many users it's
actually good enough.
(I know that there's some Linux command that will lock the password for
me, but it would honestly take me longer to figure out what it was and
look up the option I need than it does to edit
But if a user has some form of passwordless ssh set up, they can still log in even with a locked password. So I'd better remember to set the user's shell to an administrative shell that just prints a 'this account is suspended' message. (Do you have such a shell ready to go?)
But wait. Samba doesn't use the Unix password file; it has its own
password file and we have magic set up to update the Samba password
store at the same time as we update the normal Unix passwords. Simply
editing the Unix
/etc/shadow does nothing at all to the Samba password
file, so a user with a locked password could still get access through
Samba (some of our users might not even notice that they couldn't log
in to our Unix machines). The simplest fix for this is to not lock the
user's password in
/etc/shadow but to use
passwd to scramble it to a
random value so that the Samba password store is updated too.
However, this isn't good enough, since there are a number of ways for
users to run commands without actually logging in. Leaving these intact
probably doesn't count as really disabling the account, especially if
you're concerned that the user might be malicious and so might have
left themselves back doors. In our environment, a user could have a
crontab file or at jobs on any number of machines, they could have a
pipe to a command in their
.forward (or in a simple mailing list that they own), and they could even have
CGIs on our web server (or worse, an entire user-managed web server). They might also have running processes on
any number of our machines. To fix this I'd have to check every machine
and decommission or kill anything that I found.
After all of this, I've managed to thoroughly disable a user's account on our Unix systems. But users have additional access in our environment in several ways, and if we're being thorough I need to get rid of them as well. First off, users may have VPN accounts; these are completely separate from their regular Unix account (with a different password). A disabled user should probably lose VPN access, so I'd better remember to edit that password file too.
Next, users may have registered specific machines on our general access network for laptops and other user-run machines. We probably don't want a disabled user to be able to get any network access through our networks, so I'd have to look up all of their machines in the DHCP database and remove or disable the entries.
(Can you find all of the machines registered to a user and remove their access? What about your wireless environment; how much access does the user have by still knowing your SSID and WEP or WPA wireless key?)
I could probably do all of this in an hour (ignoring delays in how long some things take to propagate around). But I'd certainly want to think about it carefully to make sure that I wasn't missing something in the corner, and if I was doing this in a hurry and under pressure I'd probably have missed something.
(Reversibly suspending an account is harder, assuming that you need to
be this thorough. Deleting an account entirely instead of just disabling
it is probably easier, because you don't have to worry about a lot of
these things if you remove the user's
/etc/passwd entry and delete
It's also worth noting that the idea of 'disabling' an account is imprecise. For example, should a disabled account still be able to receive email, or should we start bouncing email to it (and if so, should we use a special error message)? Should a disabled account's personal web page still be visible? The answers may depend on just why an account is being disabled and in any case these are policy issues, not technical ones.
(However, they interact with the technical issues. If a disabled account
should continue to receive email, what do you do if the account's normal
mail handling involves a piped program in the user's