So recently we’ve been struggling with Microsoft Active Directory problems, where some accounts are frequently locked out of AD, displaying the error message “The referenced account is currently locked out and may not be logged on to“, which usually accompanied by Event 4625 on the security section of Windows log on the event viewer.
An Active Directory account lockout is caused by several stuff, and all of them boils down to how you set your GPO’s Account Lockout Policy. The most common reason is users typing the wrong password multiple times thus topping up the limit of failed sign-in attempt set at the Account Lockout Policy. But in my case, some users reported that their account are locked overnight, as if their accounts are being used by someone when they have left the office. Turns out this problem could also happen for a couple of other reasons. which will get into later.
Most of the articles that I have read usually ended up suggesting to disable the GPO, which in a enterprise environment is sometimes impossible due to audit and other stuff, or to delete and recreate the account, which isn’t really solving the problem, because the same problem would probably happen to the new account, and you would need to delete and recreate the account over and over again.
As you might have known, the account lockout and password policy are attached to workstation instead of your account, so the first thing we need to find the offending nodes in your network . If it’s you typing the wrong password it’s pretty obvious which node it is, but in other cases, you can find them by going to the event viewer on your domain controller, and then filtering the security section of Windows Log for Event no. 4771. For example:
Event 4771s are logged when a kerberos authentication failed. The example above recorded that the account “surfer” logged a failed authentication attempt during a log on process at a node which ip address is 192.168.1.141. The problem was, as you can see, it happened at 6.34AM in the morning, the time which no one is at the office.
Turns out it’s an established RDP session, and apparently, it was made a couple days a go, using a password that is now no longer valid. My further examination revealed that this problem can be initiated by a couple of things. If you
- Miss-typed passwords, obivously,
- disconnected, old RDP sessions, just like the example above,
- Mapped drive, be it on a windows client, or from a linux node with mount command
- Mobile device with ActiveSync using old, unupdated password,
- Running a service with that particular account
- If the event 4771 is logged from your Exchange Server, then it’s probably an SMTP or POP3 authentication from a mail client using old password, or from a service that use your Exchange Server’s SMTP thus requiring SMTP authentication. Look out for event 1035 for more info regarding the offending node.
To sum it up, if you are facing this problem, consult the event 4771 on your log to find the source of the authentication attempt, and then find the offending session.
While what I do will also not permanently solve the problem, it should provides a sensible approach to the problem, and can be used as a baseline to build a proper working instruction or Standard Operating Procedures (SOP) to mitigate this problem. For example, always use a dedicated service account to register a service in windows, always log out from your RDP sessions, stuff like that.