Removing user accounts can be much harder than adding them! While not always true, often you can distinguish two cases, each with a slightly different timetable for performing various steps. However, there may be legal and policy reasons to treat all terminated employees the same.
One good idea is to create a “
script that undoes all the updates done by your
The scripts remember what must be done for you.
The complete account removal process may take one to seven years, depending on applicable laws, regulations, insurance policies, etc. (The statute of limitations applies here.)
While here we are just considering removing access on a single host, keep in mind the big picture. When an employee is terminated, and especially when an SA (or anyone with extra access) is terminated, you should:
One famous failure of this was when a Microsoft fired employee
ordered a new
certificate after termination.
Since the CA didn't
know the employee was no longer with Microsoft, they issued
The former employee then could put up a fake Microsoft web site,
one that had a valid certificate for HTTPS!
This is the situation where the person whose account your are removing is not trustworthy and may either cause damage if permitted access, or may have already caused damage. This can be very serious if the account was for an administrator (who had root access). Your goal here is to stop all access immediately, preserving as much data (which may be evidence) as possible, and to determine what damage may have already occurred.
Remember that by the time an evil/bad employee is fired he/she may have been corrupting your system for quite some time. CVS/RCS and other log files can be very useful here, as can process accounting records (if you installed that).
cronjobs, and other spooled work (e.g., printer jobs, UUCP, NNTP, ...). Also examine running processes started by the user.
.forwardfile and any email aliases resolving to this account (MTA), and the
.procmailrcfile (MDA). (An easy way to do this is simply to add an alias in
/etc/aliases, so the user's mail is sent to someone else.)
*LK*” in the password field (of
/etc/shadowor where ever these are stored). This will prevent
atjobs from starting.
htpasswd(web authentication) files, Samba, etc.
/etc/hosts.*, etc. (
grepis your friend here!)
antand Maven files too.)
You may never want to delete the UID! User IDs are still used in archives and backups, and possibly in files on other systems. If the UID is ever reassigned and a file is restored, you may have created a security problem. If a UID is reused, then years later (in court for instance) it will not be easy to determine who actually owned some file with that UID.
Note you may have to speak with a fired employee before they know they've been fired. Say something like “Before you account can be re-activated you must speak with X (the fired person's supervisor/boss)”. Be aware that the supervisor may have had a miscommunication and may order the account re-activated, so don't do anything irreversible too soon.
This is the situation when an employee left their job (or was promoted to a different position), with no hard feelings. In this case, you may wish to allow some access for an extended period. For example, if a salesperson is promoted to manager, former clients should still be able to contact this person using the same email address. Developers may need to submit patches and communicate with former colleagues. Universities often allow former students access for years after graduation to computer resources. (A recent HCC retiree of 35 years of service, had their email access turned off within 24 hours of her last day. This caused considerable disruption.)
Policy may dictate that account removal follow the same procedure for friendly or unfriendly termination, to comply with regulations, to limit liability, or just for PR purposes (so customers or stockholders have high confidence in your procedures).
If allowed by your organization's policies, some differences between friendly and unfriendly termination may include:
cronjobs. These may be OK to keep running, but eventually will need to be reassigned to another employee, or deleted.