Details of Account Lockout Settings and Processes
Applies To: Windows Server 2003 with SP1
With the account lockout feature enabled, access to the account is denied when the number of logon attempts that did not work exceeds the LockoutThreshold registry value (the account lockout threshold) in a specified amount of time. A locked-out account cannot be used until it is reset by an administrator or until the lockout duration for that account expires.
Account Lockout is disabled on default installations of Windows NT Server 4.0, Windows 2000, and Windows Server 2003 domains. Account lockout operation is enabled after the domain administrator enables settings in the default domain policy. The policy settings remain enabled when you upgrade domain controllers to a later version of an operating system.
Although the Group Policy Object Editor appears to support account lockout and password policy in each organizational unit, these settings actually occur across the domain; you must define the settings on the root organizational unit for the domain. Microsoft recommends that you define account lockout and password policies in only one Group Policy object (GPO) for every domain (in the Default Domain policy settings).
Password Policy Settings
The first step that you should use to secure your network is to enforce password policy settings. When you implement a secure password policy, you may not need to implement the account lockout feature.
Password Complexity
Passwords, by default, can include any combination of characters; passwords can also be blank. Microsoft recommends that you require the use of complex passwords to help ensure that passwords provide the best security possible. These complex passwords are much more resistant to attack than blank or simple passwords.
To enforce password complexity in your organization, you can enable the Password must meet complexity requirements security setting. The complexity requirements enforced by this setting are stored in Passfilt.dll. In Windows 2000 operating systems and later, Passfilt.dll is built into the operating system. In Windows NT Server 4.0, you must add the Passfilt.dll file to the operating system to achieve the same results. Passfilt.dll is included in Windows NT Server 4.0 Service Pack 2 and in later service packs.
By default, complex passwords enforced by Passfilt.dll have the following properties:
Do not contain all or part of the user's account name.
Contain characters from three of the following four categories:
English uppercase characters (A through Z).
English lowercase characters (a through z).
Base-10 digits (0 through 9).
Non-alphanumeric (for example, !, $, #, %). extended ASCII, symbolic, or linguistic characters.
Note
Depending on your environment, using extended ASCII, symbolic, or linguistic characters in passwords can have unexpected results. It is highly recommended that you test these characters before using them in production.
When implementing this policy, it is recommended to inform your users of the change in policy so that a smooth transition can take place from a simple password to a complex password. Otherwise, users may be confused by the new password criteria and circumvent security to avoid the difficulty.
You can create and register your own custom password filter if you want to modify the complexity requirements enforced in the security setting.
Password History
You can use the Password History setting to prevent users from repeatedly using the same password. When you use the password history feature, a user is prevented from using passwords that they used in the past, up to the number of passwords that you specify. You can configure Windows to retain between 0 and 24 passwords by using the Password History feature. Microsoft recommends that you set the password history to the maximum value to help ensure the least amount of password reuse by users.
In the Windows 2000 Server family and later, the location of the password history is in the Default Domain policy settings at Computer Configuration\Windows Settings\Security Settings\Account Policies\Enforce Password History.
Valid non-zero values are between 1 and 24. The default value is 24 for domain controllers running a member of the Windows Server 2003 family, 3 for domain controllers running a member of the Windows 2000 family, and 0 for all other Windows operating systems.
Minimum Password Length
You can use the Minimum Password Length setting to decrease the chances that a password can be discovered by a malicious user. For more information about the Minimum Password Length setting, see "Understanding Password Complexity" in this document.
In versions of Windows 2000 operating systems and later, you can change the Minimum Password Length setting in the Group Policy MMC, in the Default Domain policy settings at Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Minimum Password Length.
An administrator can set the value between 0 and 14 characters. Each additional character increases the total possible password permutations. However, if you set the value to 0, blank passwords are not permitted.
Valid non-zero values are between 1 and 14, with a default value of zero.
Maximum Password Age
You can use the Maximum Password Age setting to limit the time for which a given password is valid. This decreases the odds of being able to crack a password. For more information, see the example in the Passwords section in this document.
In the Windows 2000 family and later, the Maximum Password Age setting is located in the Group Policy MMC, in the Default Domain policy at Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Maximum Password Age.
This setting determines the period of time (in days) that a user can use their password before the computer requires the user to change it. You can set passwords to expire in between 1 and 999 days, or you can specify that passwords never expire by setting the number of days to 0.
Valid non-zero values are between 1 and 999, with a default value of 42.
Minimum Password Age
You can use the Minimum Password Age setting to preventing users from repeatedly changing passwords until the user is able to use their original password, if you enforce the Password History setting.
When you use the Minimum Password Age setting, you prevent the circumvention of password expiration and help to assure unique passwords.
The Minimum Password Age setting determines the period of time (in days) that a password must be used before the user can change it. You can set the value to between 1 and 999 days, or allow immediate changes by setting the number of days to 0.
Configure the Minimum Password Age setting to be a number that is larger than 0 if you want the Enforce Password History setting to be effective. If you do not set a minimum password age, users can repeatedly cycle through passwords until they are able to use an old favorite password. This could allow users to circumvent established password policy.
The Minimum Password Age setting is located in the Group Policy MMC, in Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy.
Valid non-zero values are between 1 and 999, with a default value of one for domain controllers and zero for other computers.
Account Lockout Settings
You can set the Account Lockout settings in the Active Directory Users and Computers MMC by using the procedure in this section.
Note
The value that you set for LockoutDuration cannot be a value that is less than OberservationWindow.
Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.
In the console tree, right-click the domain on which you want to set a Group Policy object.
Click Properties, and then click the Group Policy tab.
In Group Policy Object Links, click Default Domain Policy or create and name your Group Policy object, and then click Edit.
In the console tree, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Account Policies, and then click Account Lockout Policy.
In the details pane, right-click the policy setting that you want, and then click Properties.
If you are defining this policy setting for the first time, click Define this policy setting.
Click the options that you want, and then click OK.
ObservationWindow
The ObservationWindow setting (also known in Group Policy as the Reset account lockout counter after setting) is the number of minutes after which an accounts badPwdCount registry value is reset. You can use the ObservationWindow setting to help mitigate lockout issues that are initiated by users. When you enable this setting, the bad password attempt is removed from the server after a period of time.
Valid non-zero values are between 1 and 99999, with a default value of 30.
LockoutDuration
The LockoutDuration setting (also known in Group Policy as the Account lockout duration setting) is the amount of time, in minutes, that account lockout is enforced on an account that has exceeded the LockoutDuration registry value, measured from the time of lockout. If you set the LockoutDuration registry value to 0, the account is permanently locked out until either an administrator or a user who has a delegated account resets the account. If the administrator or a delegated user account does not unlock the account, the operating system unlocks the account after the number of minutes that you set in the LockoutDuration registry value. Non-zero values for the LockoutDuration registry value reduce the administrative overhead of unlocking accounts by having them unlocked automatically; however, non-zero values do not provide the added security of user validation before the account is restored.
Valid non-zero values are between 1 and 99999, with a default value of 30.
LockoutThreshold
The LockoutThreshold setting (also known in Group Policy as the Account lockout threshold setting) is the number of times that the user, computer, service, or program can send a bad password during logon authentication before the account is locked out. Account lockout occurs when the badPwdCount registry value is equal to or exceeds the LockoutThreshold value. You can adjust the LockoutThreshold value to prevent both brute force and dictionary attacks, but you can set the value too low to capture user error and other non-attack errors. Administrators often set this value too low (3 through 5), which causes a large number of account lockouts because of user error, program caching by service accounts, or issues with networking clients. If you set the LockoutThreshold value to 0, no account lockouts occur on the domain.
Valid non-zero values are between 1 and 999, with a default value of zero.
Account Lockout Values
Account lockout registry values are described in this section. These values store the information that you need to track account lockout information.
Note
These values are maintained by the operating system, so you should not manually modify them.
badPasswordTime
The badPasswordTime value stores the last time that the user, computer, or service account submitted a password that did not match the password on the authenticating domain controller This property is stored locally on each domain controller that is in the domain. A value of 0 means that the last incorrect password time is unknown. For an accurate value for the user's last incorrect password time in the domain, you must query each domain controller that is in the domain; the largest one is the accurate value. For more information, see the "LockoutStatus.exe" section in this document.
Note
The badPasswordTime registry value is not replicated between domain controllers. This attribute, however, is reported to the PDC operations master.
badPwdCount
The badPwdCount value stores the number of times that the user, computer, or service account tried to log on to the account by using an incorrect password. This value is maintained separately on each domain controller in the domain, except for the PDC operations master of the accounts domain that maintains the total number of incorrect password attempts. A value of 0 indicates that the value is unknown. For an accurate total of the user's incorrect password attempts in the domain, you must query each domain controller and use the sum of the values. For more information, see the "LockoutStatus.exe" section in this document.
Note
The badPwdCount registry value is not replicated between domain controllers. This registry value, however, is reported to the PDC operations master.
ntPwdHistory
The ntPwdHistory registry value contains the password history for the user in Windows NT Server 4.0 one-way function (OWF). Both Windows 2000 and the Windows Server 2003 family use the Windows NT Server 4.0 OWF. This property is used by only the operating system. Note that you cannot obtain the password from the password in OWF form.
Other Settings that Affect Account Lockout
This section describes another setting that affect account lockout behavior. While the setting is focused on authentication, it is closely tied with account lockout policy.
You can set the authentication settings in the Active Directory Users and Computers MMC by using the procedure in this section.
Click Start, click Settings, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Users and Computers.
In the console tree, right-click the domain on which you want to set a Group Policy object.
Click Properties, and then click the Group Policy tab.
In Group Policy Object Links, click Default Domain Policy or create and name your Group Policy object, and then click Edit.
In the console tree, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Local Policies, and then click Security Options.
In the details pane, right-click the policy setting that you want, and then click Properties.
If you are defining this policy setting for the first time, click Define this policy setting.
Click the options that you want, and then click OK.
ForceUnlockLogon
The ForceUnlockLogon setting (also known as Interactive logon: Require Domain Controller authentication to unlock workstation controls the behavior of a computer running Windows 2000, Windows XP or the Windows Server 2003 family when the computer is unlocked by a user.
With a value of 1 (or Enabled, in Group Policy), unlocking the computer also performs a synchronous logon to the domain to verify user authenticity. This option is slower than allowing cached authentication because it requires network-based authentication.
With a value of 0 (or Disabled, in Group Policy), cached information is used to verify the users identity. When the verification is successful, the user is logged on. Windows then performs an asynchronous logon to the domain in the background. This means that the user can still unlock a computer when the account is unlocked.
Valid values are 0 and 1, with a default value of 0.
For additional information about unlocking a workstation, see the following articles:
"Information About Unlocking a Workstation" in the Microsoft Knowledge Base.
"Screensaver Password Works Even If Account Is Locked Out" in the Microsoft Knowledge Base.
Replication and Account Lockout
Account lockout relies on the replication of lockout information between domain controllers to ensure that all domain controllers are notified of an accounts status. In addition, password changes must be communicated to all domain controllers to ensure that a user's new password is not considered incorrect. This data replication is accomplished by the various replication features of Active Directory and is also discussed in this section.
Immediate Replication
When you change a password, it is sent over Netlogon's secure channel to the PDC operations master. Specifically, the domain controller makes a remote procedure call (RPC) to the PDC operations master that includes the user name and new password information. The PDC operations master then locally stores this value.
Immediate replication between Windows 2000 domain controllers is caused by the following events:
Lockout of an account
Modification of a Local Security Authority (LSA) secret
State changes of the Relative ID (RID) Manager
Urgent Replication
Active Directory replication occurs between domain controllers when directory data is updated on one domain controller and that update is replicated to all other domain controllers. When a change in directory data occurs, the source domain controller sends out a notice that its directory store now contains updated data. The domain controller's replication partners then send a request to the source domain controller to receive those updates. Typically, the source domain controller sends out a change notification after a delay. This delay is governed by a notification delay. (The Windows 2000 default notification delay is 5 minutes; the Windows Server 2003 default notification delay is 15 minutes.) However, any delay in replication can result in a security risk for certain types of changes. Urgent replication ensures that critical directory changes are immediately replicated, including account lockouts, changes in the account lockout policy, changes in the domain password policy, and changes to the password on a domain controller account. With urgent replication, an update notification is sent out immediately, regardless of the notification delay. This design allows other domain controllers to immediately request and receive the critical updates. Note, however, that the only difference between urgent replication and typical replication is the lack of a delay before the transmission of the change notification. If this does not occur, urgent replication is identical to standard replication. When replication partners request and subsequently receive the urgent changes, they receive, in addition, all pending directory updates from the source domain controller, and not only the urgent updates.
When either an administrator or a delegated user unlocks an account, manually sets password expiration on a user account by clicking User Must Change Password At Next Logon, or resets the password on an account, the modified attributes are immediately replicated to the PDC emulator operations master, and then they are urgently replicated to other domain controllers that are in the same site as the PDC emulator. By default, urgent replication does not occur across site boundaries. Because of this, administrators should make manual password changes and account resets on a domain controller that is in that user's site.
The following events are not urgent replications in Windows 2000 domains:
Changing the account lockout policy
Changing the domain password policy
Changing the password on a computer account
Domain trust passwords
For additional information about urgent and immediate replication, see "Urgent Replication Triggers in Windows 2000" in the Microsoft Knowledge Base.
Single User Object On Demand Replication
In the Windows 2000 family, when an administrator resets and immediately expires a user's password on a domain controller in site A (so that the user is given a new password but forced to change it when the user first logs on), the logon may still succeed when the user logs on with that new password in site B. This occurs because the domain controller chains to the PDC operations master during authentication. However, the users password change may not replicate correctly because domain controllers in site B do not yet have the reset password. This occurs because there is replication latency between sites.
An update is available for Windows 2000 that changes this behavior. For more information to help change this behavior by implementing an "on-demand" replication scheme, see "You Cannot Change Your Password After an Administrator Resets It" on the Microsoft Knowledge Base. The updated replication scheme allows the domain controller to contact the PDC operations master to request an update of the user object that failed authentication because of an incorrect password. This helps to ensure that the authenticating domain controller receives the most current user account information as quickly as possible.
Mixed Environments with Windows NT Server 4.0 and Active Directory Domain Controllers
If servers that are running Windows NT Server 4.0 and earlier are in the domain, account lockout is not a dependable security feature.
For example, a Windows NT Server 4.0, Enterprise Edition, backup domain controller (BDC) may authenticate a user, even though the account is marked as locked out on a domain controller that is running Windows NT Server 4.0 and earlier. Also, Windows NT Server 4.0, Enterprise Edition, BDCs cannot unlock an account. The server that is running Windows NT Server 4.0, Enterprise Edition, can increment the bad password count when the user logs in with an incorrect password. That server can then report the increment to the other domain controller. However, the Windows NT Server 4.0, Enterprise Edition, BDC does not send this information to the domain controller that is running Windows NT Server 4.0 and earlier if the user logs on with the correct password. Because of this, the bad password count is not reset after the successful logon attempt.
The account lockout feature of Microsoft LAN Manager is not compatible with the account lockout feature on computers that are running Windows NT Server 4.0 and earlier. The domain controller that is running Windows NT Server 4.0 and earlier does not replicate any account lockout information to a LAN Manager BDC. If the account is marked as locked out on the Windows NT Server 4.0 and earlier domain controller, the LAN Manager BDC may still validate the user. The LAN Manager BDC displays the account lockout policy as set to "Never," even in a domain running Windows NT Server 4.0 and earlier where account lockout is enabled.
For these reasons, you should consider ensuring that all domain controllers in your network are running Windows 2000 or the Windows Server 2003 family. This is the only way to ensure that account lockout is enforced consistently across your network.