Techniques to troubleshoot Active Directory issues

Run diagnostics on domain controllers

When you install the Windows Server Active Directory Domain Services role, Windows also installs a command-line tool named dcdiag.

This utility is very helpful to troubleshoot Active Directory -- specifically, its domain controllers.

To use dcdiag, open a command prompt window and enter dcdiag to kick off a series of basic tests that can help narrow the cause of the issue.

In Figure 1, dcdiag runs a series of tests and displays a Pass, Fail or Warning message for each.

Test DNS for signs of trouble

The Active Directory is completely dependent on the domain name service (DNS), which makes it crucial to verify that the organization's DNS servers are functioning properly. If you suspect DNS might be at the root of your problems, then there are two areas to check before you dive into more elaborate ways to troubleshoot Active Directory.

First, verify that the computer with the problems is pointed to the correct DNS server. All computers that participate in the Active Directory environment need to be configured at the TCP/IP level to use the DNS server that the authority for your domain rather than an external DNS server. You can verify a Windows machine's IP address configuration by entering the following command:

IPConfig /all

Figure 2 shows the command output.

Incidentally, Windows machines can experience DNS problems if expired entries get stuck in the machine's DNS resolver cache. You can clear the cache by using a variation of the IPConfig command:

IPConfig /FlushDNS

If you suspect a DNS problem, then another simple check is to make sure DNS is running. Open a PowerShell session on your DNS server and enter the following command:

Get-Service DNS

You should see a message similar to the one shown in Figure 3, indicating the DNS is working. If it isn't, you can start the service by entering this command:

Start-Service DNS

If these basic checks haven't revealed the cause of the problem, then your best option may be to use dcdiag and run some of its DNS specific tests. Here is one command that will check for basic DNS functionality:

dcdiag /test:dns /v /s:<Domain Controller Name> /DnsBasic

You can see a portion of the command's output in Figure 4.

Run checks on Kerberos

Active Directory uses Kerberos to authenticate communication on the domain. If Kerberos stops working, then the authentication process breaks down. Kerberos troubleshooting is complex, but there are two simple checks you can perform if you think this area is the problem.

First, verify the accuracy of the clocks on your domain controllers, your DNS server and any affected client machines. The Kerberos protocol is time-dependent and clock skew can cause several problems, including Kerberos failure. If clocks are out of sync, that is likely the reason for the issue with Active Directory.

Another area worth checking is the current list of Kerberos tickets, which you can generate by entering the KList command at the domain controller's command prompt. As you can see in Figure 5, this command returns helpful diagnostic information.

Examine the domain controllers

In an Active Directory environment, some domain controllers perform housekeeping chores delegated by a series of flexible single master operation (FSMO) roles to keep the identity and authentication system healthy. Some roles apply to the entire Active Directory forest, while others only apply to a single domain.

The first of these roles is the schema master role. If the schema master fails, then you cannot make changes to the Active Directory schema.

The second forest-level role is the domain naming master. This role maintains the forest's namespace. If the domain naming master fails, then you cannot create or delete domains within the forest.

The relative identifier (RID) master is a domain-level role responsible for providing the relative identifiers used to create a security identifier (SID). A SID consists of a domain SID, which is shared by all the objects in the domain, and a RID, which is unique to that object. If the RID master fails, then new objects can continue to be created so long as the pool of RIDs is not depleted. However, once this limit is reached, further object creation will fail.

Another domain-level role is the primary domain controller (PDC) emulator, which performs functions within the domain, including time sync and account lockout processing.

The final domain level role is the infrastructure master role. The infrastructure master updates an object's SID and distinguished name for cross-domain use.

You can use PowerShell to determine the various roles performed by each domain controller. Run the following command for forest-level roles:

Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster

To get a list of domain-level role holders, use the following command:

Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator

Figure 6 shows the results from each command.

If it looks like a domain controller is not running its designated roles correctly, then you can transfer the role to another domain controller with the Move-ADDirectoryServerOperationMasterRole cmdlet. If the domain controller that was hosting the role has failed, then you can seize the role by appending the -Force switch to the Move-ADDirectoryServerOperationMasterRole cmdlet.

Another good option is to check the event logs in the domain controller, as they will likely contain key information about the source of the problem.