Skip to main content

Troubleshooting Netlogon Error Codes

-

Quick Reference: Troubleshooting Netlogon Error Codes

January 28, 2013 by Mark Morowczynski [MSFT] // 24 Comments
Hi this is Brandon Wilson and today I will be providing you with a quick reference for troubleshooting Netlogon error codes.
I say “quick reference” very loosely here, because this is one of those sticky subjects that can easily expand into many more areas and become a very long discussion. So, I’m going to do my best to focus on just the codes and possible solutions for the error codes that are more common to see. Anyone who has dealt with some of these issues knows that some of these outlined areas can lead to huge revenue loss for a business, or at the very least an annoying authentication prompt J
I welcome you to leave comments and questions, or suggestions for articles that you as the reader would be interested in seeing us do on AskPFE Platforms (http://blogs.technet.com/b/askpfeplat/contact.aspx).

 

Netlogon logging overview:


I suppose I can’t assume that everyone in the world knows this, so let’s kick off the topic by covering where to enable Netlogon logging and the ways to enable it. How to enable Netlogon logging is also outlined at http://support.microsoft.com/kb/109626.

Where do I enable the Netlogon logging?

If you are having NTLM authentication or PAC validation issues, be prepared to enable verbose Netlogon logging across the entire authentication chain. Let use a common example, a web server servicing authentication:
1. Web server services users from the local domain only:
a. Enable verbose Netlogon logging on the application server
b. Enable verbose Netlogon logging on the domain controllers in the same logical Active Directory site (or any covering the site via Auto Site Coverage).
i. You can also enable logging on the web server first to identify the domain controller being contacted (or that contact is attempted with) when an issue occurs. From there, you can enable the logging on the domain controller you identify. A word of warning on using this method: if the issue is not persistent or is intermittent, you may lose your chance to gather all the necessary data the first time around.

2. Web server services users from another domain in the same forest:
a. Enable verbose Netlogon logging on the application server
b. Enable verbose Netlogon logging on the domain controllers from the web server’s domain that are in the same logical site
c. Enable verbose Netlogon logging on the domain controllers in the same logical site in the forest root (if the web server’s local domain is not the forest root)
d. Enable verbose Netlogon logging on the domain controllers in the same logical site in the target domain (if the target domain for authentication is a different child domain of the forest root)
NOTE: As mentioned before, you can also enable the logging selectively based on the DC discovery calls within the Netlogon log to identify the next level in the authentication chain.

3. Web server services user from another domain in a different forest:
a. Enable verbose Netlogon logging on the application server
b. Enable verbose Netlogon logging on the domain controllers from the web server’s domain that are in the same logical site
c. Enable verbose Netlogon logging on the domain controllers in the same logical site in the forest root (if the web server’s local domain is not the forest root)
d. Enable verbose Netlogon logging on the domain controllers in the same logical site in the forest root of the target domain. If the same logical site name does not exist in the target forest, you will need to identify the domain controller that is being contacted. This can be done with a network trace while the issue is occurring, or via the Netlogon logs.
e. Enable verbose Netlogon logging on the domain controllers in the same logical site in the target domain. If the same logical site name does not exist in the target forest, you will need to identify the domain controller that is being contacted. This can be done with a network trace while the issue is occurring, or via the Netlogon logs.
NOTE: As mentioned before, you can also enable the logging selectively based on the DC discovery calls within the Netlogon log to identify the next level in the authentication chain. In the case of cross forest authentication, it may actually be necessary initially to identify the domain controller we are talking to.
Remember, there are calls in the Netlogon log that represent the establishment of the secure channel with the other domain and will denote the domain controllers we are talking to (these are found in [SESSION] lines).

How do I enable verbose Netlogon logging?

1. From the command line:
a. To enable Netlogon logging, run the following command (w/o quotes): “nltest /DBFlag:0x2080FFFF”
image
b. To disable Netlogon logging, run the following command (w/o quotes): “nltest /DBFlag:0x0”
image
2. From the “Microsoft Fix it” button:
b. Scroll down to the “Fix it for me” section
c. Click the appropriate “Microsoft Fix it” button to enable or disable Netlogon logging
image
IMPORTANT NOTE: The Netlogon.log and Netlogon.bak files that are generated can be found in %systemroot%\Debug.

Differences between logging level verbosity:

When DBFlag is set to 0x0, it is common to have a 1kb file. This may of course not be the case if Netlogon logging has been enabled at any level in the past. On your Domain Controllers, you may see entries stating NO_CLIENT_SITE that can be useful to track and control straying clients.
When the value is set to the maximum verbosity (0x2080FFFF), you will see every single action taken by the Netlogon service. This does have a bit of overhead in terms of disk and memory utilization, hence I do not recommend you keep the maximum verbosity enabled at all times unless you have frequent issues relying on Netlogon logs to troubleshoot.
The example below was taken with maximum verbosity and a restart of the Netlogon service was performed. In this snip you can see a session setup failing to a trusted domain with a no logon servers available error (we will cover that error in another post). As you can see though, a LOT of data is reported.
image
For reference, a full reference to the debug flags and what they give you can be found at the bottom of http://support.microsoft.com/kb/109626.

Netlogon.log Maximum File Size:

If your issue is intermittent, or spans longer intervals, you may wish to increase the maximum log file size for the Netlogon.log and Netlogon.bak file to help ensure pertinent data is not overwritten.
The default size of the Netlogon.log (and Netlogon.bak) is 200,000 bytes (~20MB), and this can be increased up to 4GB (4294967295 bytes) at its maximum (I do not recommend you actually ever make it this large). If you are increasing the maximum log file size, double and triple check your disk space to ensure you are setting a reasonable size and will not stress your disk space.
You can also increase the maximum log file size by setting the MaximumLogFileSize DWORD value in the registry in HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. The value data should contain the maximum log file size in bytes (decimal).
Alternatively, you can use group policy and configure the Maximum Log File Size setting under Computer Configuration\Administrative Templates\System\Net Logon.

Let’s dig into the errors!

Now that my longer than expected due diligence is done, let’s start discussing some of the errors and warnings you may encounter within the Netlogon log….
Status/Return Code
Technical Meaning
English Translation

0xC000005E

STATUS_NO_LOGON_SERVERS

You cannot reach a domain controller!
This error tends to be the number one cause of some VERY expensive outages at companies that occur. It is commonly reported in errors as: “There are currently no logon servers available to service the logon request”. Due to its potential impact, I will go a bit more into depth on this error…and hopefully NOT bore you to sleep in the process.
When and IF you have a MCA (MaxConcurrentAPI) issue, this is likely what you will see littering your Netlogon logs, and potentially your event logs as well. A MaxConcurrentAPI (MCA) issue occurs when the threads within lsass.exe that handle NTLM authentication (as well as Kerberos PAC validation) begin to time out. This takes 45 seconds, as measured on a thread by thread basis (just consider the thread an authentication attempt to make it easier). Once this timeout occurs, you throw the 0xC000005E error, and logon fails. MCA issues will stand out from the crowd of data in the Netlogon log with a [CRITICAL] line stating “can’t allocate client API slot” (see example below). If you see this, you have a MCA issue, and you might as well skip straight to the common causes now J
MCA example (this is not the only indicator, but is a dead giveaway):
6/3 14:17:43 [CRITICAL] FakeDomain: NlAllocateClientApi timed out: 0 258
6/3 14:17:43 [CRITICAL] FakeDomain: NlpUserValidateHigher: Can't allocate Client API slot.
If you don’t see this message, continue reading….
This error does not however always indicate a MCA issue is occurring! There are also some common causes, such as trusts that exist with decommissioned domains (or trusts with domains that cannot be contacted for another reason). Since I went with this example, I may as well tell you that it will result in the same error code in the logs, along with 5719 events in your System event log from Netlogon indicating the trusted domain could not be contacted.
Another example would be a client with an invalid DNS configuration. This DNS configuration can in turn cause the client to not be able to find the domain and domain controller, which would also leave us with a “no logon servers available” error. NOTE: “Client” in this context can be a workstation, member server, or even another domain controller.
The list below covers some common causes for the notorious “no logon servers are available…” error message, and in some cases, suggestions for implementing a fix:
1. DNS forwarders (if crossing domain/forest boundaries) – maybe somebody forgot to update the IP when it was changed on a target domain/forest DNS server
a. Correct any “catch all” forwarders (Windows 2000) to point to the target forest’s DNS servers in the sending domain’s DNS configuration (also validate and correct the other end) -OR-
b. Correct any conditional forwarders (Windows 2003 and above) for the target forest in the sending domain’s DNS configuration (also validate and correct the other end)
REFERENCES:
How to configure DNS for internet access in Windows 2000: http://support.microsoft.com/kb/300202 (see the section labeled “To configure forwarders”)
Assign a conditional forwarder for a domain name (Windows 2008/2008 R2): http://technet.microsoft.com/en-us/library/cc794735(v=WS.10).aspx
Conditional Forwarding in Windows Server 2003: http://support.microsoft.com/kb/304491 (provides a good explanation of forwarding in general)
2. DNS records (A, AAAA, SRV) for domain controllers in the target domain may be missing or incorrect
a. Validate DNS records exist for the target domain controllers (A and SRV)
b. Restart the Netlogon service on the target domain’s domain controllers and allow up to 15 minutes for the DNS records to occur
c. If necessary, attempt to manually create the DNS records (NOTE: This should not be considered a permanent solution)
i. If you had to manually recreate the DNS records, you still need to troubleshoot why you failed to dynamically register the applicable records.
3. 1B/1C WINS records for domain controllers in the target domain may be missing or incorrect (see: http://support.microsoft.com/kb/139410)
a. Registration of WINS records may be failing
b. WINS replication may be broken
c. Incorrect static WINS records may exist
d. You may have conflicting entries in your LMHOSTS (or HOSTS) file
4. You may have invalid entries in your HOSTS and/or LMHOSTS files for the domain name, domain controller name, 1B record, or 1C record
a. Correct or remove the conflicting entry in your HOSTS or LMHOSTS file
5. You may be experiencing network timeouts due to faulty or misconfigured network hardware (ex: black hole router or MTU size set too small)
a. Follow KB314825 (http://support.microsoft.com/kb/314825) to determine if a black hole router is a potential culprit (this will also help you determine the MTU size)
b. Spanning tree protocol may be enabled at the hardware level (switch, router, etc) with PortFast disabled
i. Enable PortFast
c. VPN tunnel, router, or switch may be having hardware issues
6. SYSVOL and Netlogon may not be shared on the domain controller a connection attempt was made to (see: http://support.microsoft.com/kb/257338)
7. Network issues
a. Capture network traffic:
i. Check for excessive packet fragmentation
ii. Check for dropped packets
b. Disable SNP features per http://support.microsoft.com/kb/948496 in the registry and at the NIC driver level
8. You may be logging onto a RODC that does not have connectivity to a writeable DC (see: http://support.microsoft.com/kb/949048)
9. Logical site names in Active Directory may not match in the source and target forests (applicable only when DNS is used for cross domain name resolution)
a. If the site names are the same, then domain controller covering the site:
i. May be down/restarting
ii. No domain controllers are covering the site automatically (if no domain controller is assigned to the logical site)
iii. DNS SRV records may be missing
Perhaps I should clarify a bit on #9 above…
When DNS is used to perform a domain controller lookup in a target domain/forest, it will query for the logical site name of the requesting machine. If that site does not exist in the target forest with the exact name, spelling, etc, then Windows will default to performing a basic LDAP record lookup against the domain. This in turn can lead us to stray to locations for authentication by a domain controller that we may not want to stray to (for instance, a domain controller across a very slow link). If however you DO have a site name that is the exact same in the target forest, then LDAP SRV record lookups will occur against those domain controllers (or any registered for auto site coverage).
Status/Return Code
Technical Meaning
English Translation

0xC0000022 (or 0x00000005 (0x5))

STATUS_ACCESS_DENIED

It’s pretty easy to recognize the error here (access denied), but it can be more difficult to find the cause!
In addition to the seeing this error code in the Netlogon log, you may also see this error code logged in Netlogon error events within the System event log (commonly a 5722). Since the 0x5 error is so common, I also included a few additional possibilities outside of the scope of Netlogon.
Common causes:
1. You are attempting to join a machine who’s name already exists in Active Directory
2. Secure channel may be broken
a. Reset secure channel
i. nltest /sc_reset:<domainname>
OR
b. Rejoin domain
3. Trust password may be mismatched
a. Reset trust password
i. nltest /sc_change_pwd:<domainname>
4. Incorrect credentials may have been used (0x5)
a. Enter the appropriate credentials
5. NTLM blocking may be enabled
NOTE: NTLM blocking is only available in Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012
a. Disable NTLM blocking immediately and perform NTLM auditing
i. For Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 you can use the NTLM Auditing abilities built into the operating system (see: http://blogs.technet.com/b/askds/archive/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7.aspx)
ii. Once you have COMPLETELY eliminated NTLM authentication, you may re-enable NTLM blocking
Some other potential causes:
6. LM compatibility level mismatch
a. LMCompatibilityLevel must be at a level where authentication can be negotiated between the source and target (whether that is LM, NTLM, or NTLMv2). For example, a setting of 0 on the client and 5 on a domain controller or target server will result in an inability to negotiate a valid authentication mechanism.
b. This must be reviewed on the source/sender and the target/receiver.
i. You can find the current setting by looking in the registry at HKLM\SYSTEM\CurrentControlSet\Control\Lsa. The value is named LMCompatibilityLevel (if by chance you are still REALLY old school and are running Win9x, the value is named LMCompatibility).
ii. Valid values are 0 – 5
c. Reference table of the settings:
LMCompatibilityLevel Value
Behavior Result
0
(Send LM & NTLM responses)
· Clients can use LM or NTLM authentication, but will not use NTLMv2 session security
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
1
(Send LM & NTLM–use NTLMv2 session security if negotiated)
· Clients can use LM or NTLM authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
2
(Send NTLM response only)
· Clients use only NTLM authentication, and use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
3
(Send NTLMv2 response only)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
4
(Send NTLMv2 response only\refuse LM)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow NTLM or NTLMv2 authentication, and will refuse LM authentication
5
(Send NTLMv2 response only\refuse LM & NTLM)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow only NTLMv2 authentication, and will refuse LM or NTLM authentication
image
d. The settings, if they are incompatible, can be configured in two ways:
i. Using group policy (recommended) –
NOTE: For this example, I will assume we are using a domain level policy. The same method applies for policies at the Domain Controllers OU level, or any other.
1. Open the policy for editing using GPMC, AGPM, or Active Directory Users and Computers (whichever method you use typically)
2. Expand Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
3. Double click the “Network security: LAN Manager authentication level” setting and change it to the desired value
4. Allow time for replication (or force replication) if necessary
5. DON’T FORGET TO UPDATE YOUR POLICY! (gpupdate /force)
ii. In the registry (this may be overwritten by group policy settings) –
1. HKLM\SYSTEM\CurrentControlSet\Control\Lsa
2. Double click the LMCompatibilityLevel registry value
3. Set the value to the desired setting (as described in the above reference table)
7. User rights assignment configuration (allow access from the network) (0x5)
a. User rights assignments are located in Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
i. Alteration of either of the following user rights can result in an access denied:
1. Access this computer from the network
a. The default setting for Access this computer from the network is:
i. Workstations and servers:
1. Administrators
2. Backup Operators
3. Power Users
4. Users
5. Everyone
ii. Domain controllers:
1. Administrators
2. Authenticated Users
3. Everyone
2. Deny access to this computer from the network
a. The setting for Deny access to this computer from the network overrides the Access this computer from the network user right.
i. OOB, nothing is defined.
1. A typical security measure is to add the Guest account and/or the Guests group
8. Incompatible SMB signing options between the source and target machine
a. If a SMB connection is being made, SMB signing options must be compatible or it may result in an access denied error.
i. If you require SMB signing on the target, yet have it disabled on the source, then connectivity will be affected (and vice versa).
b. You can validate SMB signing options in the registry at:
i. HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
1. EnableSecuritySignature – this value defines whether SMB signing can be used and corresponds to the group policy setting “Microsoft network client: Digitally sign communications (if server agrees)”
2. RequireSecuritySignature – this value defines whether SMB signing is required and corresponds to the group policy setting “Microsoft network client: Digitally sign communications (always)”
ii. HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
1. EnableSecuritySignature – this value defines whether SMB signing can be used and corresponds to the group policy setting “Microsoft network server: Digitally sign communications (if client agrees)”
2. RequireSecuritySignature – this value defines whether SMB signing is required and corresponds to the group policy setting “Microsoft network server: Digitally sign communications (always)”
c. If you need to make a correction to the settings, there are two methods:
i. Using group policy (recommended) –
1. Open the policy for editing using GPMC, AGPM, or Active Directory Users and Computers (whichever method you use typically)
2. Expand Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
3. Double click the “Microsoft network client: Digitally sign communications (if server agrees)” setting and change it to the desired value
4. Double click the “Microsoft network client: Digitally sign communications (always)” setting and change it to the desired value
5. Double click the “Microsoft network server: Digitally sign communications (if client agrees)” setting and change it to the desired value
6. Double click the “Microsoft network server: Digitally sign communications (always)” setting and change it to the desired value
7. Allow time for replication (or force replication) if necessary
8. DON’T FORGET TO UPDATE YOUR POLICY! (gpupdate /force)
ii. Using the registry (may be overwritten by group policy settings) –
1. Browse to HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
2. Double click the EnableSecuritySignature registry value and set the value to the desired setting (0 = disabled; 1=enabled)
3. Double click the RequireSecuritySignature registry value and set the value to the desired setting (0 = disabled; 1=enabled)
4. Browse to HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
5. Double click the EnableSecuritySignature registry value and set the value to the desired setting (0 = disabled; 1=enabled)
6. Double click the RequireSecuritySignature registry value and set the value to the desired setting (0 = disabled; 1=enabled)
9. Secure channel may be in the process of resetting (client reset its secure channel) when an authentication is attempted
a. This should clear itself up, providing the secure channel reset succeeds successfully
10. Active Directory replication to/from the target domain controller
a. There may have been recent changes that have not replicated across domain controllers (a recent secure channel reset, a group policy change, etc.)
11. You may not be applying group policy properly
a. Examine the Event Viewer to analyze group policy application
i. If necessary, enable diagnostic logging for group policy (gpsvc.log; userenv.log; winlogon.log)
12. References:
Status/Return Code
Technical Meaning
English Translation

0xC0000064

STATUS_NO_SUCH_USER

The username you typed does not exist!
The most common cause of this is pretty straightforward:
1. Incorrect username was used
a. Verify the username you are using is typed correctly
Some other possibilities include:
2. Active Directory replication to/from the target domain controller may not be complete (ex: new user creation)
a. This may indicate problems with Active Directory Replication, FRS, or DFSR
3. Domain controller may be in the process of shutting down or restarting when the connection is made (see: http://support.microsoft.com/default.aspx?scid=kb;EN-US;973667)
4. If running Windows 2008 SP2, you may be experiencing the problem described in http://support.microsoft.com/default.aspx?scid=kb;EN-US;982801
5. Target domain controller resource load (high lsass.exe utilization, high memory consumption, paged for example)
a. Use Performance Monitor, Resource Monitor, or Xperf to analyze the performance of the system and identify the problem
i. Examples:
1. Paged pool memory exhaustion
2. Physical memory exhaustion
3. High CPU
Status/Return Code
Technical Meaning
English Translation

0xC000018A

STATUS_NO_TRUST_LSA_SECRET

Your connection to the domain is broken from this machine!
The most common causes are:
1. Secure channel corruption with the host or target domain’s domain controllers
a. Reset the secure channel (nltest /sc_reset:<domainname>
2. The computer object has been deleted from Active Directory
a. Rejoin the domain
i. You may need to reinstall applications as a result of rejoining the domain
Some of the other potential causes are:
3. Blocked ports on a firewall
a. Ensure all required ports for domain functionality are enabled per http://support.microsoft.com/kb/832017 or http://support.microsoft.com/kb/179442
4. Active Directory Replication may not be complete (if the computer has been recently joined to the domain)
Status/Return Code
Technical Meaning
English Translation

0xC000006D

STATUS_LOGON_FAILURE

Your logon failed!
Some of the potential causes for this
1. An invalid username and/or password was used
a. Verify you are using the correct username or password
2. LM Compatibility mismatch between the source and target
b. LMCompatibilityLevel must be at a level where authentication can be negotiated between the source and target (whether that is LM, NTLM, or NTLMv2). For example, a setting of 0 on the client and 5 on a domain controller or target server will result in an inability to negotiate a valid authentication mechanism.
c. This must be reviewed on the source/sender and the target/receiver.
i. You can find the current setting by looking in the registry at HKLM\SYSTEM\CurrentControlSet\Control\Lsa. The value is named LMCompatibilityLevel (if by chance you are still REALLY old school and are running Win9x, the value is named LMCompatibility).
ii. Valid values are 0 – 5
d. Reference table of the settings:
LMCompatibilityLevel Value
Behavior Result
0
(Send LM & NTLM responses)
· Clients can use LM or NTLM authentication, but will not use NTLMv2 session security
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
1
(Send LM & NTLM–use NTLMv2 session security if negotiated)
· Clients can use LM or NTLM authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
2
(Send NTLM response only)
· Clients use only NTLM authentication, and use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
3
(Send NTLMv2 response only)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
4
(Send NTLMv2 response only\refuse LM)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow NTLM or NTLMv2 authentication, and will refuse LM authentication
5
(Send NTLMv2 response only\refuse LM & NTLM)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow only NTLMv2 authentication, and will refuse LM or NTLM authentication
image
e. The settings, if they are incompatible, can be configured in two ways:
i. Using group policy (recommended) –
NOTE: For this example, I will assume we are using a domain level policy. The same method applies for policies at the Domain Controllers OU level, or any other.
1. Open the policy for editing using GPMC, AGPM, or Active Directory Users and Computers (whichever method you use typically)
2. Expand Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
3. Double click the “Network security: LAN Manager authentication level” setting and change it to the desired value
4. Allow time for replication (or force replication) if necessary
5. DON’T FORGET TO UPDATE YOUR POLICY! (gpupdate /force)
ii. In the registry (this may be overwritten by group policy settings) –
1. HKLM\SYSTEM\CurrentControlSet\Control\Lsa
2. Double click the LMCompatibilityLevel registry value
3. Set the value to the desired setting (as described in the above reference table)
3. Time difference between the source and target is greater than 30 minutes (NTLMv2 only)
a. Ensure the source and target are within a 30 minute time skew
i. Synchronize time if necessary: w32tm /resync
4. Secure channel may be broken
a. Reset the secure channel (nltest /sc_reset:<domainname>
Status/Return Code
Technical Meaning
English Translation

0xC000009A

STATUS_INSUFFICIENT_RESOURCES

You have resource issues on your system that is preventing Netlogon from connecting or operating properly!
Some potential causes for this error are:
1. Available physical memory exhaustion
2. Paged pool or non-paged pool memory exhaustion
3. Free System PTE (Page Table Entries) exhaustion
To troubleshoot this issue, use Performance Monitor, Resource Monitor, Xperf, or other performance diagnostics tool.
Status/Return Code
Technical Meaning
English Translation

0xC0020050 (Decimal -1073610672)

RPC_NT_CALL_CANCELLED

RPC communications are having problems that need to be resolved!
This issue can be difficult to track down. Some of the potential causes are:
1. Verify Scalable Networking Pack (SNP) features are disabled in the registry as well as in the driver/hardware settings
a. The driver level settings must be disabled via the configuration for the NIC itself (NOTE: Support for this action comes from the hardware vendor)
i. Access the NIC properties
ii. Click the Configure button next to the network adapter name
iii. Click the Advanced tab
1. Identify the setting for the chimney offload (typically called “Large Send Offload” or “TCP Offload Engine”) and set it to disabled
2. Identify the setting for Receive Side Scaling and set it to disabled
3. Identify the setting for TCPA or NetDMA and set it to disabled
b. This can be disabled in the registry at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
i. EnableTCPChimney – this value enables and disables the TCP Chimney Offload feature (0 = disabled; 1 = enabled)
ii. EnableRSS – this value enables and disables Receive Side Scaling (0 = disabled; 1 = enabled)
iii. EnableTCPA – this value enables and disables NetDMA (TCPA) functions (0 = disabled; 1 = enabled)
2. RPC ephemeral port closures or limitations
a. Validate RPC related ports are open using portquery or another similar tool
3. 3rd party antivirus or endpoint protection product may be blocking ephemeral communications
a. Try uninstalling the antivirus or endpoint protection product to see if it changes the behavior
4. Network issue causing packet timeouts/drops (bad switch port, router, etc)
5. RPC bind time negotiation failure
a. Disable bind time negotiation per http://support.microsoft.com/kb/899148
6. No network path exists to the target domain controller or machine
7. Verify RPC interface restrictions are not in place, and if they are, that they are compatible (see: http://technet.microsoft.com/en-us/library/cc781010(WS.10).aspx)
8. LMCompatibilityLevel may be incompatible between the source and target
a. LMCompatibilityLevel must be at a level where authentication can be negotiated between the source and target (whether that is LM, NTLM, or NTLMv2). For example, a setting of 0 on the client and 5 on a domain controller or target server will result in an inability to negotiate a valid authentication mechanism.
b. This must be reviewed on the source/sender and the target/receiver.
iii. You can find the current setting by looking in the registry at HKLM\SYSTEM\CurrentControlSet\Control\Lsa. The value is named LMCompatibilityLevel (if by chance you are still REALLY old school and are running Win9x, the value is named LMCompatibility).
iv. Valid values are 0 – 5
c. Reference table of the settings:
LMCompatibilityLevel Value
Behavior Result
0
(Send LM & NTLM responses)
· Clients can use LM or NTLM authentication, but will not use NTLMv2 session security
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
1
(Send LM & NTLM–use NTLMv2 session security if negotiated)
· Clients can use LM or NTLM authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
2
(Send NTLM response only)
· Clients use only NTLM authentication, and use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
3
(Send NTLMv2 response only)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow LM, NTLM, or NTLMv2 authentication
4
(Send NTLMv2 response only\refuse LM)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow NTLM or NTLMv2 authentication, and will refuse LM authentication
5
(Send NTLMv2 response only\refuse LM & NTLM)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
· Domain Controllers will allow only NTLMv2 authentication, and will refuse LM or NTLM authentication
image
d. The settings, if they are incompatible, can be configured in two ways:
v. Using group policy (recommended) –
NOTE: For this example, I will assume we are using a domain level policy. The same method applies for policies at the Domain Controllers OU level, or any other.
1. Open the policy for editing using GPMC, AGPM, or Active Directory Users and Computers (whichever method you use typically)
2. Expand Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
3. Double click the “Network security: LAN Manager authentication level” setting and change it to the desired value
4. Allow time for replication (or force replication) if necessary
5. DON’T FORGET TO UPDATE YOUR POLICY! (gpupdate /force)
vi. In the registry (this may be overwritten by group policy settings) –
1. HKLM\SYSTEM\CurrentControlSet\Control\Lsa
2. Double click the LMCompatibilityLevel registry value
3. Set the value to the desired setting (as described in the above reference table)
9. SMB signing settings may be incompatible
a. If a SMB connection is being made, SMB signing options must be compatible
i. If you require SMB signing on the target, yet have it disabled on the source, then connectivity will be affected (and vice versa).
b. You can validate SMB signing options in the registry at:
i. HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
1. EnableSecuritySignature – this value defines whether SMB signing can be used and corresponds to the group policy setting “Microsoft network client: Digitally sign communications (if server agrees)”
2. RequireSecuritySignature – this value defines whether SMB signing is required and corresponds to the group policy setting “Microsoft network client: Digitally sign communications (always)”
ii. HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
1. EnableSecuritySignature – this value defines whether SMB signing can be used and corresponds to the group policy setting “Microsoft network server: Digitally sign communications (if client agrees)”
2. RequireSecuritySignature – this value defines whether SMB signing is required and corresponds to the group policy setting “Microsoft network server: Digitally sign communications (always)”
c. If you need to make a correction to the settings, there are two methods:
i. Using group policy (recommended) –
1. Open the policy for editing using GPMC, AGPM, or Active Directory Users and Computers (whichever method you use typically)
2. Expand Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
3. Double click the “Microsoft network client: Digitally sign communications (if server agrees)” setting and change it to the desired value
4. Double click the “Microsoft network client: Digitally sign communications (always)” setting and change it to the desired value
5. Double click the “Microsoft network server: Digitally sign communications (if client agrees)” setting and change it to the desired value
6. Double click the “Microsoft network server: Digitally sign communications (always)” setting and change it to the desired value
7. Allow time for replication (or force replication) if necessary
8. DON’T FORGET TO UPDATE YOUR POLICY! (gpupdate /force)
ii. Using the registry (may be overwritten by group policy settings) –
1. Browse to HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
2. Double click the EnableSecuritySignature registry value and set the value to the desired setting (0 = disabled; 1=enabled)
3. Double click the RequireSecuritySignature registry value and set the value to the desired setting (0 = disabled; 1=enabled)
4. Browse to HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
5. Double click the EnableSecuritySignature registry value and set the value to the desired setting (0 = disabled; 1=enabled)
6. Double click the RequireSecuritySignature registry value and set the value to the desired setting (0 = disabled; 1=enabled)
10. NIC drivers may need to be updated
Status/Return Code
Technical Meaning
English Translation

0xC0000017

STATUS_NO_MEMORY

 

You have an out of memory condition on the system or in RPC
This error code is typically reported in errors as “Not enough storage is available to process the command”. This has the side effect, based on the friendly error description, of sending people down the wrong path in troubleshooting. Don’t fear, this error description does not mean you are low on disk space J It means you probably have memory or port contention issues, hooray!
Some potential causes of this error are:
1. Domain controller, client, or target server may have exhausted virtual memory/page file or physical memory
a. Check your available memory – if it’s extremely low then you may need to consider adding more RAM and identifying the offending process
NOTE: For busy x64 domain controllers, if you have a large ntds.dit (Active Directory database), but have less RAM than the size of the dit file, you may experience performance degradation and high lsass utilization (memory and processor) that could lead to this error. If you have busy x86 domain controllers that are running and peak memory utilization, it may be time to consider upgrading to a 64 bit version of Windows to prevent excessive trimming. Remember, lsass caches search results it returns which adds to its memory utilization! For 64 bit versions of Windows, I recommend Windows Server 2008, Windows Server 2008 R2, or better yet, Windows Server 2012 J
b. Check your page file usage with Performance Monitor – if it’s extremely high at most times (90%+) consider increasing the page file size or adding more RAM
c. Look for handle leaks with Performance Monitor, Resource Monitor, or Task Manager
2. User ports may be exhausted (see: http://support.microsoft.com/kb/196271)

Status/Return Code
Technical Meaning
English Translation

0xC0000192

STATUS_NETLOGON_NOT_STARTED

 

The Netlogon service is not started or the Domain Controller is not advertising!
This error code is typically pretty straight forward to troubleshoot as there isn’t much that will cause it.
Some potential causes of this error are:
1. The Netlogon service is not started on the application server or domain controller.
a. Check each tier of the authentication chain and start the Netlogon service
2. Sysvol and/or Netlogon is not shared on the Domain Controller
a. In these situations, the Netlogon logs should contain entries stating “Sysvol not ready”. If you see this, your problem is that one or more Domain Controllers are not advertising themselves as a Domain Controller because the SYSVOL and/or Netlogon shares are not yet shared.
b. To troubleshoot this issue, you can review http://support.microsoft.com/kb/257338 on how to troubleshoot missing SYSVOL and Netlogon shares.
c. If you find than a large number (or all) Domain Controllers do not have SYSVOL and/or Netlogon shared, you may need to resort to using Burflags values to set D2 or D4. Remember, if you use D4, you must D2 all other DCs! For more on how to utilize Burflags, please see http://support.microsoft.com/kb/315457 and/or http://support.microsoft.com/kb/290762.

Some of the more common, but self-explanatory errors are listed below:
Status/Return Code
Technical Meaning
English Translation

0xC000006E

 

STATUS_ACCOUNT_RESTRICTION

1. The username and password are correct, but there is an account restriction on the user account (such as valid workstation, valid logon hours, etc.). The value under SubStatus should provide the restriction details.
2. Active Directory Replication may not be complete

0xC000006C

STATUS_PASSWORD_RESTRICTION

User is attempting to reset password and it does not meet requirements specified by policy (length, history, complexity)

0xC0000070

STATUS_INVALID_WORKSTATION

1. The user is trying to logon from a machine they aren’t assigned to.
2. Active Directory replication may not be complete

0xC000006A

STATUS_WRONG_PASSWORD

1. Oops, you typed the wrong password!
2. PDC Emulator cannot be contact to validate the password (for recent password changes)
3. Active Directory Replication to/from the target domain controller

0xC0000193

STATUS_ACCOUNT_EXPIRED

1. Your user account is expired!
2. Active Directory Replication may not be complete

0xC0000071

STATUS_PASSWORD_EXPIRED

1. Your password is expired!
2. Active Directory Replication may not be complete

0xC000006F

STATUS_INVALID_LOGON_HOURS

1. You are set with logon hours restrictions and have attempted to logon outside of those time restrictions
2. Active Directory Replication may not be complete

0xC0000234

STATUS_ACCOUNT_LOCKED_OUT

1. Your user account is locked out!
2. Active Directory Replication may not be complete

0xC0000072

STATUS_ACCOUNT_DISABLED

1. Your user account is disabled!
2. Active Directory Replication may not be complete

0xC00000DC (Decimal -1073741604)

STATUS_INVALID_SERVER_STATE

Domain controller may be shutting down or restarting (see: http://support.microsoft.com/kb/942636 or http://support.microsoft.com/kb/973667)

0xC0000224

STATUS_PASSWORD_MUST_CHANGE

1. User has the “user must change password at next logon flag set. Time to change your password!
2. Active Directory Replication may not be complete


UPDATES!

With the introduction of Message Analyzer 1.1, you can now troubleshooting Netlogon logs through Message Analyzer using the Netlogon parser! I won’t go into detail in this blog on the who, what, where, and how (ok, maybe a little on the “where”) because I’ve already done that elsewhere (see the links below). Needless to say, Message Analyzer is a must have tool for your arsenal. Here are some links to get you started:
Message Analyzer v1.1 download
Introducing the Netlogon Parser (v1.0.1) for Message Analyzer 1.1
Troubleshooting Basics for the Netlogon Parser (v1.0.1) for Message Analyzer
Quick Reference: Troubleshooting Netlogon Error Codes
Quick Reference: Troubleshooting, Diagnosing, and Tuning MaxConcurrentApi Issues
Message Analyzer Forum
Message Analyzer blog site
Roaming AD Clients, with an Updated Script
Back to
top

Join the conversation

Add Comment

  1. Reply

    Anonymous
    this blog entry ROCKS, thanks a lot for this !!
  2. Well Mike, TBH I kind of blank out while writing and more time goes by than I know 🙂 In this case, I would say around 20 hrs between the content, updating, peer review, more updating, and finally getting to its current state.
    I'm glad to hear you liked the blog 🙂
  3. For Premier customers, we also have a 2.5 hr webcast available on this topic called "Troubleshooting Netlogon for NTLM Auth" that covers this blog content and much more. If you have interest, contact your TAM for more information.
  4. That is a Deep Dive 🙂
    Thank you so much
    Regards

  5. Reply

    Anonymous
    Hi,
    regarding the error “STATUS_INVALID_SERVER_STATE”: Both the links refer to Server 2003, but what can I do on Server 2008 R2 SP1?
    A shutdown script to stop netlogon Service failed, it didnt stop the Service.
    Thanks
    Walter
  6. We have sessions planned for 4/26/13 and 5/31/13. Hope to you see you there!

  7. Reply

    Anonymous
    Hi Mark,
    Nice Post – very useful . Is there a 100% completly definative list of ALL the Netlogon Status / Return codes that can be published ?
    cheers,
    Andy
    PS Nice Hat.
  9. Hi Walter-
    That particular state being recorded in the netlogon logs in Win2008 R2 should allow a client system to bind to another domain controller to continue its efforts (if the client is Win2003, it requires the hotfixes mentioned in this blog to do this). The links within this article describe behavior that should be built into Windows Server 2008, 2008 R2, 2012, and 2012 R2.
    That status itself is typically thrown when the server (or Netlogon service) is in the process of shutting down already.
    Its a potential state of the service itself; the real problem with this status is that systems, depending on the OS level, may not appropriately handle the status and move on to another domain controller to continue authentication or secure channel functions.
    May I ask what the actual issue you are facing is?

  10. Reply

    Mike Kline
    "Quick Reference" made laugh.  Excellent blog Brandon!  Out of curiosity how long does something like this take you to write?
    Thanks
    Mike
  11. Hi Andy-
    As far as I know, there isn't any single one resource out there that contains all of the Netlogon error codes. Actually, that is one of the reasons I wrote this blog, to provide the common error codes that cause the most issues. Most of the error codes do happen to be common though, so as a result, not that many are missing from this blog.
    With that being said, I will expand this blog to contain all of the error codes for Netlogon that I can find in the near future.
    Thanks for your input, and a great suggestion for the blog!
    -Brandon Wilson
  13. Hi Kevin-
    My initial thought is that it likely isn’t the cause of the 5719. When is the 5719 occurring? At machine startup? Randomly/periodically? For your own domain or a trusted domain? Are you seeing this on a member server/client or the DC?
    I’ve noticed that behavior you described before myself, but in testing I’ve done, I’ve never seen an actual packet go out querying for the DC name (as the domain). I will look further into this behavior of an apparent DsGetDcName call directly to the DC name.

  14. Reply

    Awinish
    Amazing stuff Brandon. I haven't witness such a comprehensive material on Netlogn.

  15. Reply

    Mark Taylor
    Nice article.  wish I'd had this a couple of years ago.
    The one item i consistently see in netlogon.log when the network appears to have gone south  is:
    11/03 08:16:01 [SESSION] CONTOSO:I_NetLogonGetAuthData called: (null) contoso.com (Flags 0x1)
    I would love to know what is going on with this entry.  I only see it when we have issues and would like to know more about what it means.
  16. Hi Mark-
    Sorry for the late reply…
    It would be easier to have the context around the message there, however this is essentially telling you that Netlogon is trying to contact a DC to send authentication data to; when there is a problem, I would expect to see a similar line with a failure code in it very soon after it is logged. That failure code is a starting point to discovering the root cause.

  17. Reply

    Karim
    Thank you for this blog! This is awesome.

  18. Reply

    Anonymous
    Hi this is Brandon Wilson again. In my newest “Quick Reference” (get the joke?), we will

  19. Reply

    Sean Sobey
    Lately a few System admins are noticing Chinese characters in the netlogon.log. The Microsoft PFE team states the following about it.
    This does not represent any issue as far as I am aware. This occurs because uplevel operating systems (such as Windows 8/8.1/2012/2012 R2) sends additional parameters that are not understood by lower level operating systems (Windows 2000/XP/2003/Vista/2008/7/2008
    R2).
    For instance, a Windows 8 client in a Windows 2008 R2 domain will attempt to send an additional parameter to the domain controller running Windows Server 2008 R2 that will result in this message being logged in the Netlogon log on the domain controller:

  20. Reply

    Kevin
    I cant find the answer to this question anywhere why does netlogon do a dns query for the domain controller name
    so for example if i have a dc called w2k8-dc1.fakedomain.com
    i get dns errors for _ldap._tcp.mysite._sites.w2k8-dc.fakedomain.com
    should it not be doing a lookup for _ldap._tcp.mysite._sites.fakedomain.com
    i am not sure if this is causing my issue which is the 5719 errors group policy not applying and eventually
    i wont be able to login to the server with my domain account

  21. Reply

    Jordan
    Excellent article and quite informative. We still don’t have a concrete RCA on this. I hope with this information we will be able to solve the problem that has been plaguing us from a while. .

  22. Reply

    Adrian Ilias
    For 0xC0000064 error we had a situation not described here.
    The user was a local user from a server (W2008 R2) that had the option "User must change the password to next logon" checked. The errors in netlogon was generated by a network map access to a local share on the same server that have the above local user. The
    access actually worked, we just had the 0xC0000064 errors (user doesn’t exist) in netlogon log file.

  23. Reply

    Skip Benson
    for this error (0xC000006D STATUS_LOGON_FAILURE)
    check the server date and time!
  24. @Skip-
    A time difference of +/- 30 minutes has the capability to kick off multiple errors for NTLM authentication. However a 6D is the most common, and is covered above under the 0xC000006D section.
    Do a find in the browser and search for "30 minutes" (no quotes) and it should take you right to it 🙂

Comments

Post a Comment

Popular posts from this blog

altiris software key

-
Image
I think a lot of people, like me, spend a lot of time try finding how to get those download: Latest Symantec workspace Virtualization , SWV 6.1, that is advanced SVS version, is integrated with the Altiris client management suite CMS 7.  (Yes, it was also named "SVS PRO") Notice 1: This package includes the "Wise Virtual Composer", and both x86+x64 versions. Notice 2: This link currently also includes SWS (Streaming) and SWC (Corporate) [please vote my post if you use it ;-] Story : I was thinking only SVS 2.1 (Software Virtualization Solution) was integrated into the "Client Management Suite 7". But this is not the case and SWV 6.1 (Symantec Workspace Virtualization) must not be paid in addition . Free home license : Both SVS 2.1 "light" version & SWV are still free personal use. I suggest you use now the latest SWV 6.4 (That is SWV 6.1 SP7 or following! Yes Symantec do this version naming - vote here also to a...
Read more

Service Principal Names (SPNs) SetSPN Syntax (Setspn.exe)

-
Image
Service Principal Names (SPNs) SetSPN Syntax (Setspn.exe) Table of Contents SPN Purpose SPN Format SetSPN Viewing or Checking SPN Registrations SPN Registration Errors Related to SPN Registration or Configuration Manually Registering SPNs Troubleshooting SPN Issues Resolving SPN Registration Issues SPN Lookup Errors Delegation External Articles SPN Purpose A service principal name (SPN) is the name by which a Kerberos client uniquely identifies an instance of a service for a given Kerberos target computer. If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. ↑  Return to T...
Read more