Unix: Tracking down ghost accounts

Are you confident that all the accounts you manage are still required and still current? Or might some of them be ghost accounts that you should have blocked five years ago?

One of the long recognized vulnerabilities on Unix systems is the problem of accounts that should have been shut down years ago but, due to some oversight, were left open well after the account "owner" left the company or moved on to other job responsibilities. For Unix systems that are set up with account expiration, the security risks that these accounts convey is limited. Within the 3-6 months following the change in the account owner's status, the accounts should be locked automatically by the system. Of course 3-6 is a long time for an account to be open when it shouldn't be, especially if the former user was laid off, left to work for a competitor, or might have shared his/her password or used the same password on numerous accounts. Systems administrators are not always in the loop when staff leave the company for various reasons. So, accounts that should be locked or removed immediately may be left open for months or years after the user has disappeared. I have run into some of these myself over the years. Some should-have-been-locked accounts were still available on servers 8-10 years after their users' departures. Sometimes, this was because no one periodically checked on the existing accounts. Other times, the admins didn't remove accounts that they didn't recognize, fearing that they'd be causing problems for someone if they did. How to check for last activity ... Two commands might help with this -- last and finger -- and, if you're lucky, the responses they provide will line up more or less. The last command, however, depends on the contents of your /var/log/wtmp file. For some of us, this file can grow for years. For others, the file is periodically cycled. You might have more than one wtmp file. You might have only one and find out that it only goes back a few months. Purging old wtmp files is more often done on systems with a large number of accounts to keep them from growing too large and overwhelming the disk space available. Using last, you might get a response like this in which the wtmp file is only a couple months old and doesn't contain any information on the user's login activity:

$ last ndrew

wtmp begins Mon Dec  2 09:52:55 2013

This means that there is no evidence of logins for this user in the wtmp file. Checking the same account with the finger command, you might get a different response. Here we see that ndrew last login was well over a year ago.

$ finger ndrew
Login: ndrew                           Name: Nancy Drew
Directory: /home/ndrew                 Shell: /bin/tcsh
Last login Fri Mar 11 14:35 2011 (EST) on pts/0 from
Mail last read Wed Oct 31 07:02 2012 (EDT)
No Plan.

If you want to check all of the accounts on a system, you can do this with a simple script like this. For anyone who hasn't ever logged in, you will just see the username listed. For others you will see the username followed by the date and time of the last login.


for user in `awk -F: '{print $1}' /etc/passwd`
    echo -n "$user: "
    finger $user | grep Last
    if [ $? != 0 ]; then

Here's an example of the kind of output you should expect to see:

shs: Last login Sat Feb  1 16:36 (EST) on pts/3 from boson.particles.com
ndrew: Last login Fri Mar 11 14:35 2011 (EST) on pts/0 from

The vulnerability of "ghost" accounts is increased for accounts that are shared intentionally. In fact, just keeping track of who the intended users are, providing for a way that users can change and exchange shared passwords securely, and monitoring account usage can be a major headache. If passwords are shared in this way, they should be changed when any of the individuals sharing an account moves on to another assignment, but it's hard to track who is actually using an account when it's shared. You could set up separate logins to an shared account, each with its own password, but the same UID. This makes it possible for you to manage/monitor who is using an account and to shut down access for any individual user. It doesn't provide all of the niceties of individual accounts, but at least provides some accountability. For example, if several people use an account called "razadmin", but they have separate login names and passwords, you can review which of them is logging in.

sally:x:1112:1112:Sally Chapman:/home/sally:/bin/bash
dick:x:1112:1112:Richard Sellers:/home/dick:/bin/bash
jane:x:1112:1112:Jane Doe:/home/jane:/bin/bash
razadmin:x:1112:1112:RAZ Admin:/home/razadmin:/bin/bash

The who, last, and finger commands should differentiate your users in spite of the shared UID and GID. An even better option, if you can make use of it, is to use completely distinct user accounts, but allow each of the individuals who needs to use to shared account to switch user to the shared account using sudo. If it is not a necessity that the user log into the shared account directly, this setup gives you the best of individual accountability and a single proper account. Even better if the application being shared allows for separate logins! If this is the case, you shouldn't bother with shared accounts. However you set up your users' accounts, account reviews should be performed periodically to reduce the likelihood that accounts that should be closed are indeed closed. I'd suggest this be done every 3-6 months, but how much work is involved depends on how well you know your user base and whether the accounts in question are likely to be used infrequently. If so, it will be much harder to determine that an account is no longer required. If you have a way to validate that each user is indeed still a current staff member and is still associated with the project or work requiring the accounts that you administer, you will have an easier time of this than many of us. I am fortunate enough these days to also manage a system which tracks accounts from many systems and that pulls information on current staff every day from a reliable business source. I also receive termination notices. Without access to these kinds of information resources, tracking down which accounts should still be active would be both time-consuming and frustrating.

Read more of Sandra Henry-Stocker's Unix as a Second Language blog and follow the latest IT news at ITworld, Twitter and Facebook.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT