Live Cyber Attack Lab 🎯 Watch our IR team detect & respond to a rogue insider trying to steal data! Choose a Session

X

Active Directory Account Lockout: Tools and Diagnosis Guide

Active Directory, IT Pros

In This Article

illustration of a lock on a stop sign symbol to represent an AD lockout

Account lockouts are a headache for system administrators, and they happen a lot in Active Directory (AD). Research shows that account lockouts are the biggest single source of calls to IT support desks.

The most common underlying cause for AD account lockouts, beyond users forgetting their password, is a running application or background service on a device that is authenticating with stale credentials. As users are required to use more devices, this problem is getting worse. For system administrators, solving it requires that they find the app that is running with stale credentials, and then either stopping it or asking the user to update the credentials.

Get the Free Pen Testing Active Directory Environments EBook

“This really opened my eyes to AD security in a way defensive work never did.”

This problem is particularly acute in AD because the way in which account lockouts are handled in the system still reflects the average IT environment of ten years ago, in which most users only used one or two devices. In the days when most Office users logged in using one device, it was easy for them to keep track of their credentials. Now, that is not the case.

In this guide, we’ll explain in more detail how AD account lockouts occur, how to resolve them, and how to build a policy that reduces the time and resources you have to spend unlocking accounts.

Quick Review: The Most Common Reasons for AD Lockouts

active directory lockout process

Most AD account lockouts are caused by one of two underlying mechanisms. Either a user forgets their password, or they have updated their credentials on a new device and forgotten to update them on an older device.

In this first instance – a forgotten password – it is a simple matter for administrators to reset a users’ credentials, to remind them of the importance of choosing a strong password and not forgetting it, or even to use a password manager to reduce the number of passwords they need to remember. The second scenario – in which a device or service is attempting to authenticate with obsolete credentials – is a more difficult issue to solve, and is our focus in this article.

The basic mechanics of this kind of lockout are as follows. By default, AD will lock a user out after three failed login attempts. In the vast majority of cases, a user will have been asked to update their AD account credentials and will have done so on their most frequently used device. Any other devices they use may still have their old credentials saved, and will automatically continue to try to access AD using these. They will not be able to, and so AD will lock the account very quickly in order to prevent what looks like a brute force attack.

In most cases, system administrators will then be forced to identify the source of these illegitimate login attempts, and either shut them down or ask the user to update their credentials. In today’s environments, though, where users might be required to log in from dozens of different sources, finding the culprit can be very challenging, as can designing a lockout policy that will reduce the frequency of this kind of issue. In the remainder of this article, we’ll show you how to do both.

Common Active Directory Lockout Causes

common ad lockout causes

Before we talk about solutions to account lockouts, it’s worth recognizing that there are many ways AD account lockouts can occur in addition to the two common reasons mentioned above.

Microsoft has an entire TechNet article on lockout troubleshooting, and their list includes:

  • Programs
  • Service accounts
  • Bad Password Threshold is set too low
  • User logging on to multiple computers
  • Stored user names and passwords retain redundant credentials
  • Scheduled tasks
  • Persistent drive mappings
  • Active Directory replication
  • Disconnected Terminal Server sessions
  • Service accounts

Troubleshooting AD lockouts is easier if you have a strong understanding of AD fundamentals. We’ve written many guides to help you master AD. You should begin with our guide to the best AD tutorials on the web, make sure that you understand the difference between users and computers in AD, the way in which ad domain services work, and also the difference between AD and LDAP.

Once you have a good understanding of these topics, you will have an excellent understanding of the way in which account lockouts happen.

Credential Caching

Service accounts are another common cause of AD account lockouts. Service account passwords are cached by the service control manager on member computers that use the account but are also stored by domain controllers.

This means that if you reset the password for a service account, but you do not reset the password in the service control manager, account lockouts for the service account can occur. This is because the machines that use this account will automatically retry login authentication by using the obsolete password.

This is an often overlooked cause of AD account lockouts but is an easy one to spot and fix. You should look for a pattern in the Netlogon log files and in the event log files on member computers. Here’s how:

You can then reconfigure the service control manager to make use of the new password, which will help to avoid further AD account lockouts.

Bad Password Threshold

