How to Configure Account Lockout Policy in Active Directory?

6.6K

Account Lockout Policy is an AD security feature that helps prevent unauthorized access and brute force attacks on user accounts by automatically locking them after a certain number of failed login attempts. In this blog post, we will explore how to configure the account lockout policy in Active Directory, and how to find and unlock locked-out user accounts.

Configuring account lockout settings in domains

A user cannot log on to the domain and will see the following message if their account is locked:

The referenced account is currently locked out and may not be logged on to DOMAIN.

There are two ways to configure account lockout settings in domains: by using the Group Policy (GPO) or with the Password Settings Object (PSO).

Configure the Default AD Account Lockout Policy with GPO

You can configure Account lockout settings for domain through a domain-level Group Policy. Although multiple GPOs can contain Account Lockout Policy settings, the effective account lockout policy for domain accounts is determined by the GPO processing order at the domain level. In most environments, you should use the Default Domain Policy in order to config these settings.

1. Open the Group Policy Management Console (gpmc.msc) on your domain controller;
2. Right-click on Default Domain Policy and select Edit.
   

   

3. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy;
   

   

4. The following account lockout policy options are available:
   • Account lockout threshold: defines the number of failed login attempts allowed before the account gets locked out.
   • Reset account lockout counter after: determines how long (in minutes) the failed logon counter resets to 0;
   • Account lockout duration: the length of time (in minutes) the account will be locked out after reaching the lockout threshold. The account will be automatically unlocked after this time. The accepted range is 0 to 99,999 minutes. If the value is 0 minutes, the account remains locked until an administrator unlocks it.
   • Allow Administrator account lockout: whether or not the built-in administrator account should be locked out (Built-in administrator account is never locked by default)

     

You can also configure the account lockout policy using the PowerShell cmdlets from the ActiveDirectory module.

List current account lockout policy settings in the default domain GPO:

Get-ADDefaultDomainPasswordPolicy | select LockoutThreshold, LockoutDuration, LockoutObservationWindow

Suppose you want to change the account lockout policy to 5 failed logon attempts, reset the bad logon counter after 25 minutes, and automatically unlock user after 30 minutes:

Set-ADDefaultDomainPasswordPolicy `
-LockoutThreshold 5 `
-LockoutDuration 00:30:00 `
-LockoutObservationWindow 00:25:00

Important. The account lockout duration must be greater than or equal to the lockout observation window. In case LockoutDuration is shorter than LockoutObservationWindow, AD will reject the config and return a validation error.

For example, a lockout duration of 30 minutes and an observation window of 25 minutes is valid, while a lockout duration of 10 minutes and an observation window of 60 minutes is not.

Policy will apply after Group Policy refresh and AD replication. This typically takes from a few minutes up to the default refresh interval (up to ~90 minutes in enterprise environments).

Important Considerations for Service Accounts and Authentication Protocols

Note that account lockout policies affect all authentication attempts processed by AD (that includes Kerberos and NTLM authentication).

You should be careful when configuring low lockout thresholds. Service accounts, scheduled tasks, Windows services, IIS app pools, legacy apps, or devices with outdated credentials may repeatedly submit failed authentication attempts and trigger account lockouts.

Before reducing the lockout threshold, you need to identify critical service accounts and check if all dependent apps use current credentials. In enterprise environments, Fine-Grained Password Policies (PSOs) are often used to apply different lockout settings to service accounts and privileged accounts.

Configure Account Lockout Policy using Password Setting Object (PSO)

Password Setting Objects (PSO) allow you to implement lockout account settings in a more granular way using the Fine Grained Password Policy. For example, you can apply different lockout settings to specific users and/or groups.

Using PSOs for Service Accounts

In enterprise environments, service accounts often require different account lockout settings than standard users. Instead of applying the default domain lockout policy to all accounts, you should consider creating a separate Password Settings Object (PSO) for service accounts and assigning it to a dedicated security group.

1. Open the Active Directory Administration Center (dsac.exe);
2. Navigate to Domain → System → Password Settings Container;

   

3. Under the Tasks pane, click New → Password Settings;

   

4. Enter the Password Settings Name. For example, “Account Lockout Policy – CA Finance” for the California Finance department.
5. In the Precedence, type a number representing the priority of this PSO, where 1 has the highest precedence;
6. Uncheck all checkboxes except Enforce account lockout policy;
7. Configure the custom lockout settings you need;
   

   

8. Add the user(s) or group(s) to apply this password setting and save the password setting object
   

   

Best practice tip. You should use separate PSOs for service accounts, privileged admin accounts, and standard user accounts when different lockout requirements are needed.

You can create more Password Settings Objects to apply to other users or groups.

Our example below creates a complete fine-grained password policy that includes both password and account lockout settings. If you only need to customize lockout settings, you can still create a PSO with the relevant lockout parameters while accepting the other PSO defaults.

$pso = @{
    Name = 'CA Sales Password Policy'
    Precedence = 2
    ComplexityEnabled = $true
    MinPasswordLength = 14
    PasswordHistoryCount = 24
    MaxPasswordAge = '90.00:00:00'
    MinPasswordAge = '1.00:00:00'
    ReversibleEncryptionEnabled = $false
    LockoutThreshold = 5
    LockoutDuration = '01:00:00'
    LockoutObservationWindow = '00:30:00'
}

New-ADFineGrainedPasswordPolicy @pso

Next, assign the PSO to the target Active Directory group(s) or user(s):

Add-ADFineGrainedPasswordPolicySubject -Identity 'CA Sales Password Policy' -Subjects 'CA Sales'

If a user is affected by more than one Password Policy Object at a time, you can use the following command to list the resulting account lockout settings:

Get-ADUserResultantPasswordPolicy -Identity [username]

Note that a user can be affected by multiple Password Settings Objects (PSOs) through direct assignments and group memberships. AD calculates the effective password policy automatically using PSO precedence and assignment rules.

In general, the PSO with the lowest Precedence value has the highest priority. However, direct PSO assignments to a user take precedence over group-based assignments. Because the resulting policy calculation can be complex, we recommend you to use Get-ADUserResultantPasswordPolicy to determine the effective settings applied to a specific user.

Monitoring Account Lockouts

Keep in mind that in enterprise environments, monitoring account lockout events is just as important as configuring the lockout policy itself.

When a user account is locked, AD records Event ID 4740 in the Security log of the DC that processed the lockout request. Reviewing these events can help you identify the source machine, app, service, or device responsible for repeated authentication failures.

You can search for account lockout events using Event Viewer by navigating to Windows Logs → Security → Event ID 4740.

For large environments, you should consider using centralized monitoring solutions (such as Microsoft Defender for Identity, Microsoft Sentinel, or SIEM platforms) in order to correlate lockout events across multiple DCs and quickly identify authentication problems.

You can use the command below to display recent account lockout events recorded on the DC:

Get-WinEvent -FilterHashtable @{
LogName='Security'
Id=4740
} -MaxEvents 20

Modern Account Lockout Protection in Microsoft Entra ID

Note that for organizations using Microsoft Entra ID, traditional AD account lockout policies are only one part of the overall authentication security strategy.

Microsoft Entra ID includes Smart Lockout protection, which helps you to defend against password spray and brute-force attacks by automatically detecting suspicious sign-in attempts and temporarily blocking authentication requests without necessarily locking the user account in AD.

In hybrid environments, you should review both on-premises Account Lockout Policies and Microsoft Entra Smart Lockout settings to ensure consistent protection against modern identity-based attacks.

Notes

• If the user is locked out of the account by policy, they must wait until the LockoutThreshold time expires or the administrator can unlock them manually. Learn more How to Unlock User Account in Active Directory Domain?
• If a user account is repeatedly locked out, you can find the source computer from which the failed logon attempts are coming (Find the source of AD account lockouts).