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:
Where do I enable the Netlogon logging?
How do I enable verbose Netlogon logging?
Differences between logging level verbosity:
Netlogon.log Maximum File Size:
Let’s dig into the errors!
0xC0000022 (or 0x00000005 (0x5)) STATUS_ACCESS_DENIED
0xC0020050 (Decimal -1073610672) RPC_NT_CALL_CANCELLED
0xC00000DC (Decimal -1073741604) STATUS_INVALID_SERVER_STATE
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.
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:
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:
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).
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.
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.
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.
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….
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)
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).
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.
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>
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:
(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
(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)
(Send NTLM response only)
· Clients use only NTLM authentication, and use NTLMv2 session security (if the target is capable)
(Send NTLMv2 response only)
· Clients use only NTLMv2 authentication, and will use NTLMv2 session security (if the target is capable)
(Send NTLMv2 response only\refuse LM)
· Domain Controllers will allow NTLM or NTLMv2 authentication, and will refuse LM authentication
(Send NTLMv2 response only\refuse LM & NTLM)
· 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) -
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:
2. Backup Operators
3. Power Users
ii. Domain controllers:
2. Authenticated Users
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:
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)”
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:
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)
a. Nltest syntax reference: http://technet.microsoft.com/en-us/library/cc731935(v=WS.10).aspx
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
1. Paged pool memory exhaustion
2. Physical memory exhaustion
3. High CPU
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)
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.
d. Reference table of the settings:
e. The settings, if they are incompatible, can be configured in two ways:
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
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.
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
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
v. Using group policy (recommended) –
vi. In the registry (this may be overwritten by group policy settings) -
9. SMB signing settings may be incompatible
a. If a SMB connection is being made, SMB signing options must be compatible
10. NIC drivers may need to be updated
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)
Some of the more common, but self-explanatory errors are listed below:
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
User is attempting to reset password and it does not meet requirements specified by policy (length, history, complexity)
1. The user is trying to logon from a machine they aren’t assigned to.
2. Active Directory replication may not be complete
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
1. Your user account is expired!
The Netlogon service isn’t started on the source, the middle-man, or the target machine.
1. Your password is expired!
1. You are set with logon hours restrictions and have attempted to logon outside of those time restrictions
1. Your user account is locked out!
1. Your user account is disabled!
Domain controller may be shutting down or restarting (see: http://support.microsoft.com/kb/942636 or http://support.microsoft.com/kb/973667)
1. User has the “user must change password at next logon flag set. Time to change your password!