The bad password threshold set on your AD accounts is not, in itself, a cause of a lockout. However, if this threshold is set too low, it can trigger the account lockout much earlier than it is practical. If your accounts are genuinely being targeted by a brute force attack, they are likely to see hundreds (if not thousands) of login attempts, but by default, the bad password threshold is set to 10 attempts.

Though Microsoft recommends that you leave this default value as it is, for environments in which users are commonly using multiple devices and services, it can be worth increasing it.

Multiple Devices

Users who frequently access AD through multiple devices can also be a common cause of account lockout. If a user is logged onto multiple devices, programs that are running on those computers may access network resources with the user credentials of that user who is currently logged on. In some cases, programs on the second computer will realize the password is no longer valid and prompt the user to re-authenticate instead of trying again, but this functionality will vary based on the program that is being used. In some cases, if the user changes their password on one of the computers, programs that are running on the other computers will continue to use the original password.

Because these programs authenticate when they request access to network resources, the old password continues to be used and the user’s account becomes locked out once it reaches the bad password threshold. To ensure that this behavior does not occur, you should encourage users to log off of all computers, change the password from a single location, and then log back on across all the devices they need.

Scheduled Tasks

Scheduled processes may be configured to use credentials that have expired, and will try multiple login attempts using these obsolete credentials. This can cause an account lockout.

Persistent Drive Mappings

A more unusual mechanism for account lockout, and one that can be difficult to spot, stems from the way in which Windows handles drive mappings. You may have previously established persistent drives with credentials that have now expired. This will mean that 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 re-logs on to the network, or restarts the computer, the authentication attempt fails. This is because when Windows attempts to restore the connection, there are no stored credentials. In order to avoid this issue, you can configure net use so that it does not make persistent connections. At a command prompt, type:

net use /persistent: no

AD 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 can also be a cause of account lockout. Disconnected terminal server sessions mean that the user is still logged onto the server in a “disconnected” state. When a user has a disconnected session and they change their password, the terminal server occasionally uses the users’ old credentials to keep the session alive. The attempts to re-authenticate the disconnected user will eventually lock out the account. This will continue to happen until the user logs out of all terminal server sessions.

A disconnected terminal 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

For most AD environments, services are configured to start in the security context of the Local System account. However, some administrators will manually set up a service to use a specific user account and password.

If the password for this account is changed, the service logon property must be updated with the new password, or that service may lock out the account.

Troubleshooting An Account Lockout

tips for troubleshooting an AD lockout

Because there are so many potential causes of an AD account lockout, system administrators will often have to undertake some significant investigative work in order to address the issue., System administrators should set up a system to track the number of enabled lockout users throughout their AD Forest, so they can to troubleshoot AD lockouts before being overwhelmed with calls from users.

Initial Steps

When you first identify a locked account,, the first and most important task is to identify whether lockout is due to a cyber attack.

To ensure you have enough information to investigate, you should take a few key steps:

  1. Verify that the domain controllers and client computers are up-to-date with service packs and hotfixes.
  2. Configure your computers to capture data:
    • Enable auditing at the domain level.
    • Enable Netlogon logging.
    • Enable Kerberos logging.
  1. Analyze data from the security event log files and the Netlogon log files to help you determine where the lockouts are occurring and why.
  2. Analyze the event logs on the computer that is generating the account lockouts to determine the cause.

If, after looking through these logs, you see hundreds (or thousands) of failed login attempts, it’s likely that you are seeing a brute force attack on your systems, and you should take immediate action to respond. If, however, it appears that the lockout was caused by more mundane reasons, you will need to find how this has occurred.

Finding the App with Stale Credentials

In the vast majority of cases, AD account lockouts are caused by stale credentials being sent by devices, services, or programs. To get to the bottom of this kind of lockout problem, admins and tech support staff must first find the offending app or service. And that means you’ll have to search the event logs of the affected domains—either manually (not recommended), with a third-party app, or Microsoft’s own LockoutStatus.exe.

Event ID 4771 or Event ID 529

The particular event you are looking for is Event ID 4771 on Server 2008 or Event ID 529 on Server 2003. When you view this Account Lockout event, you should see the client’s computer name or else the device’s IP address.

For Windows OS, at least for Windows 7 and beyond, you can then remotely log onto the client’s machine and bring up the Credential Manager to remove the old credentials. Very likely this was the user’s secondary computer, and after a password change was made on the more frequently used computer, the other machine continued to run services that forced the “account lockout threshold” to be crossed.

