I wrote recently about how to reduce account lockouts and password resets. Even with these tips in place, however, it's still possible to get entangled in a difficult troubleshooting ordeal trying to figure out why user accounts repeatedly lock. Case in point: if your Active Directory domain policy requires periodic password changes and a user updates their password while actively logged into a system, they may find themselves locked out again and again. This can understandably be a stressful experience for both the user and the system administrator involved.
This may not be a problem if the user is logged into a couple of systems at once and knows which ones these are. However, if there are numerous systems they might be logged into, a major headache can ensue trying to pinpoint which one is causing the issue. It's not feasible to just reboot everything in the domain (particularly with shared systems), so short of engaging in complex network traffic analysis what can you do? Simple: use account auditing in Group Policy to locate the troublesome machine and solve the problem.
In Active Directory environments, users authenticate to computers via their domain credentials. These credentials are transmitted to the domain controllers for validation, so when authentications fail the domain controllers take note of this - if the right setting is enabled. These steps will also work for a single server against which a user keeps failing to log in; you can either edit the Default Domain Policy to enact the same change, or edit the Local Policy (found under Administrative Tools, or you can click Run then enter GPEDIT.MSC to access it).
Note that the screenshots contained in this article were taken on a Windows 2008 R2 server but these steps will apply to any GUI-based later version of Windows server.
At your domain controller (or while using an MMC console to administer the domain from your workstation), open the Group Policy Management tool. Expand the Domain Controllers folder. You will see Default Domain Controllers Policy underneath:
(Note: all screenshots were cleansed to protect confidential data)
Right-click Default Domain Controllers Policy and select Edit:
Expand Computer Configuration, Windows Settings, Security Settings, Local Policies then select Audit Policy as shown above.
Double-click Audit account logon events. Check off Define these policy settings and then check off Failure. Click OK.
Now the fun starts. Account logon failures will be logged in the Event Viewer. Access this feature and open the Security Log. Look for any events corresponding to Event ID 4771 (you can use the Filter Current Log selection in the right side of the screen to filter all events to only show this particular ID).
In the above example, I intentionally attempted to log on with the wrong password and found this event at the top of the log. Here we can see the failed authentication attempt came from the IP address 10.1.9.12, as shown in the "Client address" section.
Once you know the IP address of the problem system, you can have the user log in and disconnect their session, or do so for them while logged in as administrator (go to Task Manager, click the Users tab, then right-click the user's account name and select Disconnect.) The flurry of lockouts will then cease.
It's probably a good idea to leaf through these entries periodically to stay aware of where failed logon attempts are coming from and proactively resolve such issues, such as with expired system accounts or forgotten logon sessions. If you'd prefer automation to handle it for you, Tech Pro Research offers a toolkit to enable event triggers to monitor Windows servers. This option would enable you to receive an email, text message or other type of alert whenever account logons fail, but should be customized carefully lest your INBOX fill up or your phone go berserk from dozens or hundreds of alerts.
Note: leaving the setting to audit failed account logon events enabled can add a lot of entries to your Security log or consume excessive disk space, so you may want to consider turning this setting back to Not Defined so it is only enabled during active troubleshooting sessions.
- 10 tips to help reduce user account lockouts and password resets
- Stay on top of Active Directory events with ADAudit Plus
- How to use System Information in Windows 10 to create configuration data sets for troubleshooting
- PowerShell: The smart person's guide
- How to manage Active Directory from your iOS device
Scott Matteson is a senior systems administrator and freelance technical writer who also performs consulting work for small organizations. He resides in the Greater Boston area with his wife and three children.