Account lockout policies - The Good, The Bad and The Ugly

McKnife
CERTIFIED EXPERT
Published:
Updated:
Edited by: Andrew Leniart
The following article deals with account lockout policies as you may find in (but not limited to) Windows domains.  The issues discussed apply to all Windows domains whose authentication relies on passwords alone (as opposed to multifactor authentication).
Protecting accounts by means of lockout policies has unpleasant side effects. I will show what side effects there are and suggest how to find a balance between securing your accounts and not taking additional risks.

So what is it all about?

“The Good”
Imagine a hacker wants your user password – What would be a simple way (doable by anyone) to get it? Well, an attacker could write a script that tries all sort of passwords for your user accounts.

Account lockout policies are helping to block this avenue by limiting the number of tries allowed. They also enable admins to lock an account until they unlock it, ensuring they become aware of an attack.

“The Bad”
As with most security measures, usability and comfort are negatively affected as well. If a user fails to enter his password correctly x number of times, the account locks and he’ll have to find an admin to unlock it or wait until it auto-unlocks after the x number of minutes expires.

Such circumstances will (from time to time) even motivate people to lock other accounts on purpose in order to bully them. Even worse, since automated locking on purpose can be scripted as well and these scripts work very fast, they could even be used as a denial of service attack against the company. Microsoft confirms this:
...it is important to note that a denial-of-service (DoS) attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of Account lockout threshold, the attacker could potentially lock every account.

The Ugly”
Weighing “the good” vs “the bad” will eventually make you consider that you need to loosen your policy settings a bit so that the adverse effects get smaller. However, do not forget that this might not be for you to decide. Possibly, there are compliance regulations that you are bound to (maybe even by law). So let’s look at the following “case study” of an imaginary company in Germany that tries to follow the guidelines of the Federal Office for Information Security (“BSI”).

The BSI recommends
Domain and domain controller policies MUST include strong password, account lockout, Kerberos authentication, user rights, and auditing settings

The BSI explains inside notes:
(translated from BSI - IT-Grundschutz-Kompendium - Umsetzungshinweise zum Baustein APP.2.2 Active Directory (bund.de)  )

The following are security settings that can serve as a baseline for security settings within Group Policy. The specified values must be adjusted to the local conditions.
...
Account lockout policies
• Account lockout threshold: 3 Invalid login attempts
• Account lockout period: 0 (Note: account is locked out until an administrator unlocks it)
• Reset account lockout counter after: 30 minutes

So let’s say the IT security team sits down and decides to modify this baseline to the following;

Threshold: 5 attempts (because it shouldn’t take anyone more than a few tries in order to realize he does not remember his password and it’s no longer worth trying)

Lockout period: 30 minutes (because there had been cases where no admin is around that could unlock)
Reset account lockout after 1440 minutes (1 day, because “why make it any shorter?”)

[Compare that to your policy and ask yourself if you remember why you chose (or had to choose) the values that are in effect]

So let’s see what consequences these settings have when it comes to the bullying scenario.

Imagine I go to a locked PC (Mr Smith’), no one is sitting there right now, poor Mr Smith has probably just left for a smoking break outside, but his screen is locked.

I press CTRL-Shift-Del, put the cursor into the password field and simply press enter several times. Only a few seconds later - TADA, Mr Smith’s account is already locked out. Oh, he's going to be annoyed, ha, that will be nice, I'll do that again tomorrow and the day after!

Call it “Bullying for the poor”…

Sooner or later, the admin will be asked if something could be done, for example, to set a threshold of 20 instead of 5. Or the admin could possibly disable automatic lockout just for Mr Smith at least temporarily. Technically, if your admins use PSOs (password settings are set per user) and not GPOs (settings are per domain), they could define exceptions for single users.

But will the admin agree with these requests? Well, the question rather is: may he comply with them? This will have to be decided by the IT security officer, not the admin!

Let me challenge this lockout security concept and ask:
What do I risk if I don’t activate an automatic lockout mechanism?

Well, then someone could try to guess passwords by brute force.
But is that a realistic scenario? Could someone inside the office start his tool/script to try and guess a password by brute force? How would he go about doing that?

To illustrate, I am going to play the role of an attacker now, one that has access to at least one computer of your domain.

