There are many components of Microsoft Active Directory Domain Services (AD DS) that can be assessed as part of a health check. Which ones to start with is, of course, the million-dollar question. At Ravenswood, we have an approach to conducting health checks that looks at hundreds of directory service settings and characteristics of your Active Directory environment. We use all this information to identify issues, make recommendations, and score the overall risk of an AD environment.
If you are looking to do a health check yourself, there are many things you can check quickly with tools that come with Windows. Knowing which tools to use is half the battle. Let’s look at where to begin and what to look for.
Scope of the Health Check
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Just like getting a check-up at the doctor’s office, you’ll need to decide in advance how detailed the examination will be to determine whether your AD forest is healthy or not. You can always dig further if you find something that isn’t right, but as a starting point, there are several areas we recommend looking at to assess the operational health of your forest, including:
- Name Resolution – AD simply can’t function without a correctly functioning DNS infrastructure supporting the forest. DNS is so important that, by default, AD installs and manages the DNS Server role on each domain controller (DC). You can use an alternate DNS service, but you will need to check even more things if you do. If there is a missing or incorrect DNS record, clients may not be able to log on or log on performance can become very slow. If a DNS forwarder is misconfigured, resolution of external DNS records could fail.
- Replication – Since AD is a distributed, multi-master directory service, changes can be made on any writeable DC. AD’s replication engine is very reliable, but you can still break it. Replication uses the AD site topology to define how DCs are connected via the network and the paths that they take to replicate changes amongst one another. When replication is broken, you may see symptoms like incorrect group memberships or missing or out-of-date objects on certain DCs. If your site topology is incorrectly configured, or if you make changes to connection objects that should be automatically managed, you can create islands where changes are not replicated to and from certain DCs. You can also create unnecessary delays before replication converges.
- SYSVOL Replication – The SYSVOL share contains all of your Group Policy Object (GPO) settings. Changes to GPOs typically happen much less frequently than changes to data in the directory, but the changes must still replicate to every DC. AD relies on another Windows service called Distributed File System Replication (DFS-R) to replicate changes to SYSVOL. When DFS-R isn’t working correctly, clients may receive inconsistent Group Policy settings or have trouble processing Group Policy all together. If you are still using NT File Replication Service (NTFRS) to replicate SYSVOL, you must migrate to DFS-R. Microsoft no longer supports NTFRS.
AD is the security cornerstone of most enterprise networks. Because of this, it’s crucial that AD isn’t just healthy operationally, but that it isn’t presenting unnecessary security risks. Common security risks and misconfigurations include:
- Privileged Access – Members of built-in security groups like Domain Admins are highly privileged. If a credential for a member of a group like Domain Admins is compromised, your entire organization can quickly be compromised. Domain Admin membership should be minimized to only named individuals that support AD infrastructure, and break glass accounts. There should be no service accounts in Domain Admins. Members who only need to make changes to directory data or support other IT infrastructure systems like member servers or client computers should never be in the Domain Admins group. Other built-in groups, like Account Operators and Backup Operators, should always be empty. All of the functions they provide can be delegated as permissions in AD or user rights assignments in the operating system.
- Legacy Protocols – AD is an evolution of older versions of Windows that supported prior protocols like LM and NTLMv1. To maintain backwards compatibility—nearly 30 years later—Windows still supports these protocols. While compatibility is important, so is security. LM and NTLMv1 are weak protocols that present many security risks. NTLMv2 also has security challenges, but removing it is likely to be much harder than the older LM and NTLMv1 protocols. If you haven’t already disabled LM and NTLMv1, you should. Furthermore, you should enable audit logging to identify where NTLMv2 is used and begin removing dependencies where possible so that domain joined systems rely exclusively on Kerberos.
- LDAP Security – The LDAP protocol has existed in various forms since the mid-90s. Microsoft introduced it as a feature in Windows alongside AD. Since then, various security enhancements such as requirements for signing and encryption and enforcement of channel binding tokens have been made available. All these features prevent attack patterns like capture of plaintext credentials and man-in-the middle. Unfortunately, many applications use LDAP client libraries that do not support these protections. You should collect and analyze audit logging data on DCs to determine where you have applications and clients that will break if you enable requirements for signing and channel binding tokens. Based on that data, you can establish a plan to implement these requirements.
Once you have identified the scope of the health check, you will need to create a plan to assess AD. Fortunately, there are tools included with Windows that can help you perform the assessment.
Tools for Analyzing Active Directory Health
/c switch to run nearly all of the tests at once. For example, if you run dcdiag /s:DC01 /c, dcdiag will test a DC named DC01. If you specify the /e switch, dcdiag will test every DC in the forest. This can be helpful, but you should be careful if you have a large, distributed forest with slow or isolated network links. Depending on the complexity of your AD and network, it can take a long time to get test results when you use the /e switch.
DNS is seemingly the root cause of many issues that AD administrators face. Making sure all the records AD requires are registered by each DC is a fundamental step to ensure that clients can authenticate and access AD. Most organizations will use dynamic update whereby DCs can automatically register and maintain their DNS records. Without dynamic updates, you must be very careful to ensure that DNS is manually updated anytime the site topology changes, a DC is promoted or demoted, or a DC’s IP address changes.
There are a set of DNS tests in dcdiag that provide insight into the health of AD’s DNS records and the configuration of the DNS server service itself if you are using AD integrated DNS. To run these tests, run dcdiag /s:DC01 /test:DNS. You can use the /e switch instead of /s and run each DNS test for every DC in the forest. If you are not using AD integrated DNS, you may need to specify specific DNS tests that you want to run.
If you are troubleshooting replication issues, you might want to run the Topology and CutoffServers tests. The Topology test checks to make sure that there are no DCs that are lacking connection objects and isolated in the AD site topology. The CutoffServers test checks additional facets of the site topology to further ensure you have no isolated DCs. To run these, specify them explicitly by running dcdiag /s:DC01 /test:Topology or dcdiag /s:DC01 /test:CutoffServers.
While dcdiag tests for specific configuration settings related to replication, repadmin is much more useful for gathering the state of replication in your forest. You can use repadmin to get a summary of the last successful (or failed) replication for a given DC or naming context (NC). You can also use repadmin to export a CSV file with forest-wide replication status that you can easily analyze with a PowerShell script or in Excel.
To collect the status of replication for DC01, run repadmin /showrepl DC01. You will receive information about the last replication attempt for each NC that the DC hosts, including its domain, the Configuration and Schema NCs, AD integrated DNS NCs (if you use this), and if the DC is a global catalog, other domains in the forest.
Running this command for multiple DCs will quickly become tedious and verbose. You can substitute the name of the DC for an asterisk to collect data for the entire forest. This data will be very hard to digest if you have more than a few DCs. Instead, we recommend that you ask repadmin to format the data as a CSV so you can analyze it in another tool. For example, run repadmin /showrepl * /csv > ReplicationStatus.csv. This will output the status of replication for every NC hosted on each DC in the forest to a file. What's Next?
Keeping AD running in optimal condition is extremely important for any organization where AD is the cornerstone of the network. Operational health of AD is only part of the problem. Mitigating and preventing security risks introduced by AD is also critically important. You can use free tools included with Windows like dcdiag and repadmin to analyze many operational health facets. Monitoring and managing security risks to AD often requires scripting or third-party tools.
Regardless of how you monitor AD, it’s extremely important to regularly keep up on its health. One way to do this is with Ravenswood’s AD Health Check service. The AD Health Check analyzes hundreds of settings and best practices and produces actionable findings for you to remediate.
