Account Lockout Policy in Active Directory

    The Account Lockout Policy in Active Directory is an important security setting. You must have come across the situation that your Active Directory user account get locked many times if the number of invalid password attempts reaches the maximum count (Account lockout threshold) and if you have tried to login in that time you won’t be allowed to login up to certain time period (Account lockout duration) or until your account get unlocked manually by your system administrator. In this article, I am going to explain the three settings which exists in Account Lockout Policy

    – Account lockout duration
    – Account lockout threshold
    – Reset account lockout counter after

Account Lockout Policy Settings

First, for those who are unfamiliar, the Account Lockout Policy can be found in any Group Policy Object in Active Directory. However, it’s usually best set in the Default Domain Policy.

 Open the GPO Default Domain Policy and navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Account Lockout Policy.

You could see following window by Default. Yes, By default  Account Lockout Policy is not configured in Default Domain Policy.

 Account Lockout Policy in Active Directory

Account lockout duration:

   This security setting determines the number of minutes a locked-out account remains locked out before automatically becoming unlocked. The available range is from 0 minutes through 99,999 minutes. If you set the account lockout duration to 0, the account will be locked out until an administrator explicitly unlocks it. If an account lockout threshold is defined, the account lockout duration must be greater than or equal to the reset time.

Default: None, because this policy setting only has meaning when an Account lockout threshold is specified.

Once an account is locked out, the “Account lockout duration” is length of time the account will be locked out until resetting. If set to “0″ the lockout status will not automatically reset and an administrator will need to unlock the account manually.

Account lockout threshold:

  This security setting determines the number of failed logon attempts that causes a user account to be locked out. A locked-out account cannot be used until it is reset by an administrator or until the lockout duration for the account has expired. You can set a value between 0 and 999 failed logon attempts. If you set the value to 0, the account will never be locked out. Failed password attempts against workstations or member servers that have been locked using either CTRL+ALT+DELETE or password-protected screen savers count as failed logon attempts.

Default: 0.

The “Account lockout threshold” determines how many failed logon attempts will result in a locked account. It works in connection with the “Reset account lockout counter after” setting. If the value specified for “Account lockout threshold” is met before the counter resets, the account is locked out.

Reset account lockout counter after:

  This security setting determines the number of minutes that must elapse after a failed logon attempt before the failed logon attempt counter is reset to 0 bad logon attempts. The available range is 1 minute to 99,999 minutes. If an account lockout threshold is defined, this reset time must be less than or equal to the Account lockout duration. Default: None, because this policy setting only has meaning when an Account lockout threshold is specified.

This is the trickiest setting in the account lockout policy. One way to interpret this setting is that there is a window of time and in that window of time you can have (x) amount of failed logons before your account is locked out. However, that’s NOT how this setting works. This setting specifies the amount of time BETWEEN failed logon attempts. If you attempt to logon to an account with the wrong password, the "badPwdCount" attribute for your account is incremented by 1. This starts the clock. If the clock reaches the value specified in the "Reset account lockout counter after" setting, then the process starts from scratch. If another failed logon attempt is recorded before the "Reset account lockout counter after" setting is reached, then the "badPwdCount" attribute is incremented (again) by 1. If the badPwdCount attribute reaches the value specified for the “Account lockout threshold” the account will be locked.

Again, the important takeaway for this counter is that it’s counting BETWEEN failed logon attempts. And because of this, you should seriously consider setting this value to it’s lowest setting of 1 minute. That is assuming you ultimately decide to implement the account lockout policy. More on that in a moment.

Example Account Lockout Policy Scenario


   Account lockout duration: 5 minutes
   Account lockout threshold: 50 invalid logon attempts
   Reset account lockout counter after: 1 minutes

Let’s walk through this. If a brute force attack against your Active Directory domain is underway, it will require 50 failed logon attempts without more than a minute between each failed logon attempt to lock an account. As you can see, that would thwart ANY effective brute force attack. Sure, the attack could be slowed down enough not to trip this example account lockout policy, but who would do that, and to what end? If you have a strong enough password policy in place, there’s no way a massively slowed down brute force attack would bear fruit for a potential hacker. There would be no reason to even try. And that assumes the hacker even knows what your account lockout policy is set to in the first place.

In this example I specified a “lockout duration” of 5 minutes. This is the length of time an account will be locked out once the lockout policy is tripped. The default is 30 minutes, and I think that’s way too high. If your lockout policy does trip for non-malicious reasons, why lockout the user for a half hour? There’s certainly no reason to lockout an account that long to impede a brute force attack. A setting of 5 minutes seems reasonable. Again, we are n’t trying to increase help desk calls with this policy.

So if your company demands you implement an account lockout policy, I would seriously consider the settings in the above example as a good starting point. With 50 invalid logon attempts required to lockout an account, the lockout policy is unlikely to be tripped unless an actual brute force attack is underway.

Thanks,
Morgan
Software Developer

Advertisement

Leave a Comment