Linux Server Hacks, Volume Two

Hack #1. Disable User Accounts Instantly

In a crisis, here's how to quickly disable a user account, using only a text editor.

Sooner or later every system administrator gets the call to disable a user's account. Regardless of whether this is due to termination or for general security reasons, you have to move quickly to satisfy the Human Resources department or layer of management that's on the other end of the line. If you're used to graphical tools for user management, this can take a little while, but luckily there's a quick and easy solution to this request that just involves a text editor.

Disabling Accounts on Systems That Use Local Authentication

On older Unix systems passwords were stored in the /etc/password file, but they were moved to the /etc/shadow file (which is readable only by the root user) on more recent systems to prevent non-root users from having access to the encrypted form of a user's password, for security reasons. Most Linux systems that use local authentication store passwords in the /etc/shadow file, though some still use /etc/passwd as an artifact or for compliance with aging applications. If the second colon-separated field in each entry in /etc/passwd contains an x, your system is using the /etc/shadow file to hold password information. If you see other characters between the first and second colons, your system is still storing its password information in the /etc/passwd file.

To quickly disable accounts on a Linux file server or on a user's desktop machine, bring up /etc/shadow in a text editor and insert an asterisk (*) as the first character in the second field of the file (after the first colon), which is where the password is stored. This prevents subsequent logins but leaves the existing password intact. If circumstances reverse themselves and you're asked to re-enable the user's account, you can simply remove the asterisk to re-enable logins with the existing password. This is similar to the approach taken by the usermod -L user command, which inserts an exclamation mark (!) at the beginning of a user's password entry to lock out that user. Actually, if your system provides the usermod command, you can just as easily use this command to disable an account, as long as /usr/sbin is in your PATH—it's good to know how the command really works, though.

You never want to remove a user's data until it has been safely backed up, so userdel -r user is the wrong command to use when you simply need to lock out a user. Removing an existing user account with the userdel command also often leaves you open to reusing the old user ID (UID) the next time you create an account, which should be against IT policy for security and privacy reasons.

Reusing UIDs is a bad idea because if a new account is created with a UID that previously existed on your system, the new user will own any files still on the system that were owned by the previous user. This most commonly occurs with email stored in system directories outside the user's home directory, but such files can exist anywhere the previous user had write privileges. This can also cause a problem if files or directories owned by the previous user are restored from backups for some reason. Adopting a policy of not reusing UIDs prevents users from "accidentally" getting rights to files to which they shouldn't really have access.

Tip

When disabling a user's account, don't forget to change or disable the login passwords for other accounts that the user may know.

Disabling Accounts on Systems That Use Distributed Authentication

If your site uses a distributed authentication mechanism such as LDAP (the Lightweight Directory Access protocol) or NIS (the Network Information Service, originally designed by Sun Microsystems for use with the Network File System), quickly disabling an account is slightly more difficult, but it's even more important that you be able to do so. If you are using distributed authentication, until the account is disabled, a user has access to all the machines at your site that share this authentication mechanism.

Systems that use NIS for authentication rely on centralized password and shadow files that are distributed to NIS clients by an NIS server. Many NIS systems store password information directly in the NIS password file (/var/yp/ypetc/passwd), because using NIS to share shadow password files (/var/yp/ypetc/shadow) largely defeats the security implied by the shadow file. On systems using local authentication, only the root user can read the /etc/shadow file—but on NIS systems, any user who can listen to the NIS server can see the shadow file.

To quickly disable a user's account on systems that use NIS, you can directly edit the NIS master of the password or shadow file in exactly the same way that you edited the local copy in the previous section of this hack, putting an asterisk in front of the password entry for the specified user. The NIS masters of these files are stored in the directory /var/yp/ypetc on your NIS server. If the second colon-separated field in each entry in /var/yp/ypetc/passwd contains an x, your system is using the /var/yp/ypetc/shadow file to store password information. If you see other characters between the first and second colons, your system is still storing password information in /var/yp/ypetc/passwd.

Once you've modified the /var/yp/ypetc/passwd or /var/yp/ypetc/shadow file, you must push it to all NIS clients by changing directory to the /var/yp directory and using the make command:

	# cd /var/yp;make

You can, of course, always change an NIS user's password by executing the yppasswd user command, but if you need to re-enable the account you will have to work with the user to reset the password.

LDAP is a much more powerful distributed technology than NIS, because it provides a central source from which many different applications can retrieve many different types of information. As discussed in "Centralize Logins with LDAP" [Hack #6] , LDAP information directories, also known as databases, provide a great solution for a central, enterprise-wide source for login, password, and other per-user account information. However, because sites that use LDAP for authentication do not use the standard password or shadow files to hold password information, you can only disable LDAP accounts by changing the information in the LDAP database. You can disable a user account either by changing information about a specific account record (known as "attributes") in the database, by changing the access control list (ACL) on the information about the account so that the user no longer has access to it, or by directly changing the user's password in the database.

Unless you are completely familiar with the schemas used in your LDAP database, disabling an account by changing its password is the fastest and easiest method. This doesn't require that you remember every characteristic of your LDAP user/account scheme, and it can be done using the ldappasswd command. To change a user's password when you are using LDAP authentication, become the root user, run this command, and supply a new password when prompted to do so:

	# ldappasswd–l user