Managing Dormant Accounts

If a user did not login to the system for considerable time (say 90 ot 180 or 256 days) and/or is known to be absent to an extended period of time, it make sense to prevent direct logins to such an account (dormant account). This assures that an intruder won't try to use the person's account in his or her absence. It is prudent to disable accounts that are seldom used, enabling them only as needed.

There is a utility dormant_user_stats that can do this automatically  and it can be invoked from cron to make this process seamless.

There are three simple ways to prevent logins to an account:

1. Change the account's password.

2. Modify the account's password so it can't be used.

3. Change the account's login shell.

Actually, you may want to consider doing all three.

Changing an Account's Password

You can prevent logins to a user's account by changing his password to something the user doesn't know. Only superuser can change another user's password.

Alternatively, you can prevent logins to an account by inserting an asterisk in the password field of the shadow file for the user's account. When you remove it, she will have her original password back.

Both POSIX version of passwd and GNU version of passwd used in Linux have option -l which accomplish the same thing:

passwd -l joeuser

NOTE: Note that you still can use su to log to the account, or using the trusted hosts mechanism. Thus, changing the password is not sufficient to completely block access to an account on such a system. But with proper permissions on the directory (700), it is enough to block access from non-privileged users.

Changing the Account's Login Shell

Another way to prevent direct logins to an account is to change the account's login shell to ; /bin/false or /sbin/noshell so that instead of letting the user type commands, the system simply prints an informative message and exits. This change effectively disables the account.

Most versions on Linux now contain /sbin/noshell ; for this particular purpose.

Finding Dormant Accounts

Accounts that haven't been used for an extended period of time are a potential security problem. They may belong to someone who has left or is on extended leave, and therefore the account is unwatched. If the account is broken into or the files are otherwise tampered with, the legitimate user might not take notice for some time to come. Therefore, disabling dormant accounts is good policy.

One way to disable accounts automatically when they become dormant (according to your ; definition of dormant) is to set a dormancy threshold on the account. You can also accomplish the same thing with the ; the -f ; option to the usermod ; command:

# usermod -f 90 joeuser

In this example, ; account locked if a login is not made at least once during any 90-day period. Option -U allows to unlock the account.

If your version of UNIX is not SVR4 and does not have something equivalent, you will need to find another way to identify dormant accounts.

Below is a simple shell script called not-this-month, which uses the last ; command to produce a list of the users who haven't logged in during the current month. Run it the last day of the month to produce a list of accounts that you may wish to disable:

#!/bin/sh
#
# not-this-month:
# Gives a list of users who have not logged in this month.
#
PATH=/bin:/usr/bin;export PATH
umask 077
THIS_MONTH=`date | awk '{print $2}'`
/bin/last | /bin/grep $THIS_MONTH | awk '{print $1}' |  /bin/sort -u > /tmp/users1$$ 
cat passwd | /bin/awk -F: '{print $1}' | /bin/sort -u > /tmp/users2$$
/bin/comm -13 /tmp/users[12]$$
/bin/rm -f /tmp/users[12]$$

The following explains the details of this shell script:

umask 077

Sets the umask ; value so that other users on your system will not be able to read the temporary files in /tmp.

PATH = /bin:/usr/bin

Sets up a safe path.

THIS_MONTH=`date | awk "{print $2}"`

Sets the shell variable THIS_MONTH to be the name of the current month.

last

Generates a list of all of the logins on record.

| grep $THIS_MONTH

Filters the above list so that it includes only the logins that happened this month.

| awk '{print $1}'

Selects out the login name from the above list.

| sort -u

Sorts the list of logins alphabetically, and removes multiple instances of account names.

cat -passwd | awk -F: '{print $1}'

Generates a list of the usernames of every user on the system.[4]

[4] Recall that we told you earlier that we would define ;cat-passwd ; to be the system-specific set of commands to print the contents of the password file.

comm -13

Prints items present in the second file, but not the first: the names of accounts that have not been used this month.

This shell script assumes that the database used by the last ; program has been kept for at least one month.

After you have determined which accounts have not been used recently, consider disabling them or contacting their owners. Of course, do not disable accounts such as root, bin, uucp, and news ; that are used for administrative purposes and system functions. Also remember that users who only access their account with the rsh ; (the remote shell command) or su ; commands won't show up with the last ; command.

Remove Abandoned Accounts!

