Fix Active Directory account lockouts with PowerShell

What are causes of Active Directory account lockouts?

Not all account lockouts are from malicious sources or even from users who forget their passwords.

Applications often rely on a service account for the necessary permissions to function. However, if the service account's password changes and the application does not get the updated password, this can lock the service account.

Redundant login information is another reason for account lockouts. An enterprise user might have a dozen or more credentials tied to a common username. It takes effort to keep track of all these accounts. It's not difficult to foresee someone using the wrong set of credentials multiple times until they trigger an account lockout in Active Directory.

Account lockouts can also occur when users change work locations. A common scenario is when a user switches from working on a domain-joined Windows desktop in the office to a Windows laptop at home not connected to a network. Because the laptop is offline, it does not record password changes. The user must log in with the old password. If the user brings that laptop into the office and attempts to access the network, the combination of password mismatch and end-user confusion could lead to an account lockout.

Account lockout policies can help and hinder admins

One of the main reasons account lockouts are problematic is that they tend to happen silently. As an administrator, you might never even know that an account lockout has occurred unless a user calls or you see an account lockout event listed in the Windows event logs.

Account lockouts can be problematic for IT because, while unlocking accounts and resetting passwords is simple enough, a high volume of reset requests or account lockout tickets can overload the help desk and waste the IT staff's time. Of course, these lockouts affect the end user, who cannot work while waiting for a fix to their account lockout.

Even though Active Directory account lockouts are meant to keep an organization secure, they sometimes backfire. Users frustrated by account lockouts might try to sidestep the organization's security protocols and write down their passwords or use weak passwords that are easy to remember. An automated brute-force attack could cycle through every user in an organization and cause widespread damage by locking out every account; one way to counteract this is to set the account lockout threshold to 0, which never locks any accounts but relies on other security means to prevent these hack attempts.

How to investigate account lockouts in the Windows event logs

To search the event logs for account lockout events, it's best to begin by checking the Security log for Event ID 4740: A user account was locked out. While this event indicates an account was locked out, it doesn't explain why.

When investigating this issue, search for other events that can provide more information, such as Event ID 4625: An account failed to log on. This event usually details why the login failure occurred. For example, you might find that the user entered their password incorrectly or that they tried to log in outside of authorized hours.

To stay ahead of these lockout situations, one option is to use PowerShell to check for lockouts in event logs with the following command.

Get-WinEvent -FilterHashTable @{LogName="Security"; ID=4740} | Select-Object TimeCreated, Message | Format-Table -Wrap

The following details the specifics of this command:

• The Get-WinEvent cmdlet queries Windows event logs.
• FilterHashTable specifies the items to search for within the event logs. In this case, the LogName parameter targets the Windows Security log and filters for instances of Event ID 4740, referring to account lockout events in Active Directory.
• The command pipes results into the Select-Object cmdlet, which displays the time when the event was created and event details, such as the device, user's name and domain.
• The Format-Table cmdlet, along with the Wrap parameter, forces PowerShell to display the pertinent information neatly in a table. Normally, PowerShell output truncates the account lockout message.

In a production environment, this Active Directory account lockout query could draw excessive results because it checks the Security event log for all instances of Event ID 4740, regardless of when the event occurred. The best way to address this problem is to use the StartTime filter. For example, the following command looks at events from the last 24 hours.

$Start=(Get-Date).AddDays(-1)
Get-WinEvent -FilterHashTable @{LogName="Security"; ID=4740;StartTime=$Start} | Select-Object TimeCreated, Message | Format-Table -Wrap

The following details the specifics of this command:

• The variable named $Start serves as a starting point for the log search. Get-Date.AddDays(-1) tells PowerShell to subtract one day from the current time. To check logs through the previous week, use AddDays(-7).
• The second command is identical to the previous one, except StartTime=$Start is added as a parameter to the filter hash table to instruct PowerShell to ignore results older than the date and timestamp in the $Start variable.

How to check your organization for account lockouts

Another way to use PowerShell to check for Active Directory lockouts is to query a user account using the Get-ADUser cmdlet and then check the value of the LockedOut property.

The problem with this approach is reliability. It works if Active Directory treats the account lockout status as a stored property, but it does not work if it is a calculated property.

Instead, use the Search-ADAccount cmdlet for more consistent results. If you want to see a list users whose accounts are currently locked out, you can use this PowerShell command.