IP Addresses

And if the Lockout event points to an IP address?

Then the admin will have to look up the MAC address from another device on the local network segment in question, and then the mac address vendor—using, for example, http://www.macvendorlookup.com—to learn the device type. Ninety-nine times out of a hundred the app on the IOS or Android gadget that was sending out the bad credentials is an Exchange email client—e.g., ActiveSync. The locked-out user will then need to update the password to refresh the credentials and bring everything back in sync.

Lockout Policy Considerations

If you are continually seeing multiple AD lockout instances, it is possible to remedy this – at least to some extent – by looking at your lockout policy.

In fact, many administrators will tell you that most, if not all, account lockouts can be remedied by having a more intelligent AD account lockout policy. This school of thought recommends that the admin go into the default GPO for the domain, and change the appropriate lockout parameters to a more reasonable setting.

The “account lockout threshold” setting should be shifted to a much higher number than three — perhaps 20 or 30 — so that you, or more to the point, a hacker really has to be hammering at the account to trigger a lockout. “account lockout duration”, the time to wait before the account is automatically unlocked, set to a more sensible ten minutes (instead of, say, 12 hours), and different from the default of zero, which is a permanent lockout. And finally, the tricky “reset account lockout policy after” default set to one minute. You can read more about this approach here.

After receiving wise counsel from a few Varonis SEs, though, I learned that changing the default Active Directory lockout parameters can help. But tread carefully here, there are assumptions about the overall strength of employee passwords that have to be first proved out. According to the SEs, if you have a robust password policy in place, then it might make sense to ramp up the “account lockout threshold”, otherwise this may not fly. There is also a good case to be made that this threshold parameter should always be zero, and users are forced to ultimately deal with support to unfreeze their accounts.

Ultimately, the approach you choose will depend on your environment, and how many lockout instances you are seeing on a daily basis. You should seek to apply a lockout policy that allows you to manage the number of account reset attempts you receive, whilst still being able to catch genuinely malicious attempts to access your network.

Applying an AD Lockout Policy

Whichever approach you decide on, you will need to implement this using the options that AD provides for managing lockouts. All of these options can be accessed in the following way:

  • Go to Start MenuAdministrative ToolsGroup Policy Management
  • In the console tree, expand the Forest and then Domains. Select the domain for which the Account policies have to be set
  • Double-click the domain to reveal the GPOs linked to the domain.
  • Right-click Default Domain Policy and select Edit. A Group Policy Editor console will open.
  • Now, navigate to Computer ConfigurationPoliciesWindows SettingsSecurity SettingsAccount PoliciesAccount Lockout Policy
  • Double-click Account Lockout Policy to reveal the three account lockout settings available in AD. Right-click any one of these settings and select Properties to define the policy-setting
  • The Properties dialog box of each policy setting will have two tabs. The Security Policy Setting tab is where the value for that setting is set. The Explain tab gives a brief description of the policy-setting and its default values
  • In the Security Policy Setting tab, check the Define this Policy Setting checkbox and enter the desired value. Click Apply and then OK.

In this dialogue box, you will be able to set three options. Here’s an explanation of each.

Account Lockout Duration

This setting determines the number of minutes a locked-out account remains locked-out before it gets automatically unlocked. The value can be set between 0 minutes and 99,999 minutes. This setting needs the Account Lockout Threshold setting to be defined.

If the value is set to 0, then the account will never be unlocked automatically. The administrator will have to unlock the account explicitly. By default, this setting is disabled. To unlock the account:

  • In ADUC, right-click the user whose account is locked out and select Properties
  • Under the Account tab of the user properties, check the Unlock Account checkbox to unlock the account

Account Lockout Threshold

This security setting sets the number of failed login attempts that are allowed before a user account is locked out.

For example, if an attacker or user enters a wrong password for the first time, the badPwdCount attribute of the user object is set to 1. When the attacker continues to enter the wrong passwords, the badPwdCount is incremented by 1 until it reaches the account lockout threshold value. Once it does, the account gets locked. A locked-out account cannot be used to log on until the account lockout duration expires or an administrator explicitly unlocks the account.

The value can be set between 0 and 999. If the value is set to 0, then the account will never get locked-out. The default value is 0.

