It’s been a busy month with multiple projects on the go and aside from the new deployments I’ve been doing, I’ve also been at a client’s office troubleshooting some account lockout issues in their remote office. I have yet to determine what the issue is after reviewing event logs for a few days but the whole exercise served as a great refresher for something I haven’t done for a long time. The environment isn’t extremely complex but I’ll quickly outline it here:
Logical Topology: 1 forest, 1 domain (domain.internal)
Physical Topology: 5 sites listed in AD. The site that we’re having problems with is the remote office site.
Remote Country Office Domain controllers: RMDC01, RMDC02.
Main Head Office: Head Office Country
IT Group’s Office: Head Office Country
Desktop OS: Windows 7 or Vista (No XP or 2000)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
The tool that I used was the Account Lockout and Management Tools from Microsoft and as some of you may already know, this package contains multiple small applications to assist in troubleshooting account lockout issues but because it was developed quite some time ago, the Alockout.zip and AlockoutXP.zip packages that is used to troubleshoot desktops are not compatible with Windows Vista or 7. While I was not able to use the tools to troubleshoot at the desktop level, I went ahead and used the server applications and this post will demonstrate the way I used them.
You can download the Account Lockout and Management Tools here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18465
LockoutStatus.exe and eventcombMT.exe
Generating the account lockout
The way I’m going to be mimicking the account lockout is to RDP over to DC01 and continuously use the wrong password for my “OCSTEST1” account to log in:
Tracking the invalid log on attempts:
Fire up the “LockoutStatus.exe” tool from the ALTools folder on the domain controller:
From the opened LockoutStatus tool, click on File à Select Target…:
In the Target User Name field, type in the account that has been locked out and Target Domain Name field, type in the appropriate domain:
The tool will then list the account’s status on all of the domain controllers in the domain as well as where the bad password was logged. As shown in the screenshot below, you can see that there are 2 domain controllers with a value in the Bad Pwd Count field. Which domain controller you choose doesn’t really matter but I prefer to choose the one that is not the PDC Emulator because all login events get forwarded over there and there will be more logs to traverse through:
Once you know which domain controller you’re going to parse the logs, open up eventcombMT.exe in the ALTools folder:
Right click in the Select To Search/Right Click to Add window and select Add Single Server:
In the Add Server window’s Server Name field, type in the domain controller’s name:
Since we’re going to use this parse the logs for security events, uncheck System and Error then check the following:
· Security
· Success Audit
· Failure Audit
· Success
Now that we have the domain controller, type of logs and events to search for, all that’s missing is to list the Event IDs we’d like to match. The 2 event IDs we’re interested in are:
Event 4740 or 4771:
Event ID 4740 is logged when an account is locked out:
Searching for event ID 4740 alone will give you all the account locked out logs on the domain controller but not the failed attempts to log in.
Event ID 4771 is logged when an there is a Kerberos pre-authentication failure:
This is the equivalent of a bad login attempt prior to the account being locked out. What you’ll notice is that if you include these events, the report generated from EventCombMT may be congested with other Kerberos related errors from other services so to avoid this, what you should do is also enter in the user account you’re auditing in the text string that you’d like to match:
For the purpose of this example, I’m going to type in event IDs 4740 and 4771 into the Event IDs field but also include the user account I’m auditing into the Text text field:
Highlight the domain controller and hit the Search button when ready and the EventCombMT tool will begin parsing the event log for you:
Once the parsing is complete you’ll notice that the control buttons for EventCombMT will no longer be grayed out and a Windows Explorer with the folder C:\temp will be opened:
The txt file we’re interested in is the one that begins with the domain controller’s name. Open that file and you’ll see the entries with the event IDs with the reference account name that you entered earlier:
From the entries written in the log above, you’ll be able to find the failed login attempts for OCSTEST1 through reviewing the event ID 4771 events:
4771,AUDIT FAILURE,Microsoft-Windows-Security-Auditing,Mon Jun 06 10:39:20 2011,No User,Kerberos pre-authentication failed. Account Information: Security ID: S-1-5-21-1384921881-3793137998-3288394186-33241 Account Name: ocstest1 Service Information: Service Name: krbtgt/DOMAIN Network Information: Client Address: ::ffff:10.1.1.208 Client Port: 3633 Additional Information: Ticket Options: 0x40810010 Failure Code: 0x12 Pre-Authentication Type: 2 Certificate Information: Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint: Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options and failure codes are defined in RFC 4120. If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.
The Client Address is the IP of where the login was taking place (in this case it was the someServerName server).
You can also determine when the account was locked out by reviewing the event ID 4740 entries:
4740,AUDIT SUCCESS,Microsoft-Windows-Security-Auditing,Mon Jun 06 10:39:18 2011,No User,A user account was locked out. Subject: Security ID: S-1-5-18 Account Name: DC04$ Account Domain: DOMAIN Logon ID: 0x3e7 Account That Was Locked Out: Security ID: S-1-5-21-1384921881-3793137998-3288394186-33241 Account Name: ocstest1 Additional Information: Caller Computer Name: someServerName
Note that this will also tell you where this user was trying to log in.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Note that this is just one of the many ways you can lockout and account and this situation is one of the easier ones to troubleshoot because the root cause is just failed login attempts via RDP. The more complex ones will most likely involve scheduled tasks or Exchange services related.
Hope this helps anyone out there looking for a demonstration of what the process for troubleshooting account lockout looks like.
No comments:
Post a Comment