AD Account Logout Strategy

Settings in the Account Lockout Policy of the Active Directory Default Domain Policy can lead to unexpected account lockings.

This article explains why…

Settings of Account Lockout Policies

The Account Lockout policies are part of the Default Domain Policy of the domain and are configured under:

\ Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Account Policies \ Account Lockout Policy

The Account Lockout Policy includes 3 settings:

Account Lockout Duration

time until a locked account is automatically unlocked again. Choosing 0 minutes means that an account cannot be unlocked automatically but requires the intervention of an administrator.

Account Lockout Threshold

number of failed attempts allowed before the account is locked. Choosing 0 (default) means that a locking won’t ever be triggered.

Reset Account Lockout counter after

time until the number of failed attempt is automatically reset.

How does the Account Lockout Policy work?

When entering a false password at a local domain controller (DC), it sends the password to the PDC emulator for a final check. Password changes are immediately replicated to the PDC emulator making it the best entity for double-checking. In case the PDC detects a false password, two values are recorded on DC and PDC:

BadPwdCount +1

BadPasswordTime – present time

With each failed attempt the BadPwdCount, will be increased.
The account will be locked, when the the highest possible number of failed attempts set in the Account Lockout Threshold is be reached. 

After the Account Lockout Duration has passed, the account is reactivated and the BadPwdCount will be reset to 0. BadPwdCount will also be reset, when the correct password is entered after several failed attempts. And it will be reset when the time of the Reset Account Lockout counter after (Observation Window) has passed without a new failed attempt.

Problems with Locked Accounts

Problems with locked accounts can occur when programs keep trying to login after a failed login attempt or when they run with old credentials, e.g. Scheduled Tasks, disconnected RDP sessions or manually connected network drives.

Searching for the problem’s source, it can be helpful to check the Securiy Eventlog of the DC. Among other things, it records the computer name from which the locking was triggered. In scattered environments with many DCs that can be difficult as you don’t know from which DC the locking was triggered. A small tool might be able to help here: LockOutStatus.exe. As the name says, LockOutStatus checks the Lock Out status of an account on all DCs. Thus, you can work out on which DC the account was locked and which Security Eventlog you should take a closer look at.

Microsoft Download Link: LockOutStatus.exe

“OberservationWindow” too long

With strict settings this can lead to quite strange effects.
An example: Let’s assume the Account Lockout Threshold is set to a low value, like “3” and the Reset Account Lockout counter after (Observation Window) to a high value, say a couple of hours. The following situation can happen:

The attribute BadPwdCount is not replicated and counted separately on every DC. Assuming we have 3 DCs and one PDC emulator, one failed attempt on DC1 is passed on to the PCD. The PDC decides on “false password”. Afterwards, the login is successful on DC1:

DC1 BadPwdCount=0
PDC BadPwdCount=1

Within the Observation Window another failed attempt takes place on DC2 which gets passed on to the PDC. Successful login on DC2:

DC1 BadPwdCount=0
DC2 BadPwdCount=0
PDC BadPwdCount=2

The same happens with DC3:

DC1 BadPwdCount=0
DC2 BadPwdCount=0
DC3 BadPwdCount=0

The PDC now has a BadPwdCount=3 and locks the account.

The same thing happens when a valid password is entered after every failed attempt. The PDC just does not notice the correct entries. My example may be a little extreme and not quite realistic but I wanted to draw your attention to the weird effects which can be caused with imprudent or too strict guidelines.