Reset Account Lock-out Counter After

This security setting determines the number of minutes that elapse, after a failed login attempt, for the failed logon counter to be set as 0. The value can be set between 1 and 99,999 minutes. This setting needs the Account Lockout Threshold setting to be defined.

If the Account Lockout Threshold is defined, then the Reset Account Lock-out Counter After value must be less than or equal to the Lockout Threshold duration.

3 Active Directory Account Lockout Tools

ad lockout tools

AD account lockouts are such a common occurrence, and such a source of frustration for network administrators, that a few tools have been written specifically to help you deal with them. Some of these are provided by Microsoft, and others are third-party offerings. Here is a round-up of the best of them:

Account Lockout Status Tools

This is the standard set of tools that Microsoft provides for managing AD account lockouts, and consists of a set of individual components. Each will help you to investigate different aspects of your network:

  • EventCombMT.exe collects and filters events from the event logs of domain controllers. This tool has a built-in search for account lockouts, it gathers the event IDs related to certain account lockouts in a separate text file that can then be exported.
  • LockoutStatus.exe examines all DCs in a domain, and tells you when the target account last locked out and from which DC. In addition, it provides the locked-out account’s current status and the number of bad password attempts that have been made.
  • Netlogon logging is used for tracking Netlogon and NT LAN Manager (NTLM) events. Enabling Netlogon logging on all DCs is an effective way to isolate a locked-out account and see where the account is being locked out. Although Netlogon logging isn’t part of the Account Lockout and Management Tools, NLParse.exe is used to parse the Netlogon logs—and NLParse.exe is one of the account lockout tools.
  • Acctinfo exposes more properties in ADUC (Active Directory Users and Computers), for example, lastLogon and Password Expires. Specifically, with this add-on, you get an extra tab in ADUC called Additional Account Info it helps isolate and troubleshoot account lockouts and to change a user’s password on a domain controller in that user’s site.

ADLockouts

This is a simple program that tries to track the origin of Active Directory bad password attempts and lockout.

This tool is great for smaller networks but can struggle with more extensive environments. The application can search through each domain and the domain controller for failed logins, and will then parse any related events. The goal is to identify the origin of the lockout. After this, the program analyzes each machine and outputs the typical causes of account lockouts against a number of entities: mapped drives, old RDP sessions, scheduled tasks, and other factors.

PowerShell

You can, of course, take the most direct approach to investigate the cause of AD account lockouts, and use PowerShell to interrogate your network. This might be a slightly longer and more complex process than using the tools above, but it will also give you more granular information on exactly what is happening in your systems.

Using powershell you can easily filter the event log for events that are related to a certain account in order to ascertain the source of the account lockout:

  • You can do this using the Get-EventLog cmdlet using the following code:
Get-EventLog -LogName Security | ?{$_.message -like "*locked*USERNAME*"} | fl -property *
  • Alternatively, you can use the Get-UserLockoutStatus function for troubleshooting persistent account lockout problems. The function searches all domain controllers for a user in a domain for account lockout status, Bad Password Count, Last bad password time, and When password was set last. You can find the full documentation for using this function on Technet here.
Get-UserLockoutStatus

A Final Word

If you are a network administrator, you don’t need us to tell you that AD account lockouts are a major headache. Given this, it’s tempting to simply view account lockouts as an inherent feature of AD, and automatically unlock user accounts as soon as you receive a support request.

This is a bad approach to handling account lockouts. By taking the time to investigate the true causes of frequent account lockouts, you can stop them from occurring so frequently. Equally, changing your AD account lockout policies can be an effective way of separating instances of user error from genuinely malicious attacks on your network.

Ultimately, how effectively you are able to prevent and manage AD account lockouts will depend on how well you understand AD itself. If you are frequently frustrated by an inability to trace the source of these issues, you can use the resources we’ve provided to improve your knowledge. Specifically, take a look at our guide to AD users and computers, and also our guide to how to use data classification labels can help you to further secure your network against cyberattacks.

Jeff Petters

Jeff Petters

Jeff has been working on computers since his Dad brought home an IBM PC 8086 with dual disk drives. Researching and writing about data security is his dream job.

 

Does your cybersecurity start at the heart?

Get a highly customized data risk assessment run by engineers who are obsessed with data security.