Home / server / Questions / 547739
Accepted
Stephane
Asked: 2013-10-23 01:12:14 +0800 CST

How to find the cause of locked user account in Windows AD domain

  • 772

After a recent incident with Outlook, I was wondering how I would most efficiently resolve the following problem:

Assume a fairly typical small to medium sized AD infrastructure: several DCs, a number of internal servers and windows clients, several services using AD and LDAP for user authentication from within the DMZ (SMTP relay, VPN, Citrix, etc.) and several internal services all relying on AD for authentication (Exchange, SQL server, file and print servers, terminal services servers). You have full access to all systems but they are a bit too numerous (counting the clients) to check individually.

Now assume that, for some unknown reason, one (or more) user account gets locked out due to password lockout policy every few minutes.

  • What would be the best way to find the service/machine responsible for this ?
  • Assuming the infrastructure is pure, standard Windows with no additional management tool and few changes from default is there any way the process of finding the cause of such lockout could be accelerated or improved ?
  • What could be done to improve the resilient of the system against such an account lockout DOS ? Disabling account lockout is an obvious answer but then you run into the issue of users having way to easily exploitable passwords, even with complexity enforced.
windows

3 Answers

  1. Best Answer

    Adding something I don't see in the answers given.

    What would be the best way to find the service/machine responsible for this ?

    You can't just look at the Security log on the PDCe, because, while the PDCe does have the most up-to-date information regarding account lockouts for the entire domain, it does not have the information about from which client (IP or hostname) the failed logon attempts came from, assuming that the failed logon attempts occurred on another DC besides the PDCe. The PDCe will say that "Account xyz was locked out," but it won't say from where, if the failed logons were occurring on another DC in the domain. Only the DC that actually validated the logon will record the logon failure, including the client's address. (Also not bringing RODCs into this discussion.)

    There are two good ways to find out where failed logon attempts are coming from when you have several domain controllers. Event forwarding, and Microsoft's Account Lockout Tools.

    I prefer event forwarding to a central location. Forward failed logon attempts from all your domain controllers to a central logging server. Then you only have one place to go look for failed logons in your entire domain. In fact I personally don't really love Microsoft's Account Lockout tools, so now there's one good way.

    Event forwarding. You'll love it.

    Assuming the infrastructure is pure, standard Windows with no additional management tool and few changes from default is there any way the process of finding the cause of such lockout could be accelerated or improved?

    See above. You can then have your monitoring system, such as SCOM or Nagios or whatever you use, comb that single event log and blow up your cell phone with text messages or whatever. It doesn't get more accelerated than that.

    What could be done to improve the resilient of the system against such an account lockout DOS?

    1. User education. Tell them to stop setting up Windows services to run under their domain user accounts, log off of RDP sessions when they're done, teach them how to clear the Windows Credential Vault of cached passwords for Outlook, etc.
    2. Use Managed Service Accounts where you can so users no longer have to manage passwords for those user accounts. Users muck up everything. If you give a user a choice, he or she will always make the wrong choice. So don't give them a choice.
    3. Enforcing remote session timeouts via GPO. If a user is idle in an RDP session for 6 hours, kick them off.
    • 13

  2. We had the same problem while cleaning up admin accounts in a larger environment a while back. Although the DCs audit logs technically provide the needed info, we decided to implement ManageEngine's ADAudit Plus product, which scans these logs and looks for logon attempts, along with any changes in AD. Using a the builtin reporting feature and a bit of Excel work, we were able to track down (quite easily) where the logons came from. In our case it was mostly related to admins having used admin accounts instead of service accounts when implementing various applications.

    • 3

  3. What could be done to improve the resilient of the system against such an account lockout DOS?

    You can't.

    There are a lot of things that can burn your house down. Like simple code to repeatedly request IP addresses until the DHCP scope is exhausted. Or simple code that creates directories until the MFT is full and you have to reformat your partition to restore it. You can't protect against everything.

    A more common scenario with lockouts are the people who enter their credentials in a much wider variety of devices than was common just a few years ago. Such as printers (to email scans), or a smartphone or tablet. If they forget where they entered their credentials, or if they no longer have access to the device, it's possible that device will continue to attempt authentication forever. Email auth is a tough vector to track down these devices, and even if you do, the user may not have access to it or know where it is. IP 10.4.5.27? I know of one user that had to call the help desk every day to get their account unlocked, then they would immediately logon, and then their account would lock out again. They did this for months. I told them to get their account renamed.

    Life has disincentives, we can't remove all of them.

    • 3