First of all, using simple commands, I will determine: is there is an active account lockout policy?
Let us assume there is none - Good for me!
Then I look at the user that I am about to attack; which machines can he log on to?
Anywhere. Very, very good for me!
Then I'll find out how long his password is still valid...
6 months, that suits me as well!
Now let's see how long his password could be...
According to the password policy, the minimum length is 8 characters... hm, not so good. It must also be complex... not good either. (again: all of this information is readable by anyone at the command line).

Now after knowing this, should I risk to begin my brute-forcing, or not? Since this is a live attack (run within the company premises against domain controllers and not in the safety of home against password hashes), it is risky in any case.

Instead, I would like you to imagine that I am doing a little “shoulder surfing” - I am observing our Mr Smith while he’s entering the password. I don't recognize exactly what he types, but at least I see and hear that Smith's password has 8 characters and that Smith presses Shift twice, once at the beginning (a big G that was, I think) and at the end (that was probably a "!"). And in between Smith definitely typed an “x” and a “u”, I also saw that, but I am unsure about the position of the two, maybe the x was the fourth and u the fifth, but maybe also the fifth and the sixth letter... Thus, four characters remain to be guessed, all were lowercase letters, and likewise, the position of the two known middle letters is not quite clear, which doubles the password space again.

Calculating, this leaves me with about 900,000 possible passwords.

Like I gathered before, I have up to 6 months to try them out, which makes about 5000 passwords a day, which is laughably little and therefore easy prey for a brute force attack – it will certainly undoubtedly succeed with no active lockout policy to stop me.

Without going into detail about the method, here is just a number for your reference: even on weak PCs with slow domain controllers it should be possible to test about 20 passwords per second, so I can try more than half a million passwords in a single working day of 8 hours. That means, after 2 days (latest) I would have Smith's password for sure!

Anyone who says "but surely DCs log failed attempts, so they will catch you" might be right. However, does this log evaluation take place regularly? Possibly, it’s only carried out every now and then and could come too late to prevent this. Anyway, even if the logs are watched, will they catch me? Or will it be possible for me to run that attack under false flags, as someone else?

It is clear to me that this game requires not only a malicious attacker but also a successful "shoulder surfing" (the attacker can read parts of the password on input) to get started, as well as a not-so-strict hard password policy. Nevertheless, I think this example is realistic.

So how can admins make this brute-forcing harder for an attacker without having to introduce a very stringent password policy at the same time?
 
Well, configure an automatic lock-out in case of repeated incorrect password entry!

What you set as threshold number is not that important, for example, let me show you what happens if I use the maximum of 999 allowed attempts until lockout. As an admin, I, therefore, set that it will be locked for 30 minutes if the password is entered incorrectly 999 times.

The one brute-forcing (I) must therefore constantly take forced breaks in order to avoid crossing this threshold now. How long is this break? This, too, is configurable. Let's set: “Reset account lockout counter after:” to 1440 minutes (=1 day).

This means that I can only test about 1000 passwords (or more precisely; a maximum of 998) per day, so it would take me up to 900 days to try the 900,000 possibilities – that's undoubtedly longer than the password's lifetime, so this measure seems to be very effective!

Now let us look at what would happen if some program Smith uses has saved his password, and Smith now changes it (that’s a typical scenario).

The automatism in the program may constantly try to send the old password to the server until the account is locked (automatisms can be very stupid...)! He would then need an admin to unlock him, as he doesn't want to wait 24 hours to do some important weekend work. Hmm, maybe we had better set this lockout period to 30 minutes or so, and not as the BSI proposes.

Let’s set "Reset account lockout counter after..." to 30 minutes as well. How many passwords can the brute-forcer now try during an 8-hour-shift? Well, every 30 minutes (for example 8am/8:30/9:00/... 3pm/3:30/4:00pm = 17 times) each time trying 1000 passwords, that will add up to about 17,000 per day. Will I get the 900,000 possibilities tested in 6 months? Do the math…, yes, I can easily do this even in 2-3 months, assuming nobody is checking the logs thoroughly.

But alas, didn’t the BSI propose, to lock already after 3 (!) failed attempts? So then I would have only 2x17=34 attempts per day and would not be able to try the 900,000 combinations in time (in fact not even after 50 years of trying!). Well, that's something. So the automatic locking against brute-forcing may be very effective, even with no admin checking the logs, ever!

The two adjusting screws "Lockout Observation Window" (influences the duration of the forced break) and the number of allowed failed attempts ("Lockout Threshold") play together and only need to be balanced appropriately, so that it is unlikely that even with a reduced password space (due to my successful shoulder surfing) it is still worth brute-forcing.

