Chapter 3: The Domain Policy
Published: December 31, 2003 | Updated: April 26, 2006 OverviewThis chapter uses the construction of a domain environment to demonstrate ways to address security within a Microsoft® Windows Server™ 2003 with Service Pack 1 (SP1) infrastructure. This chapter focuses on the following topics:
This information provides a foundation and a vision for how to evolve from an LC environment to an SSLF environment within a domain infrastructure. Windows Server 2003 with SP1 ships with default values that are set to a known, highly secure state. To improve the usability of this material, this chapter only discusses those settings that have been modified from the default values. For information about all default settings, see the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159. Domain PolicyYou can apply Group Policy security settings at several different levels in an organization. The baseline environment that is discussed in Chapter 2, "Windows Server 2003 Hardening Mechanisms" used Group Policy to apply settings at the following three hierarchy levels in the domain infrastructure:
The following sections of this chapter will only discuss the Domain Level policy in detail. Most of the domain security settings that are addressed are for user accounts and passwords. When you review these settings and recommendations, remember that all settings apply to every user in the domain boundary. Domain Policy OverviewGroup Policy is extremely powerful because it allows an administrator to create a standard network computer configuration. Group Policy objects (GPOs) can provide a significant portion of a configuration management solution for any organization, because they allow administrators to make security changes simultaneously on all computers in the domain or subsets of the domain. The following sections provide detailed information about the security settings that you can use to enhance the security of Windows Server 2003 with SP1. Tables are provided that summarize the settings, and detailed descriptions of how to achieve the security objectives for each setting are also provided. The settings are divided into categories that correspond to their presentation in the Windows Server 2003 Security Configuration Editor (SCE) user interface. You can simultaneously apply the following types of security changes through Group Policy:
This guide recommends that you create a new Group Policy at the domain root to apply the domain-wide policies that are discussed in this chapter. This approach will make it easier for you to test or troubleshoot the new Group Policy, because if you need to roll back changes you can simply disable it. However, some applications that are designed to work with Active Directory make changes to the built-in Default Domain Policy. These applications are not going to be aware of the new Group Policy you implemented if you follow the recommendations in this guide. Before you deploy new enterprise applications, be sure to test them thoroughly. If you encounter problems, check to see whether the application has modified account policies, created new user accounts, modified user rights, or made other changes to the Default Domain Policy or local computer policies. Account PoliciesAccount policies, which include password policy, account lockout policy, and Kerberos policy security settings, are only relevant in the domain policy for all three environments that are defined in this guide. Password policy provides a way to set complexity and change schedules for high security environments. Account lockout policy allows tracking of unsuccessful password logon attempts to initiate account lockouts if necessary. Kerberos policies are used for domain user accounts, and determine settings that relate to the Kerberos authentication protocol, such as ticket lifetimes and enforcement. Password PolicyComplex passwords that are changed on a regular basis reduce the likelihood of a successful password attack. Password policy settings control the complexity and lifetime for passwords. This section discusses each specific password policy setting and how they relate to each of the three environments that are defined in this guide: Legacy Client, Enterprise Client, and Specialized Security – Limited Functionality. Strict requirements for password length and complexity do not necessarily mean that users and administrators will use strong passwords. Although password policy may require users to comply with technical complexity requirements, additional strong security policy is needed to ensure that users create passwords that are hard to compromise. For example, Breakfast! might meet all password complexity requirements, but it is not a very difficult password to crack. If you know certain facts about the person who creates a password, you might be able to guess their password if it is based on their favorite food, car, or movie. One strategy of organizational security programs that seek to educate users about strong passwords is to create a poster that describes poor passwords and display it in common areas, such as near a water fountain or copy machine. Your organization should set strong password creation guidelines that include the following:
You should also use these guidelines for all service account passwords in your organization. Password Policy SettingsThe following table includes the password policy setting recommendations for all three environments that are defined in this guide. You can configure the password policy settings in the following location in the Group Policy Object Editor: Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy Additional information for each setting is provided in the subsections that follow the table. Table 3.1 Password Policy Setting Recommendations
Enforce password historyThis policy setting determines the number of unique new passwords that must be associated with a user account before it is possible to reuse an old password. The value can be set between 0 and 24 passwords. The default value for the Enforce password history setting in Windows Server 2003 with SP1 is the maximum, 24 passwords. Microsoft recommends this value for all three environments because it helps ensure that old passwords are not continually reused, because common vulnerabilities are associated with password reuse, and because a low number for this setting will allow users to continually recycle a small number of passwords repeatedly. Also, there are no known issues with this recommendation for environments that include legacy clients. To enhance the effectiveness of this policy setting, you may also configure the Minimum password age setting so that passwords cannot be changed immediately. This combination makes it difficult for users to reuse passwords, either accidentally or on purpose. Maximum password ageThis policy setting defines the period in which an attacker who has cracked a password may use it to access a computer on the network before the password expires. The range of values for this policy setting is from 1 to 999 days. You can configure the Maximum password age setting so that passwords expire as often as necessary for your environment. The default value for this setting is 42 days. Regular password changes can help prevent passwords from being compromised. Most passwords can be cracked if an attacker has enough time and computing power. The more frequently the password changes, the less time an attacker has to crack it. However, the lower this value is set, the greater the potential for an increase in calls to help desk support. Microsoft recommends that the Maximum password age setting be left at the default value of 42 days for all three environments that are defined in this guide. This configuration ensures that passwords are changed periodically but does not require users to change their password so often that they cannot remember what it is. To balance the needs of security and usability, you can increase the value for this policy setting in the Legacy Client and Enterprise Client environments. Minimum password ageThis policy setting determines the number of days that a password must be used before a user can change it. The range of values for the Minimum password age setting is between 0 and 999 days; a value of 0 allows the password to be changed immediately. The default value for this policy setting is 1 day. The Minimum password age setting must be less than the Maximum password age setting, unless the Maximum password age setting is configured to 0 (which means that passwords would never expire). Configure the Minimum password age to be greater than 0 if you want the Enforce password history setting to be effective. Without a minimum password age, users can cycle through passwords repeatedly until they can reuse an old favorite. Microsoft recommends that you enforce the Minimum password age default value of 1 day for all three environments that are defined in this guide. When this setting is used in conjunction with a similar low value in the Enforce password history setting, users can recycle the same passwords again and again. For example, if Minimum password age is configured to 1 day and Enforce password history is configured to 2 passwords, users would only have to wait 2 days before being able to reuse an old favorite password. However, if Minimum password age is configured to 1 day and Enforce password history to 24, users would need to change their password every day for at least 24 days before they could reuse a password—which is unlikely. Minimum password lengthThis policy setting ensures that passwords have at least a specified number of characters. Long passwords—eight or more characters—are usually stronger than short ones. When the Minimum password length setting is used, users cannot use blank passwords and they must create passwords with a specific number of characters. The default value for this setting is seven characters. This guide recommends that you configure the Minimum password length setting to eight characters for the Legacy Client and Enterprise Client environments. This configuration is long enough to provide some level of security but still short enough for users to easily remember. Also, this configuration provides a reasonably strong defense against the commonly used dictionary and brute force attacks. (Dictionary attacks use word lists to obtain a password through trial and error. Brute force attacks try every possible password or encrypted text value. The likelihood of a successful brute force attack depends on the length of the password, the size of the potential character set, and the computational power that is available to the attacker.) This guide recommends that you configure the Minimum password length setting to 12 characters for the Specialized Security – Limited Functionality environment. Each additional character in a password increases its complexity exponentially. For example, a seven-character password would have 267, or 1 x 107, possible combinations. A seven-character case-sensitive alphabetic password has 527 combinations. A seven-character case-sensitive alphanumeric password without punctuation has 627 combinations. At 1,000,000 attempts per second, it would take approximately 40 days to crack. An eight-character password has 268, or 2 x 1011, possible combinations. Although this might seem to be an overwhelmingly large number, at 1,000,000 attempts per second (a capability of many password-cracking utilities) it would take only 59 hours to try all possible passwords. Remember, these times will significantly increase for passwords that use ALT characters and other special keyboard characters, such as ! or @. Passwords are stored in the Security Accounts Manager (SAM) database or Active Directory after they are passed through a one-way (non-reversible) hash algorithm. Therefore, the only known way to tell if you have the right password is to run it through the same one-way hash algorithm and compare the results. Dictionary attacks run entire dictionaries through the encryption process, looking for matches. They are a simplistic yet very effective approach to determine who uses common words like "password" or "guest" as their account passwords. Older versions of Windows used a specific type of hashing algorithm known as the LAN Manager Hash (LMHash). This algorithm breaks up the password into blocks of seven or fewer characters and then calculates a separate hash value for each block. Although Windows 2000 Server, Windows XP, and Windows Server 2003 all use a newer hashing algorithm, they may still calculate and store the LMHash for backward compatibility. When the LMHash values are present, they present a shortcut for password crackers. If a password is seven characters or less, the second half of the LMHash resolves to a specific value that can inform a cracker that the password is shorter than eight characters. Passwords of at least eight characters strengthen even the weaker LMHash, because the longer passwords require crackers to decrypt two portions of each password instead of only one. It is possible to attack both halves of an LMHash in parallel, and the second half of the LMHash is only 1 character long; it will succumb to a brute-force attack in milliseconds. Therefore it is not really beneficial unless it is part of the ALT character set. For these reasons, the use of shorter passwords in place of longer ones is not recommended. However, minimum length requirements that are too long may cause more mistyped passwords, which can cause an increase in locked out accounts and help desk calls. Also, extremely long password requirements can actually decrease the security of an organization because users may be more likely to write their passwords down so that they do not forget them. Password must meet complexity requirementsThis policy setting checks all new passwords when they are created to ensure that they meet complexity requirements. The Windows Server 2003 policy rules cannot be directly modified. However, you can create a new version of the Passfilt.dll file to apply a different set of rules. For more information about creating a custom Passfilt.dll file, see the MSDN® article "Sample Password Filter" at https://msdn2.microsoft.com/en-us/library/ms722439. A password of 20 or more characters can actually be set so that it is easier for a user to remember—and more secure—than an eight-character password. Consider the following 27-character password—I love cheap tacos for $.99. This type of password (really a pass phrase) might be simpler for a user to remember than a shorter password such as P@55w0rd. When combined with a Minimum password length of 8, this setting makes it very difficult to mount a brute force attack. If you include upper and lower case letters and numbers in the keyspace, the number of available characters increases from 26 to 62 characters. An eight-character password then has 2.18 x 1014 possible combinations. At 1,000,000 attempts per second, it would take 6.9 years to cycle through all possible permutations. For these reasons, Microsoft recommends that the Password must meet complexity requirements setting be configured to Enabled for all three environments that are defined in this guide. Store password using reversible encryptionThis policy setting determines whether the operating system uses reversible encryption to store passwords. It supports applications that use protocols that require user passwords for authentication purposes. Passwords that are stored with an encryption method that can be reversed can be retrieved more easily than passwords that are stored with non-reversible encryption. If this setting is enabled, vulnerability is increased. For this reason, Microsoft recommends that you configure the Store password using reversible encryption setting to Disabled unless application requirements outweigh the need to protect password information. Also, environments that deploy the Challenge-Handshake Authentication Protocol (CHAP) through remote access or IAS and environments that use digest authentication for Internet Information Services (IIS) require this policy setting to be enabled. How to Prevent Users from Changing a Password Except When RequiredAlthough the password policy settings that are described in the previous section provide a range of options, some organizations require centralized control over all users. This section describes how to prevent password changes by users except when changes are required. Centralized control of user passwords is a cornerstone of a well-crafted Windows Server 2003 security scheme. You can use Group Policy to set minimum and maximum password ages as discussed earlier, but remember that frequent password change requirements can enable users to circumvent the password history setting for your environment. Requirements for passwords that are too long may also lead to more calls to the help desk from users who forget their passwords. Users can change their passwords during the period between the minimum and maximum password age settings. However, the Specialized Security – Limited Functionality environment design requires that users change their passwords only when the operating system prompts them to do so after the Maximum password age setting of 42 days. To prevent password changes (except when required), you can disable the Change Password option in the Windows Security dialog box that appears when you press CTRL+ALT+DELETE. Note that security-conscious users may want to change their passwords more often and will have to contact an administrator to do so, which will increase support costs. You can implement this configuration for an entire domain through Group Policy, or you can edit the registry to implement it for one or more specific users. For more detailed instructions about this configuration, see the Microsoft Knowledge Base article "How To Prevent Users from Changing a Password Except When Required in Windows Server 2003" at https://support.microsoft.com/?kbid=324744. Account Lockout PolicyAccount lockout policy is a Windows Server 2003 with SP1 security feature that locks a user account after a number of failed logon attempts occur within a specified time period. The number of attempts that are allowed and the time period are based on the values that are configured for the policy. Windows Server 2003 with SP1 tracks logon attempts, and the server software can be configured to disable accounts after a preset number of failed logins as a response to potential attacks. These policy settings help protect user passwords from attackers who guess passwords, and they decrease the likelihood of successful attacks on your network. However, you will likely incur higher support costs if you enable account lockout policy, because users who forget or mistype their passwords repeatedly will need assistance. Before you enable the following settings, ensure that your organization is prepared for this additional overhead. For many organizations, an improved and less-costly solution is to automatically monitor the Security event logs for domain controllers and generate administrative alerts when apparent attempts to guess passwords for user accounts occur. See Chapter 2, "Domain Level Policies," of the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP at https://go.microsoft.com/fwlink/?LinkId=15159, for additional discussion of these settings and how they interact. Account Lockout Policy SettingsThe following table summarizes the recommended account lockout policy settings. You can use the Group Policy Object Editor to configure these settings in the Domain Group Policy at the following location: Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy Additional information for each setting is provided in the subsections that follow the table. Table 3.2 Account Lockout Policy Settings
Account lockout durationThis policy setting determines the length of time before an account is unlocked and a user can try to log on again. It specifies the number of minutes a locked out account will remain unavailable. If you set the Account lockout duration value to 0, accounts will remain locked out until an administrator unlocks them. The Windows Server 2003 with SP1 default value for this policy setting is Not Defined. Although it may seem like a good idea to configure the Account lockout duration setting to never automatically unlock, such a configuration may increase the number of calls the help desk receives to unlock accounts that were locked by mistake. This guide recommends that you configure the Account lockout duration setting to 30 minutes for Legacy Client and Enterprise Client environments and to 15 minutes for Specialized Security - Limited Functionality environments. This configuration decreases the amount of operation overhead during a denial of service (DoS) attack. In a DoS attack, an attacker maliciously performs a number of failed logon attempts on all users in the organization, which locks out their accounts. The recommended settings give locked out users the chance to log on again in a reasonable amount of time without the need for assistance from the help desk. However, information about this setting value needs to be communicated to users. Account lockout thresholdThis policy setting determines the number of attempts that a user can make to log on to an account before it is locked. Authorized users can lock themselves out of their accounts in different ways. They can incorrectly enter their password or they can change their password on one computer while logged on to another computer. The computer with the incorrect password may continuously try to authenticate the user, and because the password it uses to authenticate is incorrect, the user account will eventually be locked out. To avoid lockout of authorized users, configure the Account lockout threshold setting to a high number. Because vulnerabilities can exist when the Account lockout threshold setting is configured and when it is not, distinct countermeasures for each of these possibilities are defined. Your organization should weigh the choice between the two based on the identified threats and the risks that you are trying to mitigate.
This guide recommends that you configure the Account lockout threshold setting value to 50 for the Legacy Client and Enterprise Client environments, which should provide adequate security and acceptable usability. This value will prevent accidental account lockouts and reduce help desk calls, but will not prevent a DoS attack as described earlier. However, this guide recommends that you configure this policy setting value to 10 for Specialized Security - Limited Functionality environments. Reset account lockout counter afterThis policy setting determines the length of time before the Account lockout threshold resets to 0 and the account is unlocked. If you define an Account lockout threshold, then this reset time must be less than or equal to the value for the Account lockout duration setting. The Reset account lockout counter after setting works in coordination with other settings. If you leave this policy setting at its default value or configure it to an interval that is too long, you could make your environment vulnerable to an account lockout DoS attack. Without a policy setting to reset the account lockout, administrators would have to manually unlock all accounts. Conversely, if there is a reasonable time value for this setting, users would be locked out for a set period until all of the accounts are unlocked automatically. This guide recommends that you configure the Reset account lockout counter after setting to 30 minutes for the Legacy Client and Enterprise Client environments. This configuration defines a reasonable time period that users are more likely to accept without the need for assistance from the help desk. However, this guide recommends that you configure this policy setting to 15 minutes for Specialized Security – Limited Functionality environments. Kerberos PoliciesKerberos policies are used for domain user accounts. These policies determine settings that relate to the Kerberos version 5 authentication protocol, such as ticket lifetimes and enforcement. Kerberos policies do not exist in the local computer policy. If you reduce the lifetime of Kerberos tickets, the risk of an attacker who attempts to steal passwords to impersonate legitimate user accounts is decreased. However, the need to maintain these policies increases the authorization overhead. In most environments, the default values for these policies should not be changed. Because the Kerberos settings are included in the default domain policy and enforced there, this guide does not include them in the security templates that accompany this guide. This guide recommends that no changes be made to the default Kerberos policies. For more information about these policy settings, refer to the companion guide, Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP, which is available at https://go.microsoft.com/fwlink/?LinkId=15159. Security OptionsThe three different types of account policies that are discussed earlier in this chapter are defined at the domain level and are enforced by all of the domain controllers in the domain. A domain controller always obtains the account policy from the Default Domain Policy GPO, even if there is a different account policy applied to the OU that contains the domain controller. There are three security options settings that are similar to account policies. You should apply these settings at the level of the entire domain and not within individual OUs. You can configure these settings in the Group Policy Object Editor at the following location: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options Security Options SettingsThe following table summarizes the recommended security options settings. Additional information for each setting is provided in the subsections that follow the table. Table 3.3 Security Options Settings
Microsoft network server: Disconnect clients when logon hours expireThis policy setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This policy setting affects the server message block (SMB) component. When it is enabled, client sessions with the SMB service are forcibly disconnected when the client's logon hours expire. If it is disabled, an established client session is allowed to be maintained after the client's logon hours have expired. If you enable this policy setting, you should also enable the Network security: Force logoff when logon hours expire setting. If your organization has configured logon hours for users, then it makes sense to enable the Microsoft network server: Disconnect client when logon hours expire setting. Otherwise, users who should not have access to network resources outside of their logon hours may actually be able to continue to use those resources with sessions that were established during allowed hours. This guide recommends that you configure the Microsoft network server: Disconnect client when logon hours expire setting to Enabled for the three environments that are defined in the guide. If logon hours are not used, this policy setting will have no impact. Network Access: Allow anonymous SID/NAME translationThis policy setting determines if an anonymous user can request the SID for another user. If the Network Access: Allow anonymous SID/NAME translation setting is enabled on a domain controller, a user who knows an administrator's standard well-known SID attributes could contact a computer that also has this policy enabled and use the SID to obtain the administrator's name. That person could then use the account name to initiate a password guessing attack. Because the default configuration for the Network Access: Allow anonymous SID/NAME translation setting is Disabled on member computers, they will not be affected by this policy setting. However, the default configuration for domain controllers is Enabled. If you disable this policy setting, computers that run older operating systems may not be able to communicate with domains that are based on Windows Server 2003 with SP1. Examples of such computers include:
This guide recommends that you configure the Network Access: Allow anonymous SID/NAME translation setting to Disabled for the three environments that are defined in the guide. Network Security: Force Logoff when Logon Hours expireThis policy setting determines whether to disconnect users who are connected to a local computer outside their user account's valid logon hours. This setting affects the SMB component. If you enable the Network Security: Force Logoff when Logon Hours expire setting, client sessions with the SMB server will be forcibly disconnected when the user's logon hours expire. The user will be unable to log on to the computer until their next scheduled access time. If you disable this policy setting, users will be able to maintain an established client session after their logon hours expire. To affect domain accounts, this setting must be defined in the Default Domain Policy. This guide recommends that you configure the Network Security: Force Logoff when Logon Hours expire setting to Enabled for the three environments that are defined in the guide. SummaryThis chapter discussed the need to review all domain-wide settings in the organization. Only one set of password, account lockout, and Kerberos version 5 authentication protocol policies can be configured for each domain. Other password and account lockout settings will only affect the local accounts on member servers. Plan to configure settings that will apply to all member servers of the domain, and ensure that these settings provide an adequate level of security across your organization. More InformationThe following links provide additional information about topics that relate to domain policy for servers that run Windows Server 2003 with SP1.
|
|
.jpg)