First published on TechNet on Jan 28, 2013
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.
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 the Core Infrastructure and Security TechCommunity blog.
Where do I enable the Netlogon logging?
How do I enable verbose Netlogon logging?
Differences between logging level verbosity:
Netlogon.log Maximum File Size:
0xC000005E STATUS_NO_LOGON_SERVERS
0xC0000022 (or 0x00000005 (0x5)) STATUS_ACCESS_DENIED
0xC0000064 STATUS_NO_SUCH_USER
0xC000018A STATUS_NO_TRUST_LSA_SECRET
0xC000006D STATUS_LOGON_FAILURE
0xC000009A STATUS_INSUFFICIENT_RESOURCES
0xC0020050 (Decimal -1073610672) RPC_NT_CALL_CANCELLED
0xC000006E STATUS_ACCOUNT_RESTRICTION
0xC000006C STATUS_PASSWORD_RESTRICTION
0xC0000070 STATUS_INVALID_WORKSTATION
0xC000006A STATUS_WRONG_PASSWORD
0xC0000193 STATUS_ACCOUNT_EXPIRED
0xC0000192 STATUS_NETLOGON_NOT_STARTED
0xC0000071 STATUS_PASSWORD_EXPIRED
0xC000006F STATUS_INVALID_LOGON_HOURS
0xC0000234 STATUS_ACCOUNT_LOCKED_OUT
0xC0000072 STATUS_ACCOUNT_DISABLED
0xC00000DC (Decimal -1073741604) STATUS_INVALID_SERVER_STATE
0xC0000224 STATUS_PASSWORD_MUST_CHANGE
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”
b. To disable Netlogon logging, run the following command (w/o quotes): “nltest /DBFlag:0x0”
2. From the “Microsoft Fix it” button:
a. Browse to http://support.microsoft.com/kb/109626
b. Scroll down to the “Fix it for me” section
c. Click the appropriate “Microsoft Fix it” button to enable or disable Netlogon logging
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.
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
Configure forwarders for a DNS server : http://technet.microsoft.com/en-us/library/cc755608(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: https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/ntlm-blocking-and-you-applica...
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 |
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:
a. Nltest syntax reference: http://technet.microsoft.com/en-us/library/cc731935(v=WS.10).aspx
|
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
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 |
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)
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:
|
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)
NOTE: For Windows Server 2008 and above, you must use netsh to enable or disable the SNP features as covered in https://support.microsoft.com/en-us/help/951037/information-about-the-tcp-chimney-offload-receive-si...
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.
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 |
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)
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:
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 (this blog)
Quick Reference: Troubleshooting, Diagnosing, and Tuning MaxConcurrentApi Issues
Roaming AD Clients, with an Updated Script
Using PowerShell for Message Analyzer Text Log Parsers
New Features in the Netlogon Parser (v1.1.4) for Message Analyzer
Diving Into the Netlogon Parser (v3.5) for Message Analyzer