Without taking eventual regulations into account, my gut feeling tells me, that 100 failed attempts combined with an observation window of one day should fit for most of you – then, brute-forcing of 1 million passwords takes almost a whopping 30 years, while no one is annoyed by fast locking. Also, a manual lock-out by tried someone bullying you should get more difficult as well, shouldn’t it?

Let’s try that! So I am at the keyboard of Mr Smith again, this time eager to press enter not only 5 times in a row but this time 100 times – shouldn’t take more than a minute, should it? Guess again! Microsoft has implemented some “anti-hammering” mechanism that will stop constant password entry after 5 tries! Did you know that?

Try it. You will hit a wall after 5 times and find that there’s some mechanism in place, which, from try 5 on, will from time to time impose a 30-second-pause before the logon mask becomes available again! So this bullying will take very, very long to carry out, and the guy bullying will risk being seen at the keyboard.

Bottom line: While I don't think attackers are acting like that, this section was a required theoretical exercise. Although the theory is conceivable, attackers are more likely to try other ways to hijack the identities of other users. Nevertheless, this should have proved that an automatic account lockout is definitely worth considering!

In the next section, let me talk about the risk of being targeted by a denial of service attack.

From here on, let me introduce an imaginary company that has followed the BSI guidelines to the T and sticks to the baseline setting of:

- Threshold: 3 failed attempts and
- Counter reset after 30 minutes
- and then even permanently locking accounts until the admin unlocks.

I am now changing roles once more from a brute-forcer to that of a “funny” prankster, a prankster that can script a little and is a familiar with Active Directory, at least enough to know how to read out the settings that prevail. So I'm writing a script (or I take one from the Internet), which does the following:

  • It reads all domain user account names that have active accounts and are allowed to log in anywhere
  • It tries the wrong password "a" for all these accounts for three times in a row.

I park the script on a USB stick and go with it to the next PC I find unlocked and start it.

What will happen?
At a company with say 200 active AD users, they are all locked in about 30 seconds (!) This includes all service accounts and all admins that could have been used to unlock others!

Alas, all admins? No, luckily there is still the built-in domain admin "Administrator", which cannot be locked! If you have left that one active and didn’t disable it for security reasons (I don’t recommend to do that), you will be able to use that account to undo all the lockouts.

In any case, after a short time a collective outcry will go through the company, that is for sure. The admin won't ignore it.

If the serving admin is on his toes, he even has access to the password of this built-in account (maybe an envelope in the safe). He will log on with it, create a list of (locked out) users and then run a script for unlocking against that list and after less than 10 seconds of running time the haunting is over. Yes, if he is prepared, he can now even see the IP address where that attack came from and will take a look which computer that is, where it is located and who is sitting in front of it... Meanwhile, of course, I the prankster, have left whistling and the poor guy who left his computer unlocked will have to answer some serious questions.

What damage has been done?
Everything stood still for a while, some services, whose accounts have been locked, might have crashed and will now have to be searched and restarted.

In addition, the personnel did not necessarily enjoy this forced break and might of course question the skills of the admin.

What would have happened if someone had started the script, on a day while the admin was sick and without a substitute admin at hand? Then, full 30 minutes would pass before the accounts would automatically unlock. If the attacker wanted to be particularly funny, he would of course also lock the account of the user who starts the script and then lock his screen, add a timeout of 30 minutes to the script and then run it repeatedly in a loop, locking out accounts repeatedly. Ouch…

It would even be conceivable to launch this attack as a diversion while running a more serious attack against the file servers, to add a bit of confusion and distract the admins from the actual attack!

Ok, so far about the attack, now let me talk about countermeasures.

What went wrong here, apart from the fact that some computer was not locked?

1. That computer was not only unlocked, but the attacker felt confident that he had a little time for the attack since he knew the habits of the abused user!

Remedy: If the PCs are not locked by some users regularly, this must be addressed! Company agreements, including sanctions, could help!

2. The parameters of when accounts lockout and when the counter will be reset were set too strictly.

Remedy: These "hardenings" should be reconsidered (see preliminary considerations and examples above). DOES the company really HAVE to set these?

3. The massive amount of failed logins went unnoticed.

Remedy: A software component (software or appliance) could have detected that network traffic, found the offending device and, could possibly have cut off network traffic between that device and the DCs at an early stage.

