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 /etc/shadow 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 /etc/shadow directly.)

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 their files.)

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 .forward?)