Sometimes there are situations when the AD user account keeps locking out. This happens when you try to log on to a domain computer and get an error on the login screen: The referenced account is currently locked out and may not be logged on to. This notification means the account is automatically temporarily blocked by the Active Directory domain Security Policy and can’t be used to log in to the domain computer.
The message about the account lockout looks as shown on the screenshot below:
In this case, the account was locked out after too many failed password attempts.
Table of Contents
Account Lockout Policy in Active Directory Domain
The maximum number of failed logon attempts with a wrong password is specified in the Account lockout threshold Group Policy option, which is located in the following GPO section Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.
Most often, the account lockout settings in the domain are configured through the Default Domain Policy. You can change the account lockout policy in the domain.
In addition to the Account lockout threshold policy, another policy in the section Account lockout duration might be of interest. This policy determines for what time the account is locked out.
In our example, the user account lockout settings in the domain are configured as follows:
- Account lockout threshold — 10 invalid logon attempts;
- Account lockout duration — 10 minutes;
- Reset account lockout counter after — 10 minutes.
Account Lockout policy helps to protect your domain from brute-force attacks. A brute-force script won’t be able to brute-force a large number of password combinations, because after every 10 attempts to brute-force passwords, the target user account will be locked.
Thus, if you’ll wait for 10 minutes after the lock, the account will be automatically unlocked.
Starting with the Active Directory version on Windows Server 2008, you can create individual passwords and lockout policies in a domain for specific users and groups. For this, Fine Grained Password Policies (FGPP) are used. You can check if a custom Password Policy Object (PSO) is being applied to a specific user with the following PowerShell command (the same command will return the lockout settings for that user):
Get-ADUserResultantPasswordPolicy -Identity m.becker
To list the lockout settings in the Default Domain Policy, run the command:
Get-ADDefaultDomainPasswordPolicy | select *lockout*|ft
If LockoutDuration = 0, then such an account will never be automatically unlocked. Only the domain administrator can remove the lock.
If you don’t want to wait for automatic unlocking, the administrator needs to find the user account in the Active Directory Users and Computers snap-in. In the Account tab, check the box Unlock account tab. This account is currently locked out on this Active Directory Domain Controller and press Ok.
You can check if the AD account is locked out using the PowerShell command:
Import-Module ActiveDirectory Get-ADUser -Identity m.becker -Properties LockedOut | Select-Object samaccountName,Lockedout
The Search-ADAccount cmdlet allows you to display information about all locked accounts in a domain:
Search-ADAccount -LockedOut -UsersOnly | Select-Object Name, SamAccountName, Lockedout
You can use the PowerShell cmdlet Unlock-ADAccount to unlock AD account:
Unlock-ADAccount jjackson –Confirm
If you want to unlock all accounts at once, run:
Search-ADAccount –LockedOut -UsersOnly | Unlock-ADAccount
Enable Account Lockout Audit Policy in Active Directory
But in some cases, the locking of the accounts takes place without any apparent reason. In such a situation users report that did nothing and were never entering the wrong password, but their account for some reason is locked. The administrator can manually remove the lock at the request of the user, but after a while, the situation repeats.
In this case, you must first determine the name or IP address of the computer/server from which the lock occurs. To do this check if the Audit User Account Management policy is enabled on the domain controllers in the Default Domain Controllers Policy. Start the Group Policy Management Console (gpmc.msc) and go to the Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy section
Enable the checkboxes: Define these policy settings, Audit these attempts: Success and Failure. Save the changes in the GPO.
Then navigate to the following GPO branch: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon.
Enable the Audit Kerberos Authentication Service policy with the Success and Failure options.
Wait for the Group Policy settings to be updated on domain computers and domain controllers (up to 120 minutes), or run the gpupdate /force command to update the GPO settings immediately.
How to Find Account Lockout Source in Domain?
Account lockout is processed on the PDC emulator, so you need to check for user lockout events on the domain controller with the PDC FSMO role. Use the following PowerShell command to locate the domain controller running the PDC Emulator role:
get-addomain | select PDCEmulator
When a user account is locked out, an event ID 4740 is generated on the user logonserver and copied to the Security log of the PDC emulator.
Log on to the PDC and open the Event Viewer (eventvwr.msc). Expand Event Viewer > Windows Logs > Security. Right-click the Security item and select Filter Current Log.
Filter the security log by the event with Event ID 4740.
You will see a list of events when locking domain user accounts on this DC took place (with an event message A user account was locked out). Find the newest entry in the log containing the name of the desired user in the Account Name value.
You will see something like:
A user account was locked out.
Subject:
Security ID: S-1-5-18
Account Name: LON-DC01$
Account Domain: contoso
Logon ID: 0x3E7
Account That Was Locked Out:
Security ID: S-1-5-21-1774357850-36436-2143367957-1114
Account Name: j.brion
Additional Information:
Caller Computer Name: WKS-NY21S323
In this event, you will have interesting values for the following parameters:
- Security ID and Account Name — the account name of the user that was locked out;
- Caller Computer Name — the name of the computer where the lockout event occurred from. In this case, the computer’s name is WKS-NY21S323.
If you can’t find event ID 4720 with a user lockout, or if the Caller Computer Name value is empty, you need to check the domain controller’s security log for event ID 4771.
- Enable the Security log filter as described above on event 4771;
- You will find several Kerberos authentication service events;
- Look through all “Kerberos pre-authentication failed” events for the item containing Failure Code: 0x18. This error code indicates the following “Clients credentials have been revoked Account disabled, expired, locked out, logon hours”;
- In this case, the lockout IP address source will be contained in the Client Address field in the event description.
- In our example, the user account lockout was initiated from the device with an IP address 172.16.61.9.
Get Account Lockout Source Using PowerShell
Also, you can find the account lockout source on the DC with the PDC FSMO role using PowerShell. Use the following code to list the last account lockout events on the DC:
$properties = @(
'TimeCreated',
@{n='Account Name';e={$_.Properties[0].Value}},
@{n='Caller Computer Name';e={$_.Properties[1].Value}}
)
Get-WinEvent -FilterHashTable @{LogName='Security'; ID=4740} | Select $properties
You can get the account lockout source from the ‘Caller Computer Name’ field.
You can find the sources of lockout events for a specific user in the last 2 days using the command:
$username = ‘m.becker’
$pdcname=(get-addomain).PDCEmulator
$Date = (Get-Date).AddDays(-2)
Get-WinEvent -computername $pdcname -FilterHashtable `
@{logname='security';id=4740;data='m.becker'; StartTime=$Date} |`
Select-Object -Property timecreated,`
@{label='username';expression={$_.properties[0].value}},`
@{label='computername';expression={$_.properties[1].value}}
Common Causes of Account Lockouts
Most often, the account lock begins after the user has changed the domain password. A periodic account lockout can be caused by different reasons. Most commonly, in a production environment, account lockout events are associated with the following causes:
- A brute-force attack is actually being performed on your domain. Find the source computer according to this guide and disconnect it from the network;
- User errors when typing a password. The user is mistaken when entering a password or forgot the password that was recently changed;
- Disconnected RDP/RDS session — usually happens if the user closed the remote session instead of logging out. You can’t prevent such a problem by configuring the force Log off Idle Remote Desktop sessions policy in the domain. This can be configured using the policy Set time limit for active but idle Remote Desktop Services sessions in the GPO section Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits;
- Saved user password in Windows Services. Don’t use the user account to run services on domain servers/computers. Use the separate service account instead (with the password set to never expire) or group Managed Service Accounts;
- Saved user credentials in the Task Scheduler jobs. As with services, user accounts are often used to run the scheduler task. It is better to use service accounts to run scheduled tasks;
- Mapped network drives with saved credentials;
- Mobile devices with saved user credentials — check email client settings on your mobile device for saved AD credentials (like Outlook, ActiveSync, etc.). The saved networks (passwords for Wi-Fi connections) can also be assigned to this category (if you use the Wi-Fi authentication with Windows Active Directory via the Radius server);
- Saved password in browsers;
- Saved user password in the Windows Credential Manager. Open the Credential Manager (rundll32.exe keymgr.dll, KRShowKeyMgr) and remove all the saved credentials.
Using Account Lockout Tool to Track Lockout Events
To find the account lock source on all domain controllers, you can use the convenient LockoutStatus.exe tool (Account Lockout and Management Tools).
Download the Microsoft Account Lockout and Management Tool (ALTools.exe), extract the archive and run the LockoutStatus.exe utility. Select menu File > Select Target and enter needed username (SAMAccountName).
If you run the Microsoft Account Lockout Status utility under a non-privileged user account, check the box “Use Alternate Credentials” and specify account credentials with domain admin privileges. This is necessary to connect to AD domain controllers and select account locking events from the Security log. The LockoutStatus.exe utility does the same thing — it searches for events with the EventID 4740 from the domain controller logs and displays the total data for the events and user account.
Here you can see the current user state on all DCs (Locked), Lockout Time, the value of Bad Password Count on each DC, and the name of the computer from which the lock occurred (Orig Lock).
You can unlock the user account directly from the tool instead of using the ADUC console. To do this, select a DC, right-click the user and select ‘Unlock Account’. This change will be instantly replicated to all DCs in the domain and the user can log on to the domain computers. You can also change the user password by selecting the ‘Reset User’s Password’ menu item.
That’s all! Hope this was useful to fix the issues when the AD account keeps locking out!
