"Linux Gazette...making Linux just a little more fun!"

The Answer Guy


By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, http://www.starshine.org/

(?)SysAdmin: User Administration: Disabling Accounts

From Glenn Jonsson on 05 Aug 1998

Answerguy,

I'm doing a course on unix administration, unfortunatly i don't recall being taught to disable a user, I was hoping you would be able to tell me how to do this?

Thanks
Glenn

(!)I suppose you could disable a user by taking a sledgehammer or other LART to his or her kneecaps (least gruesome among many means that come to mind). However, I presume the intended question at hand was:
"How does a Unix/Linux sysadmin disable a user's account?"
Now, I should preface this answer with a bit of a flame (more of a spark, really): This is not the "do-your-homework" line. When you get an assigment as part of your coursework you've either been presented with the information needed to answer the question --- or you're expected to know where to find that information (how to do the research).
So, before I answer this question let me answer the meta-question:
"How does a sysadmin find out how to perform routine user and group management operations on his systems?"
One way is to look for commands that relate the operation, to find out what might be 'apropos' --- so we issue the 'apropos' command (or 'man -k' --- keyword search command).
Since this relates to a user's account let's try:
man -k account
On my system that gives me two commands: 
userdel (8)          - Delete a user account and related files
usermod (8)          - Modify a user account
These and many others will show up when we issue:
man -k users
... and 'man -k login' will give us just about the right number of other alternatives.
However, 'usermod' sounds promising. Looking at the man page for usermod and searching on the word "disable" leads be to the following paragraph: 
-f inactive_days
The  number  of days after a password expires until
the account is permanently disabled.  A value of  0
disables  the  account  as soon as the password has
expired, and a value of -1  disables  the  feature.
The default value is -1.
... so that's one way to do it. If we near the end of the man pages we'll often find a "SEE ALSO" section which will point us to related man pages. So we look at passwd(1) (the section/chapter 1 command 'passwd') and search on disable and find: 
Account maintenance
User  accounts  may be locked and unlocked with the -l and
-u flags.  The -l option disables an account  by  changing
the   password  to  a  value  which  matches  no  possible
encrypted value.  The -u option re-enables an  account  by
changing the password back to its previous value.
... so that's method number two.
This note about "changing the password to a value which matches no...." sounds in intriquing. Technically it is using the wrong terminology since passwords in the /etc/passwd file are technically not "encrypted" --- they are "hashed" using a cryptographically strong algorithm (DES by default, MD5 or others on some systems). The distinction is lost on most writers and it is a bit longer to explain --- but the way that DES hashing of a password under Unix works is that the password and a "salt" (a random 12 bit value) are used as a "key" to "encrypt" a string of ASCII NUL's using the DES (data encryption standard --- a 20 year old U.S. mandated encryption system derived from IBM's "Lucifer" research). The result value is expressed as a subset of the printable characters with the "salt" prepended to it.
(The "salt" exists simply to make "dictionary attacks" more expensive --- computationally and in terms of storage. It means that the "crack-er" has to have about 4000 different hashes for every word in his or her 'crack' dictionary).
One of the properties of DES that made it attractive for commercial deployment is that that it is highly resistant to "known plaintext attacks." That means that it was computationally infeasible to recover the key even if one had arbitrary samples of the plain text (our string of NUL characters in this case) and the crypt text (the hashed form of the password from the /etc/passwd file).
There are two reasons why this, technically, is not being used for "encryption." First, is a matter of semantics; if I know the plain text (the string of NUL's) then I'm not "encrypting" anything becuase I'm not "hiding information." I am "using cryptographic protocols and algorithms" for other purposes (such as authentication, digital signatures, etc). The other reason is more technical and pedantic. Conceivably there might be multiple keys (passwords) that encrypt a string of NUL's into the same hash. This is a defining property of hashes (checksums, CRC's, etc). You can verify that there is a given "message" has a given likelihood of being valid (you can measure its probability of integrity) --- but you can not definitively say that a given specific message was the same one that generated a given hash. (Given other constraints on the use of DES for Unix passwords it's possible to try all 1 to 8 character combinations to detect collisions --- but that is a different matter).
In any event, given an alleged password the 'login' program (or the xdm, xlockmore, POP/IMAP daemon, or PAM module, etc) will attempt to encrypt a string of NUL's with it (and the "salt") and compare the resulting hash to the one stored in the /etc/passwd or the /etc/shadow file. (Generally this is done via the 'crypt(3)' library call). There are minor differences in the details (particularly on 'shadow' vs. non-shadowed systems) but that's the gist of it. If the hashes match than the user is presumed to have entered the correct password.
If we follow another cross-reference from the passwd(1) man page we might find a list of characters that cannot be generated by the crypt(3) function. Actually we'll find a list of characters that can result from the operation and a bit of thought about that (taking the complement) will show us some characters that will never work.
Now, the Linux man pages don't just come out and say this but logically we can see that we could use the following procedure to "manually" disable an account:
... and it makes sense that no password will ever result in a matching hash. Thus the user will be locked out of direct logins. To re-enable the account *with the same password it used to have* just remove the asterisk. That's why we don't overwrite the passwd --- then we'd have to go through extra work to securely re-enable the password and get the user's new password set. (Most organizations are quite sloppy about this procedure --- sending initial passwords over e-mail, setting them to well-known and easily guessed values, etc. I recommend much better protocols).
Now, I have a confession to make: I didn't figure this all out on my own. I didn't read all of these man pages. I learned about the "prepend with an asterisk" trick from other sysadmins. It was so long ago, I really don't remember where I saw it first. It might have been netnews. It might have been over someone's shoulder. Who knows.
The point here is that you should find some of those sysadmins to "hang out" with. To be an effective sysadmin you need to become part of a sysadmin community. You and your classmates should probably form such a community and work together --- there's too much in this field for anyone to "know it all" (as a perusal of my back issues will sure prove with regards to me). The most organized and widespread community of sysadmins would be SAGE (the "System Adminsitrator's Guild" --- the 'e' is silent). Look at http://www.usenix.org/sage for details.
Of course none of this is to suggest that you should neglect your textbooks. There are two standard textbooks on systems administration today:
Unix System Administration Handbook, 2nd Edition
by Evi Nemeth, Trent R. Hein, Scott Seebass and Garth Snyder
(Prentice Hall, 1995, ISBN 0-13-151051-7)
Known as the "cranberry book."
Essential System Administration, 2nd Edition
by Aeleen Frisch
(O'Reilly & Associates, 1995, ISBN 1-56592-127-5)
... the "armadillo book"
... I'm working on one that I hope will go well beyond these --- although it will appear as a "Linux" title.
Of the two Frisch's work tends to give a more "step-by-step" HOWTO approach to these things --- so I'd look in there (indeed I tried to review it so I could remind myself of what she says --- but my copy must be out on loan somewhere).
Glancing in the cranberry book's index I find no entry under "accounts" and "users" refers me to "logins" where I find "disabling" on pp. 95 & 95:
Occasionally, a user's login must be temporarily disabled. Before networking invaded the UNIX world we would just put a star in front of the encrypted password, making it impossible for the user to log in. However the user could still log in across the network. These days we replace the user's shell with a program that prints a message explaining why the login as been disabled and provides instructions for rectifying the situation.
There is no further explanation of this at that point --- and they don't cover a number of other issues related to the situation.
They are, of course, referring to the fact that this user might have a .rhosts file that permits them access to their account without a password. Their approach is part of a solution --- but it is incomplete.
In the Linux System Administration Handbook by Mark F. Komarinski and Cary Collett they go into a bit more detail (p. 24) but show a bit less experience:
If you want to disable a user account (that is, prevent the user from logging in again), replace the password in the /etc/passwd file with an * or some other character. Since the * isn't a valid encrypted password, there is no password that will allow you to log into that account (2).
... no notion of re-enabling the account with its old password here. We've replaced it.
Komarinski and Collett also mention that the account can receive mail --- but doesn't mention that there may be other forms of access that are possible by this "disabled" user. They miss the same things that Nemeth et al gloss over --- and a bit more.
A few of the problems with just knocking out the password --- and changing the shell:
You might have various other services, like ssh, that don't require a password.
Their .forward file might route their mail through a script or customer filtering program (like procmail). That script could do anything that they could do under their UID --- including opening up some sort of connection to some system to which they still have access and allowing them to have interactive access to a shell. (I don't know of a tool that does this --- but I know it's possible and I could probably cook one up in a few hours using 'netcat' and/or 'expect' --- there's probably a set of "warez" that does this for you.
They might have started a daemon. This might wake up periodically and change their password and shell back to some setting (we didn't prevent their UID from running the chsh and passwd commands, perhaps via an 'expect' or a Perl/comm.pl script).
They might leave in 'cron' or 'at' jobs to periodically renable their access or as a logic bomb.
If their directory was on a writable NFS volume and they can get at any of the hosts that are trusted by that NFS server ---- they can put in new .forward and other "magic" files to do these sorts of things.
There might be other mechanisms that I don't even know about. In fact there almost certainly are.
Many of these won't apply to many hosts. However they should all be considered.
One potential method would be to remove their line from the /etc/passwd file completely. Perhaps you'd save it in a special file so you could restore it later. I don't like that approach since it leaves their files as 'orphans' (an ls -l command will show numeric ID's for the ownership and they will be found by a 'find -nouser' command).
So, the minimum I recommend to disable an account is:
Using PAM you can do other things, in addition to this. For example you can use the listfile.so (module) to check a magic file in /etc/ (one that you create for yourself) with the "sense=deny" parameters.
Another thing I personally recommend (at least optionally) is to scour your filesystems for files owned by this user --- move them all into a "graveyard" .tar file.
You can use a command like:
{ cd / && find . -user $GOING \
| tee /root/tmp/scourge.$$ \
| tar cTzf - /home/.graveyard/$GOING.tar.gz } \
&& cat /root/tmp/scourge.$$ | xargs rm -f \
cat /root/tmp/scourge.$$ | xargs rmdir 2> /dev/null
... this is intentionally simplified (I usually do this by hand since I have reason to go through a disabled users files to re-assign them to other users. That's appropriate for former or suspended employees while it wouldn't be in most educational or ISP environments).
The point of this process is to create a "graveyard" file that contains every file that this user owned. I remove them (dangerous if they used degenerate filenames --- this part I'm glossing over since I usually manually look over the list to catch them and I suggest running a 'skulker' to warn you about 'weird' filenames anyway).
In most cases I don't recommend re-using user names (for several months at least) or UID's (until you've "wrapped around" on the UID's). This is a complex issue, but it really amounts to avoiding the confusion when you restore from backups, or encounter other files (perhaps members from .tar files) etc. This is another case where the standard practice for ISP's and educational institutions is necessary quite different from business and government sites (typically the turn over in ISP's and at colleges, etc, is far to quick to worry about UID re-use after about one fiscal quarter).
Note: there may be other things you'll have to do in sites that use NIS/NIS+ (make sure you update the account entry in the master yp maps), and in Kerberos realms (remove their credentials on the KDC). I don't know all the details of these.
Hopefully I've made some important points here:
Read the man pages. (I have never left it at RTFM --- I prefer to tell you which M to F'ing R).
Look beyond the first answer. If you'd stopped at the usermod -f 0, you'd be stumped at the first box you came to that didn't have the shadow suite installed, or that had a different implementation. Likewise with the passwd -l (which I think is not supported in the PAM suite that came with Red Hat 5.1).
Knowing about "star-ring out" the password is pretty portable --- it works with DES, MD5, and "Big-DES", at least. HOWEVER, you have to check on each new version of UNIX that you encounter! Try it on a test account and make sure you method works. Tomorrow someone may implement a Unix passwd scheme that uses SHA-1 (the NIST secure hashing algorithm) in some way --- possibly with a bug --- that ignores the "*'s." A minute's test on each new system is probably worth a professional sysadmin's time.
Look beyond the initial question. It sounds like you were told to just stop the user from "logging in" --- which might lead to an incomplete solution (prevent password authenticated logins). If the requirement is disable the account then perhaps you need to do more than merely prevent password authentication.
This last point is crucial. Just knowing how Unix and Linux work is not enough. Knowing that many sites have the r* (rsh, rlogin, et al) utilities enabled, and knowing that a .forward file can be used to run arbitrary shell scripts with arbitrary side effects; these go beyond just knowing how Unix works. More importantly you have to think about the implications of these things, and know people who've experienced some of them.
Reading the threads on comp.unix.admin for a few months will help quite a bit with that. Netnews for all the bad rap that it takes and all of the spam it endures, is still the largest set of open, ongoing technical discussions in the world. The regulars in comp.unix.admin are particularly helpful UNLESS YOU EXPECT THEM TO DO YOUR HOMEWORK.
Finally: it's more important that you know *how to find answers* than how to perform a specific operation. It is even more important that you learn how to ask the right questions.
This goes beyond the nitpick (disabling the user vs. his or her account) --- and asking "disable access to which services" (which requires some understanding of all of the services and forms of access that are available on the system at hand.
Anyway, good luck on your studies.

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 32 September 1998

[ Answer Guy Index ] phreak abandon javaterm BBS flaws doslinux resume
softwindows convert apache emulate database distrib proxy
disable DVI superblock serial permission detach cdr
rs422 modem notfound tuning libc5 startup clock ping
accounts lilo NDS 95slow nonlinux progenv cluster ftpd

[ Table Of Contents ] [ Front Page ] [ Previous Section ] [ Next Section ]