There are intrusion detection systems that can be configured to block suspicious behaviour. Please test whether your existing systems detect this kind of attack by simply creating as many test accounts as you have users and then automatically "attacking" them. If your systems do not recognize an attack, check if you can tune them.

4. The attacker was able to start a script on the PC

Remedy: Preventing this is not that easy. Sure, you can quite easily ban the use of USB sticks and you can also ban the use of scripts via AppLocker, but both lead to permanently reduced comfort. It needs to be considered nevertheless.

5. The attacker could easily prepare this script (account names could be read out by anyone)

Remedy: Sadly, the fact that it is easily possible to read this information does not mean, conversely, that it is also easy to make this information unreadable!
Since some mechanisms in programs rely on that info, switching off the readability of these details will inevitably have side effects. Be very careful here.

6. There were many accounts that could log in on any machine (attention, that is even the default!)

Remedy: Why should any user be able to log on anywhere? Yes, for large offices where people change seats (and PCs) almost daily this makes sense, but in a lot of corporate environments, this is superfluous! If the number of workstations where users may logon to can be limited, the attack becomes hard to carry out. If you can reduce the number to a single fixed employee PC, the attack will even become impossible! This restriction of login permissions is done directly in the user object in the AD - do NOT use the GPOs "Allow/deny local login" - they don't help!


What you should do in any case: reduce the workstations, where the administrative users and the service accounts can log on to, to a minimum. If you need workstation support accounts, use single admins (one per machine), don’t even think of creating global admins!

7. The offending PC was allowed to communicate with the DCs

If someone would claim, "In our company, the PCs will never be unlocked, as they lock themselves after at least 2 minutes of inactivity", he has overlooked something important: the attacker could also carry out the attack from his own PC. Think of a computer lab room in a school. Some student runs that script and claims in hindsight that it wasn’t him, but rather somebody else must have run that script from his machine at a time when he was not looking at his screen. He was busy with others doing group tasks. Now will he be punished, or not?

Or, what if I bring my own mini-PC and connect it with the network cable of my office PC for a short time, just for 30 seconds, that’s enough. Since I can quickly make the mini-PC disappear afterwards, and its network card identifier (“MAC address”) is unknown on this network, no one will be able to say for sure where the attack came from, right?

The problem is that the attacking PC does not have to be in the domain. If we have set, that all users can log in from anywhere (again: this is the default!), then I can also use a non-domain PC for the attack! Likewise, even if logon workstations are limited, I could take my BYOD PC and rename it to the name of a workstation where the account I am going to attack may logon to!

Remedy: This point is very simple: Firewalls that work with authentication (for example, the Windows Firewall, if you use secured rules with Kerberos authentication) can prohibit traffic from unknown computers to the DCs.
See: Endpoint Isolation with the Windows Firewall

Conclusion
If some of these scenarios seem unrealistic to some of you: remember, if it happens, the excuse "this has never happened in the last 10 years, so I didn’t prepare for it" will not look good on you.

Since I personally consider it dangerous to disable the automatic account lockout completely, the best countermeasure, in my opinion, is item 6 – Reduce the logon workstations and possibly 7, firewalls with authentication. In addition, you should review the number of failed attempts you allow and possibly increase it considerably. That would also slow down the attack.

PS: This article reflects my own opinions and I do not claim these to be flawless. However, I have tried to argue thoroughly, so if someone has questions about it, or doubts things, or just wants to share his opinion: please take your time to read the whole article beforehand :-)


4
596 Views
McKnife
CERTIFIED EXPERT

Comments (3)

madunixI know some stuff, and I do some things.
CERTIFIED EXPERT
Most Valuable Expert 2019

Commented:
Good Work Expert. When implementing protection, you need to balance protecting accounts from attack and protecting users from being denied authorized access.
CERTIFIED EXPERT
Fellow
Expert of the Year 2017

Commented:
In recent Active Directory attacks, you do not need the password, because you can extract the "users password hash", once you have the Hash, and the user id, you can then perform mayhem!

Oh, and that's including using a null password to gain access to the "DC Account" in the first place!!!
Senior IT System EngineerSenior Systems Engineer
CERTIFIED EXPERT

Commented:
This is very great article, thank you for sharing it here !

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.

Get access with a 7-day free trial.
You Belong in the World's Smartest IT Community