Chapter 3: The Domain Policy

Published: December 31, 2003   |   Updated: April 26, 2006

Overview

This 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:

  • Security settings and countermeasures at the domain level.
  • How to secure a Windows Server 2003 domain for the Legacy Client (LC), Enterprise Client (EC), and Specialized Security – Limited Functionality (SSLF) environments that are defined in Chapter 1, "Introduction to the Windows Server 2003 Security Guide."

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 Policy

You 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:

  • Domain Level. Settings at this level address common security requirements, such as account and password policies that must be enforced for all servers in the domain.
  • Baseline Level. Settings at this level address specific server security requirements that are common to all servers in the domain infrastructure.
  • Role-Specific Level. Settings at this level address security requirements for specific server roles. For example, the security requirements for infrastructure servers differ from those for servers that run Microsoft Internet Information Services (IIS).

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 Overview

Group 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:

  • Modify permissions on the file system.
  • Modify permissions on registry objects.
  • Change settings in the registry.
  • Change user rights assignments.
  • Configure system services.
  • Configure audit and event logs.
  • Set account and password policies.

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 Policies

Account 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 Policy

Complex 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:

  • Avoid the use of words from a dictionary in any language, including common or clever misspellings of words.
  • Do not create a new password that simply increments a digit in your current password.
  • Avoid the use of passwords that begin or end with a numeral because they can be guessed easier than passwords that have a numeral in the middle.
  • Avoid the use of passwords that others can easily guess by looking at your desk (such as names of pets, sports teams, and family members).
  • Avoid the use of words from popular culture.
  • Enforce the use of passwords that require you to type with both hands on the keyboard.
  • Enforce the use of uppercase and lowercase letters, numbers, and symbols in all passwords.
  • Enforce the use of space characters and characters that can be produced only by pressing the ALT key.

You should also use these guidelines for all service account passwords in your organization.

Password Policy Settings

The 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

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Enforce password history

24 passwords remembered

24 passwords remembered

24 passwords remembered

Maximum password age

42 days

42 days

42 days

Minimum password age

1 day

1 day

1 day

Minimum password length

8 characters

8 characters

12 characters

Password must meet complexity requirements

Enabled

Enabled

Enabled

Store password using reversible encryption

Disabled

Disabled

Disabled

Enforce password history

This 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 age

This 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 age

This 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 length

This 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 requirements

This 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 encryption

This 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 Required

Although 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 Policy

Account 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 Settings

The 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

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Account lockout duration

30 minutes

30 minutes

15 minutes

Account lockout threshold

50 invalid login attempts

50 invalid login attempts

10 invalid login attempts

Reset account lockout counter after

30 minutes

30 minutes

15 minutes

Account lockout duration

This 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 threshold

This 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.

  • To prevent account lockouts, set the value for Account lockout threshold setting to 0. This configuration helps reduce help desk calls because users cannot accidentally lock themselves out of their accounts. Also, DoS attacks that try to intentionally lock out accounts in your organization will not succeed. Because it will not prevent a brute force attack, choose this setting only if both of the following criteria are explicitly met:
    • The password policy requires all users to have complex passwords that consist of eight or more characters.
    • A robust audit mechanism is in place that can alert administrators when a series of account logon failures occur in the environment. For example, the audit mechanism should monitor for security event 539, which is "Logon failure. The account was locked out at the time the logon attempt was made." This event means that the account was locked out at the time the logon attempt threshold was reached. However, event 539 only shows an account lockout, not a failed password attempt. Therefore, your administrators should also monitor for a series of bad password attempts.
  • If these criteria are not met, the second option is to configure the Account lockout threshold setting to a high enough value that will provide users with the ability to accidentally mistype their password several times and not lock themselves out of their accounts. However, the value should help ensure that a brute force password attack will still lock out the account.

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 after

This 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 Policies

Kerberos 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 Options

The 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 Settings

The 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

Setting Legacy Client Enterprise Client Specialized Security – Limited Functionality

Microsoft network server: Disconnect clients when logon hours expire

Enabled

Enabled

Enabled

Network Access: Allow anonymous SID/NAME translation

Disabled

Disabled

Disabled

Network Security: Force Logoff when Logon Hours expire

Enabled

Enabled

Enabled

Microsoft network server: Disconnect clients when logon hours expire

This 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 translation

This 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:

  • Windows NT® 4.0–based Remote Access Service servers.
  • Microsoft SQL Servers™ that run on Windows NT 3.x–based or Windows NT 4.0–based computers.
  • Remote Access Service servers that run on Windows 2000–based computers that are located in Windows NT 3.x domains or Windows NT 4.0 domains.

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 expire

This 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.

Summary

This 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 Information

The following links provide additional information about topics that relate to domain policy for servers that run Windows Server 2003 with SP1.

This accelerator is part of a larger series of tools and guidance from Solution Accelerators.

Download

Get the Windows Server 2003 Security Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions