When the AD user account continues locking out, there are a few things you may do. When you try to connect in to a domain computer and get the following error: The referenced account is now locked out and may not be logged on to, this is what happens. This message indicates that the account has been temporarily blocked by the Active Directory domain Security Policy and is no longer able to connect in to the domain computer.
The following is a snapshot of the notice regarding account lockout:
Due to multiple attempts to input the erroneous password, the account was disabled in this situation.
Domain Policy for Active Directory Account Lockout
The Account lockout threshold Group Policy option, which is contained in the following GPO section, specifies the number of attempts to input a wrong password. Account Lockout Policy can be found under Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies.
The Default Domain Policy is usually where the domain’s account lockout settings are specified. The domain’s account lockout policy can be changed.
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.
The Account Lockout policy aids in the prevention of brute-force assaults on your domain. A brute-force script won’t be able to brute-force a significant number of password combinations since the target account will be locked after every 10 attempts to brute-force passwords.
As a result, if you wait 10 minutes after the account has been locked, it will be automatically unlocked.
Individual passwords and lockout policies for certain users and groups can be created in a domain starting with the Active Directory version on Windows Server 2008. Fine Grained Password Policies (FGPP) are utilized for this. The following PowerShell command can be used to see if a custom Password Policy Object (PSO) is being applied to a certain user (the same command will also provide the lockout settings for that user):
Get-ADUserResultantPasswordPolicy -Identity m.beckerTo list the lockout settings in the Default Domain Policy, run the command:
Get-ADDefaultDomainPasswordPolicy | select *lockout*|ft
If LockoutDuration is set to 0, such an account will never be unlocked automatically. The lock can only be removed by the domain administrator.
If the administrator does not want to wait for automatic unlocking, the user account must be found in the Active Directory Users and Computers panel. Check the box Unlock account tab in the Account tab. On this Active Directory Domain Controller, this account is presently locked out. Click 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
Note. Or you can use the PowerShell cmdlet Unlock-ADAccount to unlock a user account:
Unlock-ADAccount jjackson –ConfirmIf you want to unlock all accounts at once, run:
Search-ADAccount –LockedOut -UsersOnly | Unlock-ADAccount
How can I find the source of an account lockout in a domain?
However, in certain instances, the accounts are locked for no apparent reason. Users complain that they did nothing wrong and never entered the erroneous password, but their account is locked for some reason. The administrator can manually remove the lock at the user’s request, but the scenario will recur after a while.
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 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.
You need to look for domain account lockout events on the PDC domain controller. Use the following PowerShell command to locate the domain controller running the PDC Emulator role:
get-addomain | select PDCEmulator
Open the Event Viewer on the PDC after logging in (eventvwr.msc). Expand Windows Logs > Security in Event Viewer. Select Filter Current Log from the Security item’s right-click menu.
Filter the security log by the event with Event ID 4740.
You’ll see a list of events that occurred on this DC when domain user accounts were locked (along with an event message). A user account was disabled). Find the last entry in the log with the desired user’s name in the Account Name field. The Caller Machine Name value specifies the name of the computer from whom the lock was created. LON-DC01 is the name of the computer in this situation.
Using PowerShell, locate the source of account lockout.
You can also use PowerShell to locate the account lockout source on the DC using the PDC FSMO role. To get a list of the most recent account lockout incidents on the DC, use the following code:
$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:
- Your domain is being subjected to a brute-force attack. Follow this guide to locate and disable the source computer.
- When inputting a password, the user makes mistakes. When typing a password, the user makes a mistake or forgets a password that was recently updated;
- An unclosed RDP/RDS session occurs when a user does not log out after closing (disconnecting) a remote session. You can’t avoid a situation like this by setting the force. In the domain, there is a policy to log off idle Remote Desktop sessions. The policy can be used to set this up. In the GPO section, set a time limit for active but inactive Remote Desktop Services sessions. Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits; Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits;
- In Windows Services, the user password was saved. On domain servers/computers, don’t use the user account to operate services. Instead, create a separate service account (with a password that will never expire) or create a group of Managed Service Accounts.
- User credentials were saved in Task Scheduler jobs. User accounts, like services, are frequently utilised to run the scheduler operation. To run scheduled tasks, it is preferable to use service accounts.
- Mobile devices with saved user credentials—check your mobile device’s email client settings for saved AD credentials (like Outlook, ActiveSync, etc.). If you utilise Wi-Fi authentication with Windows Active Directory via the Radius server, you may also assign stored passwords for Wi-Fi connections to this category.
- Passwords were saved in browsers, and user passwords were saved in the Windows Credential Manager. Remove all saved credentials from the Credential Manager (rundll32.exe keymgr.dll, KRShowKeyMgr).
Tracking Lockout Events with the Account Lockout Tool
To find the account lock source on all domain controllers, you can use the convenient LockoutStatus.exe tool
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
Check the box “Use Alternate Credentials” and select account credentials with domain admin capabilities if you’re running the Microsoft Account Lockout Status software as a non-privileged user. To connect to AD domain controllers and pick account locking events from the Security log, you’ll need this. The LockoutStatus.exe application accomplishes the same thing, searching the domain controller logs for events with the EventID 4740 and displaying the total data for the events and user account.
The current user state on all DCs (Locked), Lockout Time, Bad Password Count on each DC, and the name of the computer from which the lock happened are all displayed here (Orig Lock).
Instead of utilizing the ADUC console, you can unlock the user account directly from the tool. To do so, select a DC, right-click the user, and choose ‘Unlock Account’ from the context menu. This modification will be replicated instantly to all DCs in the domain, and the user will be able to connect to the domain computers. By selecting the ‘Reset User’s Password’ menu item, you may also alter the user password.
