Account lockout tools….

One of the challenges I always came up against, both as a security consultant and as an network administrator was account lockouts… I kept coming up against this in a number of ways:

– Accounts being locked out because of attempts to brute force the password.

– People forgetting their passwords (and not just users!).

– Incorrectly set up or draconian password policies.

– and more…

The challenge is that we all want to make our systems as secure as possible by having useful and well thought out security policies… However, I have come across many people over the years not implementing account lockouts, complex passwords, validity periods and monitoring / reporting because they think it will take too much effort to implement and maintain. For those who do implement password policies there is always a need for tools to help diagnose problems and manage these accounts in question. I have decided to put together a few suggestions…

There are a number of documents and tools available to help you. First of all, we need to look at why should we use account lockouts. There is a really useful white paper:

I have audited many companies who have not implemented account lockouts as they perhaps decided it wasn’t necessary. In most cases they had not implemented complex passwords either. Therefore brute forcing the user ‘John’, password ‘john’ was not difficult. Even if you are using the Windows Server 2003 defaults of:

  • Is not based on the user’s account name.
  • Contains at least six characters.
  • Contains characters from three of the following four categories:
    • Uppercase alphabet characters (A–Z)
    • Lowercase alphabet characters (a–z)
    • Arabic numerals (0–9)
    • Non alphanumeric characters (for example, !$#,%)

This may not take very long with many of the tools available out there (my favorite and not to be used for illegal purposes is l0phtcrack for password auditing, but there are many more). So the idea is that by enabling account lockouts, even if you don’t have a massively complex password structure, you can limit the amount of incorrect attempts someone can make before the account is locked out. This does have a potential draw back. If you set the number of attempts before account lockout too low, you can penalise those users like me who can’t type for toffee and may lock themselves out unwittingly. This also means you get many more support calls saying ‘ I can’t log in to my account’ and having to either reset the password and / or unlock your account. So now for some of the tools:

  • LockoutStatus.exe. Displays information about a locked-out account.
  • ALockout.dll. Helps determine the program or process sending the incorrect credentials in a scenario.
  • AcctInfo.dll. Isolates and troubleshoots account lockouts.
  • ALoInfo.exe. Displays user account names and their password age.
  • EnableKerbLog.vbs. Startup script that enables Kerberos logging.
  • EventCombMT.exe. Gathers events for event logs at many locations for a centralized view.
  • NLParse.exe. Extracts and displays desired entries from Netlogon files.

These are available as a package download-able from here.

There are some other ways of finding locked out accounts easily, some based on scripts and others on applications querying active directory. A great repository can be found at

Have Fun and let me know if you find any other tools or would like more info.

Comments (3)

  1. Gregor Suttie says:

    Many Thanks for this as I was getting locked out a lot at work and can now use these links to find out why I was being locked out.



  2. Lurker 1138 says:

    How about a self-serve website for users to recover forgotten passwords, change passwords, and update other info in AD like phone number?

  3. Drew says:

    I’ll disagree with you, Bruce. IMHO password lockout is evil. It’s an excuse to forego the use of strong passwords (or "passphrases") or smartcards and it creates the possibility for a nasty DOS attack. Even if you use IPSEC to limit logons to come from only your forest’s machines you have the possibility of malicious disgruntled employees DOSing one another. Auditing can catch the culprit after the DOS has happened, but that is more administrative overhead and it still means that some innocent was locked out and lost productivity. Even auditing might not help if the attack were spread virally to lots of machines.

    We have an account lockout policy on ntdev (the domain I’m in at work) and I also know that if I tried to lock someone out (for 30 minutes according to what rsop tells me now, but I could attack again 30 mins later) someone would porbably figure out that I did it and that would be the end of me at Microsoft. Then again, there are a few shared test accounts I know of in ntdev and we have some debuggers in our lab that are joined to the domain, so . . . I doubt I’d get away with it now that you know my evil plans. Drat!