Export (0) Print
Expand All

Configuring Account Lockout

Updated: July 31, 2004

Applies To: Windows Server 2003 with SP1

The account lockout policy settings are designed to help prevent a brute force attack on user passwords. This section describes where you can configure the setting, as well as some things that you should consider before you use the settings.

Configuring Account Lockout for Domain Users

For domain users, set the appropriate values by configuring the default domain policy in the console tree. To configure the default domain policy, open the Group Policy MMC, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Account Policies, and then double-click Account Lockout Policy. For more detailed steps, see "Account Lockout Settings" in this document.

Configuring Account Lockout for Local Users

For a stand-alone workstation, set the appropriate registry values by configuring the local policy:

  1. Click Start, click Run, type gpedit.msc, and then press ENTER.

  2. In the Group Policy Object Editor MMC, double-click Computer Configuration, double-click Windows Settings, double-click Security Settings, double-click Account Policies, and then double-click Account Lockout Policy.

  3. In the details pane, right-click the policy setting that you want, and then click Properties.

  4. If you are defining this policy setting for the first time, click Define this policy setting.

  5. Select the options that you want, and then click OK.

Microsoft recommends that you do not exempt the privileged accounts from password policies. Your privileged accounts should have complex passwords, an expiration period, and the passwords should be a minimum of fifteen characters in length. Microsoft also recommends that you also protect the local accounts (non-domain clients) by using a local password policy for all users. For all workstations in a domain, set a domain-level Group Policy object (GPO) and filter it to apply to the domain member computer.

Choosing Account Lockout Settings for Your Deployment

This section describes the ramifications of changing the various settings and a way to estimate the difficulty of using the brute force method of password guessing with a certain configuration. Like other settings that are associated with passwords, choosing settings for account lockout involves balancing the benefits and drawbacks between security, usability, and cost. The primary consideration is how much risk is acceptable when you configure the password policy of the domain. For example, consider the following two domain configurations:

  • User accounts that are in domain A have a minimum password length of 3 characters, no password complexity requirements, and passwords never expire.

  • User accounts that are in domain B have a minimum password length of 6 characters, password complexity, and passwords in the domain expire in 42 days.

There is less risk of a malicious user guessing the password of a domain B user; for the same risk tolerance, domain B can have a less stringent account lockout policy. Whether you set the LockoutDuration registry value to 0 or not also has an important on the setting that is permitted for both the ObservationWindow and LockoutThreshold registry values.

As an example, assume that the administrator resets the password when the account is locked with LockoutDuration registry value of 0. With the LockoutDuration registry value set to 0 and the LockoutThreshold registry value set to 20, the malicious user has 20 guesses to use against that password. If the lockout duration is 30 minutes, the malicious user has 20 guesses every 30 minutes against that password until it is changed. This is a very significant difference in the total number of guesses that are available to the malicious user.

In comparison, if the administrator sets the maximum password age to 42 days, the first malicious user has only 20 guesses against any given password, while the second malicious user has 40,320 guesses (20 tries for ever lockout, multiplied by 48 lockouts every day, multiplied by 42 days before the user changes the password). With the default password settings, there are approximately 1012 possible passwords. This means that the malicious user has approximately a .000004 percent (%) chance of guessing the password. With an optimized guessing scheme, this percentage would most likely be a larger percentage.

This example demonstrates that setting the LockoutDuration registry value to 0 allows the LockoutThreshold registry value to be a significantly higher number for equivalent risk tolerance. If you increase the LockoutThreshold registry value, you help to reduce the behavior of a user accidentally locking themselves out of their computer.

When you choose the setting for account lockout, it is important that you consider the inherent denial of service that is associated with a locked out account. Ideally, the only accounts that are locked out are the accounts that are being attacked. However, the computer cannot determine the difference between a user typing an incorrect password or an automated task that is using an incorrect password. As a result, from the users perspective, users who are trying to perform their daily tasks may be suddenly unable to perform their work, which incurs both the cost of support to the domain and the cost of lost work. The lower the value that you set for the LockoutThreshold registry value, the more likely this behavior is to occur. The length of the ObservationWindow registry value has much less effect on this behavior than the LockoutThreshold registry value.

Microsoft recommends that you regularly review the Security event logs of all computers so that you are aware of any patterns that might show an attack or user error. The values that are necessary to identify specific malicious users and targets can be obtained only after you implement the auditing policies that are mentioned in the "Appendix Two: Gathering Information to Troubleshoot Account Lockout Issues" section in this document. Microsoft offers an event log monitoring solution, Microsoft Operations Manager (MOM), that you can script with responses. This tool also has many other built-in actions that you can use. For more information about MOM, see the MOM Web site.

noteNote
Web addresses can change, so you might be unable to connect to the Web site or sites mentioned here.

LockoutThreshold vs. ObservationWindow

In general, the LockoutThreshold value has more of an effect on how the computer behaves than the ObservationWindow value. Most logon attempts that do not work occur during a very short period of time. Because of this, the period of time is inside of the ObservationWindow time. Users rarely type a bad password many times in a row, so the LockoutThreshold value is rarely exceeded. The exception to this is the environment where the LockoutThreshold registry value is set so low that a user could accidentally mistype their password often enough to lock themselves out (for example, if you set the LockoutThreshold value to 2). Malicious password attacks are almost always automated. A user typically locks themselves out of their computer when they type a bad password once and try to type that same bad password over and over again.

Recommended Account Lockout Settings

The security configuration for an organization is determined by the level of protection that is required in the organization's environment. In some low-security scenarios (such as in a small office where no sensitive information is stored in the system), a simple password policy may be sufficient to protect the resources. However, in a high-security environment (such as in a banking system), much stronger security protection is desired. You should use account lockout and strong password policies in these environments. In all examples, the stronger the security that is implemented, the higher the cost that is associated with maintaining that security.