We have seen cases where systems had account entries in the password file for users who had left the organization years before and had never logged in since. In at least one case, we saw logins for users that had not been active for more than three years, but the accounts had ever-expanding mailboxes from system-wide mail and even some off-site mailing lists! The problem was that the policy for removing accounts was to leave them until someone told the admin to delete them - something often overlooked or forgotten.

The easiest way to eliminate these historically dormant accounts on your system is to create every user account with a fixed expiration time. Users of active accounts should be required to renew their accounts periodically. In this way, accounts that become dormant will automatically expire if not renewed and they don't become a liability.

You can do this with the usermod ; command:

usermod -e 12/31/10 joeuser

Other systems may have a method of doing this. If nothing else, you can add an entry to the crontab ; to mail you a reminder to disable an account when it expires. You must couple this with periodic scans to determine which accounts are inactive, and then remove them from the system (after archiving them to offline storage, of course).

By having users renew their accounts periodically, you can verify that they still need the resources and access you have allocated. You can also use the renewal process as a trigger for some user awareness training.

NOTE: The last program only reports logins and logouts on the computer running it. Therefore, this script will not report users who have used other computers that are on the network, but have not used the computer on which the script is being run.

Discovering dormant accounts in a networked environment can be a challenging problem. Instead of looking at login/logout log files, you may wish to examine other traces of user activity, such as the last time that email was sent or read, or the access times on the files in a user's home directory.

NEWS CONTENTS

• 20201019 : The utility dormant_user_stats was posted on GitHub. ( Oct 19, 2020 )
• 20201019 : Finding dormant- unauthorized user in accounts solaris solaris, user ( Finding dormant- unauthorized user in accounts solaris solaris, user, )
• 20201019 : Locking inactive user accounts using PAM ( Locking inactive user accounts using PAM, )

Old News ;-)

[Oct 19, 2020] The utility dormant_user_stats was posted on GitHub.

The utility lists all users who were inactive for the specified number of days (default is 365). Calculates I-nodes usage too. Can execute simple commands for each dormant user (lock or delete account) and generates a text file with the list (one user per line) that can be used for more complex operations.

Use

dormant_user_stats -h

for more information

Finding dormant- unauthorized user in accounts solaris solaris, user

Hi Folks,

I have to do a security audit in Solaris production servers; in which one of audit read like this:

"Check for dormant and unauthorized accounts. Review the accounts in /etc/passwd files. Review, investigate, and results documented for any accounts that have had no logins for the past 90 days or accounts still present from terminated employees".

My queries are as follows:

1) How can I check whether a particular account is active and how can I find the last time the user logged in?
2) How can I ensure whether an account is a normal one or it has some administrative previlage?
3) I have an entry like this in passwd file "zzzzzz:x:60002:60002:special crontab account:/:/dev/null". What it represents? How can i ensure that this account is harmless?

Locking inactive user accounts using PAM

Hi All,

This is my first post in the forums. I have done a search of all possible combinations of keywords in the "Linux Security" sub forum for my problem and found nothing - I apologize if this question has already been answer before.

This is my requirement - lock out accounts if its not active for 30 days. So if an account is created and the user hasn't logged in for 30 days, the account is to be locked until "root" unlocks it. I want a method to do it using PAM. We use PAM modules for account, auth, password and session and have all major modules in the system. I have done a search in the internet to the best of my ability but still have no information on how to accomplish this.

Please let me know if anyone has any ideas/suggestions or pointers.

TIA

rizi

I'll try to get a look at this when I get home from work this evening, I'd be interested in a solution for it. Something that occurred to me is to be careful that you don't lock out or amend system users. Maybe some filter on users below UID 1000 could help.

Anyway, I'll certainly try to have a look this evening. Maybe even read up a bit more on PAM too

EDIT - I came across this in a google if it's any use to you :-

Manpage of PASSWD

Check out the -i and -x switches, looks like there might be a way around this, if you can slightly amend your requirements. If a users account had a regular password change requirement you could set a reasonably short expiry so that if it wasn't changed with a few days the account would be disabled. Maybe 15 day password turnaround and 15 day expiry? I understand this may not be suitable in your environment but it might be worth considering. It could also be easily reversed using a script for passwd though I'm guess the users would have to be manually unlocked.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Managing Dormant Accounts -CodeIdol

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: November, 02, 2020