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).
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:
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.
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.
-
English uppercase characters (A through Z).
 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. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
-
"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:
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:
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
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.
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.
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.
