Windows Server


Account Lockout    



Account Lockout


Account Lockout

Account Lockout is the Lockout of an user’s / service account due to entering incorrect credentials more than what is specified in the Account Lockout Section of the Password Policy for the Domain; after which you cannot use the account to login even if you enter correct credentials.


Account Lockout occurs when you violate the policy for account lockout for the Domain for a particular account.

There are two scenarios:

1.      Manual Account Lockout: Whenever the policy violation occurs manually by a user entering incorrect credentials.

2.      Service Account Lockout: When you set a service to run on a service account and then the service violates the account lockout policy continually without knowing that the Password is incorrect.


In a Service Account Lockout, the lockout typically occurs when ever a system administrator updates the password for that account but the service is still configured to run as using the old un-updated credentials.

In this case the service tries to login indefinitely using the incorrect old credentials and then the account gets locked out.

To resolve this issue update all the services to run using the latest correct account credentials.


A normal account lockout would be a typical scenario where-in a user enters incorrect credentials manually and then the account gets locked-out.


Under a non-manual account lockout the computer programs are causing lockout.

These may be programs that stand for services configured with the account getting locked out.


It may be due to a virus causing the Account to get locked out.


In any of these cases; I want you all to treat it as a normal account lockout issue; meaning: Troubleshoot as if it is a normal account lockout.


By gathering Netlogon logs from the Domain Controller we can track down the client workstations where the account was being used to login into the active directory.

We can get the machines NetBIOS name and then find and track that machine physically and then continue to troubleshoot further.


The Location to check for stored credentials:

Go to Computer Management Console (compmgmt.msc) > Services Section > Right Click the Service whose account you want to check for.


Other Location to check for stored credentials:

Start > Run > control keymgr.dll


Follow the following steps to troubleshoot account lockout issues:


·        Enable auditing on the Domain Controllers

·        Configure and gather Netlogon logs from the domain controllers, especially from the PDC emulator.

a.      Out of all of the user accounts that are being affected focus on one user account and track down the machine causing the lockout.

b.      Once you have tracked down a machine that is sending bad credentials, gather a MSDT / MPS Report(s) from the client.


After going through the logs and tracking at least one machine from which that account is being used; Note down its NetBIOS name, IP Address; and then use the Auditing for tracking which process on that machine is using that account to login.

After doing this much update the service with the correct credentials.

OR Else if that was because of some malicious software; then use a descent Anti-Virus to troubleshoot/clean that workstation client.

Auditing can help us to get to those Event ID’s where in  the process name is mentioned together with the Account username and then we can find which service was using that process and then correct the Run As Preference to the latest correct credentials.


It is important that we have data with these cases.


Please refer to the following TechNet articles on troubleshooting account lockouts:


Troubleshooting Account Lockout


Troubleshooting Account Lockout

Applies To: Windows Server 2003 with SP1

In an environment where you set the account lockout feature, you may notice a large number of lockouts that occur. To determine if these lockouts are false lockouts or a real attack:

1.      Verify that the domain controllers and client computers are up-to-date with service packs and hotfixes. For more information, see the "Recommended Service Packs and Hotfixes" section in this document.

2.      Configure your computers to capture data:

a.      Enable auditing at the domain level.

b.      Enable Netlogon logging.

c.       Enable Kerberos logging.

For more information, see the "Appendix Two: Gathering Information to Troubleshoot Account Lockout Issues" section in this document.

3.      Analyze data from the Security event log files and the Netlogon log files to help you determine where the lockouts are occurring and why.

4.      Analyze the event logs on the computer that is generating the account lockouts to determine the cause.

For more information, see the Account Lockout Tools section in this document.

The following section further describes the account lockout troubleshooting process.

Common Causes for Account Lockouts

This section describes some of the common causes for account lockouts The common troubleshooting steps and resolutions for account lockouts are also described in this section.