Search-ADAccount -LockedOut | Select-Object SamAccountName, LockedOut

The following details the specifics of this command:

• The Search-ADAccount cmdlet is designed to look at various user account properties.
• The LockedOut parameter designates whether an account is locked.
• The Select-Object cmdlet determines the information displayed within the output. In this case, the command shows the Security Account Manager (SAM) account name -- or the username -- and the LockedOut status.

To check to see whether a specific user has been locked out, use this command.

Search-ADAccount -LockedOut | Where-Object {$_.SAMAccountName -eq "<username>"} | Select-Object SamAccountName, LockedOut

This command is nearly identical to the previous command, except for the Where-Object cmdlet, which filters the list to show results for the specified user. The command returns a status of True if the user is locked out. No results show otherwise.

To unlock an account, use the following PowerShell command, replacing <username> with the name of the user whose account you wish to unlock.

Unlock-ADAccount <username>

If you want to unlock the locked accounts, use this command.

Search-ADAccount -LockedOut | Unlock-ADAccount

The following details the specifics of this command:

• The Search-ADAccount cmdlet finds locked-out users.
• The results are piped into the Unlock-ADAccount cmdlet, which removes the lockout status.

How to use the ADUC console to unlock accounts

PowerShell tends to be the quickest and easiest option for unlocking accounts for certain scenarios, such as if you have a lot of accounts to unlock or if you aren't sure which accounts need attention, but it isn't your only option. You can also unlock accounts using the Active Directory Users and Computers (ADUC) console:

• Open the console, and then right-click on the account to unlock and select the Properties command from the shortcut menu to open the user's properties sheet.
• Select the Account tab, and then select the Unlock Account checkbox.
• Click OK to complete the process.

How to troubleshoot frequent account lockouts

Frequent account lockouts can be a headache. When that happens, they are usually tied to a few specific causes.

One reason is cached credentials. Avoid this problem by always prompting users for their credentials rather than enabling Windows to remember them.

If a user device is often locked out while using a mobile device, consider enlisting Microsoft's Conditional Access policies. These policies reduce lockouts through more stringent login verification methods, such as using geographic location to prevent hack attempts or requiring Microsoft Authenticator to implement passwordless authentication.

You can also review the Active Directory account lockout settings in Group Policy and adjust the lockout threshold or the lockout duration to align them to your security requirements.

Some legacy applications store credentials inside the application. This setup can trigger lockouts if the password is changed without adjusting it in the application. It's best to limit this practice if possible and to avoid a lockout policy for accounts only used by these applications.

Finally, Active Directory replication health problems sometimes cause account lockouts in complex Active Directory environments, such as when replication falters or there's a delay in replication between domain controllers. To check the Active Directory's replication status, use the repadmin /replsummary command.

What are some security considerations related to account lockouts?

When determining how to manage account lockouts in your organization, consider your options carefully.

First, it's important to adhere to least-privilege access principles, meaning that admins have just the permissions needed to do their jobs. The downside is that this limits the scope of how administrators use PowerShell to prevent unauthorized account lockout management.

Second, while it is possible to build PowerShell scripts that automate the account unlocking process, it's important to protect those scripts from unauthorized access. If you have properly implemented least-privilege access, then this restricts unsanctioned access to these scripts. This limitation prevents any malicious modifications to your code and stops attackers from accessing the code to learn more about your infrastructure.

Finally, checking account access patterns before unlocking an account is important. If you find that an account -- particularly a privileged account -- gets locked repeatedly, it may be an indication that an attacker is targeting that account.

How to define the organization's lockout policy

You adjust the account lockout policy settings by using the Group Policy Management Editor and navigating to the following menu: Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy. The Group Policy settings provide options to adjust the account lockout duration, threshold and lockout reset counter.

Microsoft does not have a universally applicable best practice for account lockouts. Some Microsoft documentation suggests setting the account lockout threshold to either 0 -- to prevent denial-of-service attacks -- or to 10. If you configure accounts to be locked out, Microsoft recommends keeping the account lockout duration relatively short, such as 15 minutes.

Brien Posey is a former 22-time Microsoft MVP and a commercial astronaut candidate. In his more than 30 years in IT, he has served as a lead network engineer for the U.S. Department of Defense and a network administrator for some of the largest insurance companies in America.