Active directory Troubleshooting (Part1 - Diagnostics Logging)

Troubleshooting Active Directory issues like authentication failures, performance issues and logon issues, we can use different methods to monitor the AD, I will discuss more about enabling diagnostics logging, adding related counters on performance monitor to monitor the AD, Enabling debug logging for the Net Logon service

As an Active Directory Administrator did any one asked the questions like, how many search operations Active Directory performed and who searched from which server? Number of secure channel connection to which Domain and Domain controller? Number of Kerberos authentications on the server per second? Number of connected LDAP client sessions

While doing the troubleshooting you may have this question or some one asked the question to resolve the issue, am going discuss how to find the answer for this

Active Directory Diagnostics logging

 

To get more data about the directory service we have to enable Active Directory Diagnostics logging to respective Domain controllers in the registry (HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\)

We have below values in Diagnostics logging, when enabled, it will dump additional events into the DC event log to assist with troubleshooting. You can change these values from zero to five, the default value is zero, meaning minimal verbosity, and a setting of five will dump more than you want, normally I use four (if require five)

Note: Make sure to reset the value to zero when troubleshooting is completed

The most common values for Active Directory Diagnostics logging:

• 1 Knowledge Consistency Checker
• 10 Performance Counters
• 13 Name Resolution (this is DNS related)
• 15 Field Engineering
• 18 Global Catalog
• 2 Security Events
• 5 Replication Events
• 8 Directory Access
• 9 Internal Processing
  

I have used 15 Field Engineering value many times to find the inefficient LDAP queries including the client who was the source of the query with query string and the root of the query. This is important because one of the headaches related to AD is the LSASS process (Local System Authority Subsystem Service) using up enough resources to hang or crash a DC and cause client log on delays. Inefficient LDAP queries by a user or by an application or Linux client log on will put a huge load on LSASS. Enabling this diagnostic log will quickly identify the affected system or IP address in your network that casing the problem, so you will know which system searching the AD (querying the info from AD) and what info the system searching, this will help you to find the root cause of the issue, it helped me in many occasions

Example Events:

You will receive Event ID: 1643 if the value of 15 Field Engineering set to 4  

Event Type:            Information
Event Source:         NTDS General
Event Category:      Field Engineering
Event ID:                1643
Date:                      28/05/2012
Time:                     1:35:26 p.m.
User:                      NT AUTHORITY\ANONYMOUS LOGON
Computer:              server1
Description:

Internal event: Active Directory performed the following number of search operations within this time interval.

Time interval (hours):
12

Number of search operations:
30937

During this time interval, the following number of search operations were characterized as either expensive or inefficient.

 
Expensive search operations:0

Inefficient search operations:0

 

You will receive Event ID: 1644 if the value of 15 Field Engineering set to  5

If you set the value to 5 you will see an event entry for each search against the directory that breaches the inexpensive and/or inefficient search thresholds.  

Event Type:           Information
Event Source:       NTDS General
Event Category:    Field Engineering
Event ID:                1644
Date:                      28/05/2012
Time:                      10:06:25 a.m.
User:                      TM\Administrator
Computer:             server1
Description:
Internal event: A client issued a search operation with the following options.

Client:
192.168.100.1

Starting node:
DC=test,DC=com

Filter: ( &  (objectClass=user)  (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=test,DC=com)  (sn=z*) ) 

Search scope:

subtree

Attribute selection:

sAMAccountName

Server controls:

 Visited entries:

24579

Returned entries:

25

 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Conclusion:

But you won’t actually see anything in the event log until you have enabled diagnostics logging by modifying the registry.  

Like that for replication troubleshooting, you can enable 1 Knowledge Consistency Checker and 5 Replication Events, The 9 Internal Processing value is for getting additional details for DS events that indicate an internal error has occurred. This will often cause additional events that will aid in diagnosing the problem

Come back to see the next part of Active Directory Troubleshooting article, hope this will help you

Share this . . .