To avoid false lockouts, check each computer on which a lockout occurred for the following behaviors:

  • Programs: Many programs cache credentials or keep active threads that retain the credentials after a user changes their password.
  • Service accounts: Service account passwords are cached by the service control manager on member computers that use the account as well as domain controllers. If you reset the password for a service account and you do not reset the password in the service control manager, account lockouts for the service account occur. This is because the computers that use this account typically retry logon authentication by using the previous password. To determine whether this is occurring, look for a pattern in the Netlogon log files and in the event log files on member computers. You can then configure the service control manager to use the new password and avoid future account lockouts.
  • Bad Password Threshold is set too low: This is one of the most common misconfiguration issues. Many companies set the Bad Password Threshold registry value to a value lower than the default value of 10. If you set this value too low, false lockouts occur when programs automatically retry passwords that are not valid. Microsoft recommends that you leave this value at its default value of 10. For more information, see "Choosing Account Lockout Settings for Your Deployment" in this document.
  • User logging on to multiple computers: A user may log onto multiple computers at one time. Programs that are running on those computers may access network resources with the user credentials of that user who is currently logged on. If the user changes their password on one of the computers, programs that are running on the other computers may continue to use the original password. Because those programs authenticate when they request access to network resources, the old password continues to be used and the users account becomes locked out. To ensure that this behavior does not occur, users should log off of all computers, change the password from a single location, and then log off and back on.


Computers running Windows XP or a member of the Windows Server 2003 family automatically detect when the users password has changed and prompt the user to lock and unlock the computer to obtain the current password. No logon and logoff is required for users using these computers.

  • Stored user names and passwords retain redundant credentials: If any of the saved credentials are the same as the logon credential, you should delete those credentials. The credentials are redundant because Windows tries the logon credentials when explicit credentials are not found. To delete logon credentials, use the Stored User Names and Passwords tool. For more information about Stored User Names and Passwords, see online help in Windows XP and the Windows Server 2003 family.


Computers that are running Windows 95, Windows 98, or Windows Millennium Edition do not have a Stored User Names and Passwords file. Instead, you should delete the user's .pwl file. This file is named Username.pwl, where Username is the user's logon name. The file is stored in the Systemroot folder.

  • Scheduled tasks: Scheduled processes may be configured to using credentials that have expired.
  • Persistent drive mappings: Persistent drives may have been established with credentials that subsequently expired. If the user types explicit credentials when they try to connect to a share, the credential is not persistent unless it is explicitly saved by Stored User Names and Passwords. Every time that the user logs off the network, logs on to the network, or restarts the computer, the authentication attempt fails when Windows attempts to restore the connection because there are no stored credentials. To avoid this behavior, configure net use so that is does not make persistent connections. To do this, at a command prompt, type net use /persistent:no. Alternately, to ensure current credentials are used for persistent drives, disconnect and reconnect the persistent drive.
  • Active Directory replication: User properties must replicate between domain controllers to ensure that account lockout information is processed properly. You should verify that proper Active Directory replication is occurring.
  • Disconnected Terminal Server sessions: Disconnected Terminal Server sessions may be running a process that accesses network resources with outdated authentication information. A disconnected session can have the same effect as a user with multiple interactive logons and cause account lockout by using the outdated credentials. The only difference between a disconnected session and a user who is logged onto multiple computers is that the source of the lockout comes from a single computer that is running Terminal Services.
  • Service accounts: By default, most computer services are configured to start in the security context of the Local System account. However, you can manually configure a service to use a specific user account and password. If you configure a service to start with a specific user account and that accounts password is changed, the service logon property must be updated with the new password or that service may lock out the account.


You can use the System Information tool to create a list of services and the accounts that were used to start them. To start the System Information tool, click Start, click Run, type winmsd, and then click OK.

Other Potential Issues

Some additional considerations regarding account lockout are described in the following sections.

Account Lockout for Remote Connections

