In an organisation where you may have hundreds or thousands of AD accounts it will not be unusual to come across incidents where user’s accounts are unexpectedly locked out.
This is where the Microsoft Account Lockout and Management Tools will come in handy to help us figure out (i) which device caused the account lockout and (ii) the current lock out state of a given user account.
Looking up the current account state
After downloading and extracting the Microsoft Account Lockout and Management Tools, simply run the LockoutStatus.exe as an appropriately privileged user such as your domain admin account.
- Select File — Select Target…
- Enter the target user’s username and the domain to lookup.
- Now you will see the account status across all domain controllers. The first column will give you the domain controller names (hidden in the example below).
The User State will tell you whether the account is locked or not.
Bad Pwd Count tells you how many times the password was entered incorrectly – this will not tell you how many times it was entered incorrectly beyond the account lockout threshold. For example, if your group policy states a maximum of 5 incorrect passwords before a lockout then the Bad Pwd Count will not be a number above 5.
Last Bad Pwd will tell you the date and time of the last attempt. This will not update after the account has been locked out.
Pwd Last Set is self explanatory
Lockout Time will be the same as the Last Bad Pwd if the account is already locked out.
Orig Lock will tell you which domain controller processed the account lockout. All domain controllers will replicate the account lockout status anyway but the Orig Lock will be the initial DC that processed the log-on request.
Below is an example of what a locked out account looks like.
The Domain controller names are obscured. The Orig Lock was set to the third DC in the list. I believe the reason why Bad Pwd Count is listed twice is because even though the third DC in the list processed the original log-on request – it still needs to reference the PDC emulator.
For example; assume DC1 holds the PDC emulator role.
Now imagine you log in to a desktop PC which picks DC2 as the domain controller to authenticate against. DC2 will check with the PDC emulator (DC1) before it allows the user to log-on hence why the PDC emulator and the original requester will register a bad password count.
Finding out which machine caused the account to be locked out
This is where eventcombMT.exe comes in handy. Again, fire it up as an appropriately privileged account (or domain admin) otherwise the tool will not be able to view the security logs on the domain controllers.
- Fill in the domain name and right click the empty white box below and Get DCs in Domain
- Click the Searches menu and select Built in Searches –> Account Lockouts
- The event IDs filled by default cover older versions of Windows. Event ID 4740 covers Server 2008 R2 and above so enter that
- Now select a date range by going to the Options –> Set Date Range menu
- Now click Search in the main window
- When the search has finished, you will get an explorer window pop up with some log files (Temp directory which you can change in Options –> Set Output Directory)
- The log file will be easy to read and will look like this:
[text]4740,AUDIT SUCCESS,Microsoft-Windows-Security-Auditing,Sat Jul 25 11:25:42 2015,No User,A user account was locked out. Subject: Security ID: S-1-5-18 Account Name: DC01$ Account Domain: NETWORK Logon ID: 0x3e7 Account That Was Locked Out: Security ID: S-1-5-21-SOME-LONG-SID-HERE Account Name: mtunc Additional Information: Caller Computer Name: DESKTOP-PC-123[/text]
The long Security ID (SID) is the user’s unique security identifier.
Account Name is self explanatory and is the user’s AD account name.
The Caller Computer Name is the interesting bit which will tell us which device locked the account out. In this case, it’s a machine called DESKTOP-PC-123 which can now be investigated.
It’s possible you may find strange caller computer names – for example, you may find your Exchange CAS server listed. This is indicative of incorrect credentials on a user’s mobile device/laptop/tablet/etc. This can be investigated further by reviewing the IIS logs on the Exchange server.
Automation?
It probably wouldn’t be too difficult to script the above so that the service-desk receives an e-mail or summary of account lockouts in a given period. It would even be useful for your security/sysadmins to look through to see if there is any suspicious activity going on. If I have time to make such a script then you’ll see it here first 😉