[Ref: BSD Certification | User Administration | FAQ 10]
Table of Contents
If you are new to managing user accounts on OpenBSD, please refer to the above two resources. The BSD Certification, are a very solid grounding in the theory and practise of user administration. Refer FAQ 10 for explicit review of available command-line tools.
These notes discuss general ‘principals’ we currently practise for removing user accounts, more specifics are in the above two posts, and in the script file we use for creating new users.
Removing users should follow an established procedure, where we present opportunities to reconsider activities, review the process, and minimise potential for forgetting important elements in the removal of the account, privileges.
A good list of items to confirm during the account removal include:
Using the user login name (username) that we know we want to remove, we first establish a few ‘related’ details that will be important when we want to make later searches, to ‘complete’ the removal process.
USERNAME=username
Grab the user-id and group-id, this information is linked to at least file ownership throughout the system. The user may own files outside their home directory. It is important to ensure that those files are dealt with correctly.
One command-line method of reviewing the uid, gid is below.
grep "^$USERNAME:" /etc/passwd
The above grep will show the ‘username’ details from the /etc/passwd file. Or, we can explicitly extract the User ID, which is field #3, and the group id, field #4.
grep "^$USERNAME:" /etc/passwd | awk -F : '{ print "uid:"$3", gid:" $4}'
We can either manually note down the above uid, gid, or we can put them into another set of shell variables, such as in the below.
USER_ID=`grep $USERNAME /etc/passwd | awk -F : '{ print $3 }'`
GROUP_ID=`grep $USERNAME /etc/passwd | awk -F : '{ print $4 }'`
[Ref: w(1)]
Preferably the fewer people logged in during this process the saner the environment, but especially we don’t need the user being logged in at this time.
w(1) is a great tool for noting which users are currently online. In particular, we are mostly concerned that the user we’ve specified in $USERNAME is not currently logged in.
So, execute w and grab headers (1st 2 lines) and see if there’s any instance of the user active on the system.
/usr/bin/w | /usr/bin/head -2 /usr/bin/w | /usr/bin/grep "^$USERNAME"
If they’re still active on the system, WHAT??? are they doing, and WHY!!!????
(At this point, it would be useful to check the users cron settings to ensure none of the cron jobs are currently active as well)
cat /var/cron/tabs/$USERNAME
[Ref: rmuser]
Before removing a user account, a sanity review of the users cron and /home directory may be preferred, because in a scripted configuration we’re just going to blow away the user home directory.
rmuser username behaves differently amongst the Unix variants, and under OpenBSD will remove:
Normally at /home/$USERNAME, but you can/should obviously verify the setting from the /etc/passwd file.
Blowing away a users home directory is sometimes a good idea, other times it’s not so bright. Make sure you know what your policy, procedures are for ‘retired’ user files.
You should check the users cron jobs, they may have been instrumental in some activity for the organisation and it’s hidden in their cron job.
Verify this is really the user that you want to ‘blow away.’
A basic check list of the username’s Group involvement.
After you’ve performed your preliminary sanity check, go ahead and blow away the user with rmuser
sudo rmuser $USERNAME
Check the system authrised keys files for any immediately visible changes such as the authorised file, modification times.
A more thorough check would check the authorised key per the /home directories listed in the /etc/passwd. Make sure the users SSH key settings are not in another user accounts authorized_keys
After all, no value in deleting the user account, if the user can just hop in on another person’s account, with their existing SSH keys.
Check for orphaned files that may cause functionality issues at a later time or may be vectors for other forms of instability.
Some files may need to be maintained, but there’s generally a problem with leaving files on the system that are associated with someone who has been removed (i.e. a new user may inherit the group/username and thus have the privileges of those files)
You will need to make a judgement call on who the new user/group owners for orphaned files may be, for example:
find / -user $USER_ID -exec chown root:wheel "{}" ";"
find / -user $USER_ID -type f -exec chmod 600 root:wheel "{}" ";"
If the user had root access, then a lot of other sanity checks come into play, the simplest being to change the root password.
# passwd root
If the user had password access to other user accounts, change the password on those accounts as well.
Check current user account settings for unintentional openings, such as root access being available in a non-standard way.
Verify in the configuration path (/etc) there are no other configurations in which the user was registered
/usr/bin/grep -r $USERNAME /etc/* | grep -v "Binary file" | grep -v "^/etc/termcap"
Remember that these are not the only paths where user settings are noted in text files.
Go into /var/www and (and other application configuration directories where user accounts may have been created) and search for instances of the username.
DIRECTORIES="conf htdocs etc"
for i in $DIRECTORIES do
/usr/bin/grep -r $USERNAME /var/www/$i | \
grep -v "Binary file"
done
Obviously, with applications the user may not be using the same username as for host access.
Various services are operational across the spectrum of machines, make sure you have some sort of procedure for verifying whether user accounts are administered seperately for users.
General Services often installed with OpenBSD include: