Active Directory: delete vs. disable departed employees
Solution 1:
We disable the accounts. Their "descriptions" get updated to indicate the date of the departure, and they get moved in the AD hierarchy to a folder depending on what state of departure they are in (gone+email forwarded somewhere, gone+pre-archive, archived).
We have a large quantity of complex files and folder hierarchies. If you delete the account from Active Directory, and file/folder with explicit per-user ACLs will have that ACL data displayed as a SID. And I have not found any way to figure out from a SID which account it used to be -- because the account has been deleted.
This way when people are looking at ownership/permissions issues which are behaving oddly, we can see (and delete) ownerships and permissions of people who are no longer present.
If you delete a user and later on you discover that he or She have encrypted some files and folders using EFS, you will not be able to decrypt them.
Update, much later: I learned from a colleague who is undergoing an audit from Microsoft that accounts in your AD require a "per-seat" license (if you are swinging that way), whether or not they are a real person and whether or not the person is still present. So there is an argument to be made for deletion!
Solution 2:
Once they quit, they ain't coming back usually. I see no reason to hang onto old accounts. Here is what we do:
Files:
- Go through their desktop (My Documents and Desktop usually) and archive their old data to the archive fileserver (just a few 1tb drives in RAID-5)
- Back up their /user folder on the regular fileserver to the archive one as well.
Emails:
- Back up all their emails (either in pst or just save their mailbox, depending on OS) and put it in a safe place. Sometimes managers need access to ex-employees mailboxes to retrieve specific emails.
- If needed we set up an email forward to a manager or coworkers account until there is no more mail coming through.
Solution 3:
Here at my place of Higher Ed we have a disable and retain for 2 weeks policy.
- When their account gets listed in Banner as 'inactive' the next night's batch processing will fire off the Disable process.
- Their Novell accounts are disabled AND a login-time restriction put in place.
- Their AD accounts are disabled AND a login-time restriction put in place.
- Their Exchange accounts are set with a Delivery Restriction to themselves, forcing all mail to that account to bounce (new with Exchange 2007, disabled accounts can still receive mail).
- Two weeks elapse, during which time managers may throw data-retention flags. We deal with special snowflakes during this interval.
- At the end of two weeks accounts, user-directories, and mailboxes are purged.
Managers requesting access to user-directory data are given a CD, not direct access. FAR too often in the past said managers just use the user-directory as yet another file store.
Managers requesting access to emails are given a PST export of the mailbox, and not direct access.
Managers complaining that said 20 year veteran of the department was the sole point of contact for a certain critical function, and therefore they need to keep the name around so critical mails don't get bounced, get their hands held. We try to put an Out Of Office rule on the disabled mailbox stating that the person has left and please contact Person B instead. We then set a hard delete-date for that account suitably far in the future to make sure that the world knows that Person A is no longer here. We do NOT put that email address on another mailbox if we can at all help it. We are not always successful.
Sometimes that 20 year veteran was the prime secretary support for an area, and therefore was a Delegate of pretty much everyone with a calendar that needs managing. As soon as an account like that gets disabled, anyone sending an appointment to the managed calendars will get unusual bounce messages. Temporarily re-enabling the account stops the bounce messages while desktop staff go through and hand-remove the Delegates from all of the mailboxes. This can take a couple of days for the desktop staff to negotiate with the owners of said calendars to get in and make the needed settings. The account is then re-disabled and will be subject to the usual 2-week deletion. This is one 'feature' of Exchange that I particularly don't like.
Solution 4:
I'm not a fan of immediately deleting an AD account after an employee or contractor leaves the company. I've found that it's best to disable for at least 30 days and then delete the disabled accounts 1-2 times a year.
There are a couple of reasons why you don't want to delete an account immediately:
1- Forensics. If your organization has a need to pursue legal action against an employee or contractor you will need the original account(SID).
2- Automated Tasks- Users, especially IT workers, tend to setup automated tasks to do thinks like run jobs, automate reports, recycle services, etc. Your going to be in a bind if you delete the user account before you realized there were complex jobs or tasks tied to the ID's. You can't simply recreate the account with the same name because the SID won't be the same and that's what the automated tasks look at not the visible name of the account.
If you disable first, you can always re-enable the account, change or recover the password, and your back in business until you get the job transitioned over to a legitimate service account.
Solution 5:
We have pretty strict audit requirements, and are often asked to prove that a user was disabled, and when. To deal with this we tend to disable the account when we're told they've left. Move the disabled accounts to their own OU, and update the description with the date they've left (it also comes in handy for letting us disable people who disappear for a prolonged period of time and re-enable them when they come back).
Once they've gone for 6 months then we delete them.