The account lockout feature that is discussed in this paper is independent of the account lockout feature for remote connections, such as in the Routing and Remote Access service and Microsoft Internet Information Services (IIS). These services and programs may provide their own unrelated account lockout features.

Internet Information Services

By default, IIS uses a token-caching mechanism that locally caches user account authentication information. If lockouts are limited to users who try to gain access to Exchange mailboxes through Outlook Web Access and IIS, you can resolve the lockout by resetting the IIS token cache. For more information, see "Mailbox Access via OWA Depends on IIS Token Cache" in the Microsoft Knowledge Base.

MSN Messenger and Microsoft Outlook

If a user changes their domain password through Microsoft Outlook and the computer is running MSN Messenger, the client may become locked out. To resolve this behavior, see "MSN Messenger May Cause Domain Account Lockout After a Password Change" in the Microsoft Knowledge Base.





Appendix Two: Gathering Information to Troubleshoot Account Lockout Issues


Appendix Two: Gathering Information to Troubleshoot Account Lockout Issues

Updated: July 31, 2004

Applies To: Windows Server 2003 with SP1

You can use the information in this section to help you gather information before you start to troubleshoot account lockout issues. Collect the following information to troubleshoot account lockout issues:

Client Platform

If client account lockouts are occurring on a single, common operating system, there may be specific issues with the operating system. Different operating systems use different processes for name resolution and authentication protocols, and they have different levels of security, so there might be an infrastructure or program issue. For more information, see the Microsoft Knowledge Base article "Service Packs and Hotfixes Available to Resolve Account Lockout Issues" on the Microsoft Web site.

You should gather the following information in these situations:

  • Do users log on to multiple computers at the same time?
  • Are there any common patterns? For example:
    • Do the computers have the same mapped drives?
    • Do the computers have the same mapped printers?
    • Do the computers have the same antivirus software?
    • Do the computers use management software?
    • Is another networking client installed on the computers?
    • Is SMS installed on the computers?
  • Does the network include a Wide Area Network (WAN)?
  • If the computer is running Windows 95, Windows 98, Windows 98 SE, or Windows Millennium Edition, what is the version of the Vredir.vxd file?
  • If the computer is running Windows 95, Windows 98, Windows 98 SE, or Windows Millennium Edition, is the Directory Services Client installed on the computer?

Domain Platform

When you know the domain environment, the security boundaries, and how the user is gaining access to the resources that are in other domains, you can better determine the cause of the account lockouts. You should gather the following information:

  • The number of domain controllers, including operating system, location, service pack level, and so on.
  • Is Active Directory and Netlogon replication occurring?
  • What domain does the user log onto?
  • List all domain trusts that the user uses.
  • Is there a matching account with the same logon name in the trusted domain?
  • Are there any third-party SMB servers running in the environment?


Look at the client and the network resources that the user might be contacting to help you determine the cause of the lockouts. You should gather the following information:

  • When did you first notice the lockouts?
  • When did the lockouts start?
  • What has changed in the environment (new programs, new network services, and so on)?
  • Are there any identifiable patterns:
    • After a password change?
    • When the user logs on?
    • When the user gains access to mapped drives?
    • When the user uses Outlook?
    • When the user uses Outlook Web Access?
    • Are there no identifiable patterns?
  • How many user accounts are locked out each day, a small group of users or a large group?
  • Is there an account password policy?
    • How many bad attempts are allowed before a lockout occurs?
    • How much time must elapse before the count resets?
    • What is the LockoutDuration registry value?

Gathering Diagnostic Information

Gather all of the different log files from Netlogon, Kerberos, and the event logs to help you determine the cause of the lockout. Diagnostic information that you gather from the computer from which the lockout is originating may help you determine the cause for the lockout. You should gather the following information:

  • Netlogon log files
  • Traces
  • Event log files from client computers and domain controllers that are involved in the lockout


No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/2906

Leave a comment


Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011