The following table provides recommended account lockout settings for many different security configurations.

Table 1 Recommended Account Lockout Settings

Art Image
noteNote
"Cost" includes downtime cost for the user whose account is locked out, as well as support cost for servicing the locked out account.

Recommended Password Policy Settings

The table below provides recommended password policy settings for various security configurations.

Table 2 Recommended Password Policy Settings

Art Image

General Recommendations for Account Lockout and Password Policy Settings

In addition to the specific account lockout and password policy settings in the previous tables, there are some other configuration changes that may help you achieve the level of security that you want. These include:

  • When you enable account lockout, set the ForceUnlockLogon registry value to 1. This setting requires that Windows re-authenticates the user with a domain controller when that user unlocks a computer. This helps to ensure that a user cannot use a previously-cached password to unlock their computer after the account is locked out.

  • False lockouts can occur if you set the LockoutThreshold registry value to a value that is lower than the default value of 10. This is because users and programs can retry bad passwords frequently enough to lock out the user account. This adds to administrative costs.

  • After you unlock an account that is locked out, verify that the LockoutDuration value is set. You should do this because the value may have changed during the account unlock process.

  • Carefully consider setting the LockoutDuration registry value to 0. When you apply this setting, you may incur additional administrative labor by requiring administrators to manually unlock a locked out user account. Although this does increase security, the increased labor drawback may outweigh the security benefit.

  • Define account lockout and password policies once in every domain. Ensure that these policies are defined only in the default domain policy. This helps to avoid conflicting and unexpected policy settings.

  • Unlock an account from a computer that is in the same Active Directory site as the account. By unlocking the account in the local site, urgent replication occurs in that site which triggers immediate replication of the change. Because of this, the user account should be able to regain access to resources faster than waiting for replication to occur. Note that the AcctInfo.dll tool helps to identify an appropriate domain controller and unlock the account. For more information about AcctInfo.dll, see the "Account Lockout Tools" section in this document.

Protecting from External Account Lockout Denial of Service Attacks

It is possible for a malicious user to launch a denial-of-service attack against your enterprise from outside of your network. Because most networks are interconnected, this can be a difficult attack to mitigate. The following techniques technologies are common techniques and technologies that you can use to help mitigate or prevent such attacks:

  • Require complex passwords: All accounts should have a complex password. All administrator accounts (local and domain) should have a long, complex password and you should change the password regularly.

  • Rename the administrator account: Because the administrator account cannot be locked out, it is recommended that you rename the account. Although this does not mitigate all of the attacks against the administrator account, it does help mitigate these attacks most of the time. For more information, see "HOW TO: Rename the Administrator and Guest Account in Windows 2000" on the Microsoft Knowledge Base.

  • Protect your environment with firewalls: To avoid an account lockout denial of service attack, block the TCP and UDP ports 135 through 139 and port 445 on your routers and firewalls. When you do this, you prevent logon attempts that occur outside of your network.

  • Prevent anonymous access: Set the RestrictAnonymous value to 2 on all computers that are exposed to the internet and to the entire domain if all of the computers are running versions of Windows 2000 or later. This stops malicious users from making anonymous connections to resources and may help defeat some types of attacks. Note that some operating systems have limited support for computers that have this setting. Some programs may also have issues with this setting if the programs use an anonymous connection to gain access to resources. For more information, see "How to Use the RestrictAnonymous Registry Value in Windows 2000" on the Microsoft Knowledge Base.

  • Protect site-to-site traffic by using a VPN tunnel: If communication between domain members in two sites is required, use a site-to-site VPN tunnel to securely connect site networks together. Do not open all NetBIOS ports on the firewall. You can use the Windows 2000 Server Routing and Remote Access service to create site-to-site VPN tunnels. If no VPN devices are available, you should configure the edge firewall or router filters to limit the traffic that is permitted to flow between the Internet Protocol (IP) address ranges that are used by each site. If sites need to use Active Directory replication only across the Internet, then use Internet Protocol security (IPSec) transport mode through the firewalls to secure all traffic between Active Directory servers.

  • Protecting authentication and NetBIOS ports from Internet attack: On either the firewall or the router that connects your internal network to the Internet, block access to TCP and UDP ports 135 through 139 and port 445. If no edge filtering device is available, you can use IPSec filters to block these ports. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base.

  • In the same IPSec policy, you must create an additional rule that adds filters to permit traffic to these ports when the source address is in a subnet that is used by the internal network. To do this, use the configuration that is described in "How to Block Specific Network Protocols and Ports by Using IPSec" on the Microsoft Knowledge Base.

  • Protecting authentication and NetBIOS ports from internal attack: If you must protect access to both authentication and NetBIOS ports from internal malicious users, you can restrict the computers that are permitted to gain access to these ports to only domain member computers by using the feature in IPSec that allows you to negotiate security. By allowing only trusted computers (domain member computers) to gain access to both authentication and NetBIOS ports, you reduce the number of computers that can perform the attack. This extra protection provides a defense against any breaches in your security perimeter and against malicious users who can connect to the internal network. For information about how to create a custom IPSec policy to use Kerberos authentication when negotiating IPSec security for access to TCP and UDP ports 135 through 139 and port 445 see the "Step-by-Step Guide to Internet Protocol Security (IPSec)" on the Microsoft Web site.

  • Update the server: Keep all of your servers up-to-date with current versions of antivirus software, firewall software, and Windows security patches. This helps prevent trojan horse programs and viruses from attacking your resources if the malicious user can launch an attack from your internal network instead of from the Internet. These updates are an important part of an in-depth and defensive security strategy.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft