Summary: Learn about how to clean up stale Active Directory accounts.
Microsoft Scripting Guy, Ed Wilson, is here. Today we continue our series about Active Directory PowerShell by Ashley McGlone. Before you begin, you might enjoy reading his first two posts:
Here's Ashley...
In the United States, this week we celebrate Thanksgiving. I’ve made the joke before that you can give thanks for Windows PowerShell, but your family really will not understand the significance. Nevertheless, I am thankful for family, friends, and Windows PowerShell.
Clean your room much?
In my work with Microsoft, I have found organizations with tens-of-thousands of stale user and computer accounts. Some companies never touch them. Others are surprised to find terminated users in the Domain Admins account. Only a few sincerely review and clean up stale accounts. How is this possible?
As a child, I remember my mother telling me to clean my room. And why did she have to tell me? Because most of us do not like to clean. My desk looks much like this these days!
I muster the time and courage to clean my office—maybe twice a year—and that is only when the pain of the paper piles exceeds my proclivity for procrastination. Active Directory is no different. Many businesses do not prioritize cleaning up stale accounts because there is no pain or penalty associated with it. That is until compliance audit time. Many compliance standards today mandate removal of stale accounts. Suddenly it becomes the "flavor of the month" with management when the auditors roll in.
Steps to stale account cleanup
So what are the steps to finding and removing stale accounts? I am glad you asked.
We would like it to be a simple query and delete. However, there is a little more to the story. It is fun to automate the process, but we need to think it through first. I would outline the process as follows:
1. Step one is to turn on the Active Directory Recycle Bin if not already enabled. This will be your safety net for accidental deletion of good accounts.
2. Identify your compliance timeframe for inactive accounts. 30 days? 90 days? This will likely be a conversation with the compliance project manager. Note that computers and managed service accounts reset their own passwords every 30 days. User accounts will depend on the domain password policy (Get‑ADDefaultDomainPasswordPolicy) and any fine-grained password policy (Get‑ADUserResultantPasswordPolicy).
3. Query the directory to find stale objects. Do not delete them yet! Criteria might include a ping response, DNS lookup result, PwdLastSet, or LastLogonTimestamp.
4. Review the data and create a list of known exceptions (for example, krbtgt user, key service accounts, high profile business users, or cluster computers. For more information about cluster computers, see Cluster and Stale Computer Accounts).
5. Script your cleanup process. I recommend two phases to each run once per week:
- Phase 1. Disable stale accounts and append a notice to the account description, similar to this: Account disabled due to inactivity on 11/12/2014. Your exception list should be filtered prior to disabling accounts. First disabling the account makes recovery quick if someone calls to report that an account is actually active. Those accounts will then go on the exception list.
- Phase 2. Query for the now disabled accounts that still have not been touched in 30 days. Filter again against the exception list. These should now be safe for removal. Deleting these accounts will send them to the Recycle Bin. If someone calls at this point, you can use Restore‑ADObject or the Active Directory Administrative Center (ADAC) graphical interface to restore the accounts. For computer accounts, you can optionally delete any DNS records and/or DHCP reservations.
6. Make sure that your scripts generate central log files and that your first-tier support team can review these when they are troubleshooting account issues.
7. Document the procedures for enabling or recovering a stale account that was incorrectly targeted. Also document the process for updating the exception list. Communicate these steps to your level-one support team. On second thought, maybe InfoSec should be the only ones granting exceptions. Sounds like a decision for the project manager.
8. After a few manual runs of the process, and when you feel comfortable with it, schedule these two phases to run weekly.
9. Monitor the logs and call volume closely for another 90 days. If necessary, adjust the process to eliminate false positives.
10. Report compliance status to management at each phase of the implementation and at regular intervals going forward. This can also be scripted with the Send-MailMessage cmdlet.
You may be able to add your own considerations to what I have listed.
Where's the Windows PowerShell?
Yes. This is a Windows PowerShell blog. The first step to writing any script is to properly scope the activity and define the outcome. I have provided a good outline for you to start. Now take this outline and adjust it to your specific needs.
And that is what we call a “cliff hanger.” Stay tuned. Tomorrow I'll present some scripting tips to jump start your stale account cleanup.
~ Ashley
(photo credit: camknows via photopincc)
Thanks again, Ashley! Ashley recently recorded a full day of free Active Directory PowerShell training: Microsoft Virtual Academy: Using PowerShell for Active Directory. Watch these videos to learn more insider tips on topics like getting started with Active Directory PowerShell, routine administration, stale accounts, managing replication, disaster recovery, and domain controller deployment.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy