How To Cleanup Stale Data in Active Directory

by | Jun 2, 2020 | ZAG Standards

What’s poor Active Directory (AD) hygiene, you ask? No, it doesn’t involve soap or disinfectant. But it does involve occasionally going through your AD environment and doing some cleanup, sometimes deep down in the bowels of active directory. As your organization grows, stale data tends to accumulate in places, eventually leading to intermittent and difficult to diagnose issues within your environment. Stale data like authorized DHCP servers that no longer exist, invalid service connection entries, or disabled users in groups can cause erratic behavior.

So what can be done about this? There are several best practices to follow that will keep your AD environment humming along.

Migrate SYSVOL Replication to DFSR

The first thing you should do is make sure you are on Distributed File System Replication (DFSR) for your SYSVOL replication; you would be surprised how many organizations are still using File Replication (FRS) for AD replication. DFSR is more robust, faster to converge, and has a significantly reduced bandwidth requirement. If you have group policy problems that are difficult to replicate, this is a good place to start your investigation.

Update the Active Directory Functional Level

When performing maintenance on your AD environment, it is also worth considering updating to the latest Domain and Forest functional levels. Active directory is not patched in a traditional manner like Windows, but Microsoft does update the schema when new versions of the Server OS are released. These schema updates can include new functionality like the Active Directory Recycle Bin (which can recover an accidentally deleted AD object) or Fine-Grained Password Policies (allowing different password requirements to be applied per user or group rather than in bulk via group policy). These new features can only be available once a minimum Forest and/or Domain functional level is set.

Decommissioning Servers & Accounts

Similarly, when you decommission a server, keep in mind that merely removing the role from the server may not be enough. AD Certificate Services, Terminal Server Licensing, DNS, DHCP, Exchange servers, File Servers, and even Active Directory domain controllers all leave behind data in Active Directory and other locations that require additional cleanup post uninstall. Orphaned entries, particularly within the DNS server references, can lead to hit-or-miss connectivity even when no physical or design problems exist within your network.

Finally, when you de-activate an account, remove it from everything other than the Domain Users group; don’t delete it as this can cause its own problems with SID related issues and permissions. But do remove group memberships and place the disabled object in an Organizational Unit that does not contain other active objects.

Use Organizational Units

When it comes to Organizational Unites (OUs), there are also practices that should be followed. The first rule, greater than all the others, is this: USE THEM. OUs were designed to help you manage your organization in a logical and consistent manner. Every business is different in structure and requirements, which is why the default AD structure is bare bones. However, just because it starts out sparse does not mean it should remain that way.

A typical AD structure may include OUs for different geographical locations to determine what servers and other resources get allocated to a system or user. OUs may also be organized by other groupings, for example, by compliance needs where certain users may be subject to greater regulatory scrutiny such as sensitive data encryption requirements or more extended data retention periods. In addition to this grouping, you can also segregate your servers from your workstations or laptops from desktops. All of these are excellent use cases for having your directory properly structured and organized.

Under the right circumstances, proper OU structure can also simplify day to day administration. User moved to a new office and needs new drive mappings as a result? With some minor scripting, updating that user to get the new share access and printer mapping is as simple as moving them to the correct OU and waiting for the scheduled task to handle the rest of the work for you. Appropriately leveraging the capabilities of the Active Directory PowerShell can help you save time and effort in maintaining your AD environment, allowing you to quasi-dynamically update group memberships, get insight into and even automate aspects of cleaning up, and organizing your AD environment.

Schedule Your Active Directory Maintenance

How often should you perform a review of your AD environment for stale data? It depends on the amount of churn in your organization. A small shop with a few low use accounts and a stable environment might be able to perform these checks annually with no problems. A similarly sized organization that has a few developers with a constantly changing software environment with new servers constantly being added and removed should perform the same cleanup quarterly if not monthly. Lastly, if you are running a development environment with a high level of change, consider placing it in a separate domain within the same forest as your production environment to avoid generating issues within your production systems.

Related Content