Chapter 2: Configuring the Active Directory Domain Infrastructure

Updated: April 13, 2006

Overview

Group Policy is a feature of the Active Directory® directory service that facilitates change and configuration management in Microsoft® Windows Server™ 2003 and Microsoft Windows® 2000 Server domains. However, you need to perform certain preliminary steps in your domain before you apply Group Policy to the Microsoft Windows XP Professional with Service Pack 2 (SP2) client computers in your environment.

Group Policy settings are stored in Group Policy objects (GPOs) in the Active Directory database. The GPOs are linked to containers, which include Active Directory sites, domains, and organizational units (OUs). Because Group Policy is so closely integrated with Active Directory, it is important to have a basic understanding of Active Directory structure and the security implications of different design configuration options within it before you implement Group Policy. For more information about Active Directory design, see Chapter 3, "The Domain Policy," of the Windows Server 2003 Security Guide.

Group Policy is an essential tool for securing Windows XP. This chapter provides details about how to use Group Policy to apply and maintain a consistent security policy across a network from a central location.

This guide presents options for both Enterprise Client (EC) and Specialized Security – Limited Functionality (SSLF) environments. The settings that are recommended in this chapter are identical for both desktop and laptop client computers, and because they are special-case settings they are applied at the domain root level instead of the OU level. For example, password and account lockout policies for Windows Server 2003 and Windows 2000 Server domains must be configured through a GPO that is linked to the domain root. The names of the baseline security template files for the two different environments are:

  • EC-Domain.inf
  • SSLF-Domain.inf

OU Design to Support Security Management

An OU is a container within an Active Directory domain. An OU may contain users, groups, computers, and other OUs, which are known as child OUs. You can link a GPO to an OU, and the GPO settings will be applied to the users and computers that are contained within that OU and its child OUs. To facilitate administration you can delegate administrative authority to each OU. OUs provide an easy way to group users, computers, and other security principals, and they also provide an effective way to segment administrative boundaries. Microsoft recommends that organizations assign users and computers to separate OUs, because some settings only apply to users and other settings only apply to computers.

You can delegate control over a group or an individual OU by using the Delegation Wizard in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in tool. See the “More Information” section at the end of this chapter for links to documentation about how to delegate authority.

One of the primary goals of an OU structure design for any environment is to provide a foundation for a seamless Group Policy implementation that applies to all workstations in Active Directory and ensures that they meet the security standards of your organization. The OU structure must also be designed to provide adequate security settings for specific types of users in an organization. For example, developers may be permitted to do things on their workstations that average users should not be allowed to do. Also, laptop users may have slightly different security requirements than desktop users. The following figure illustrates a simple OU structure that is sufficient for the Group Policy discussion in this chapter. The structure of this OU may differ from the organizational requirements of your environment.

 

Figure 2.1 An OU structure for Windows XP computers

Figure 2.1 An OU structure for Windows XP computers

 

Department OU

Because security requirements often vary within an organization, it may make sense to create department OUs in your environment. The departmental security settings can be applied through a GPO to the computers and users in their respective department OUs.

Secured XP Users OU

This OU contains the accounts for users in both the EC and SSLF environments. The settings that are applied to this OU are discussed in the “User Configuration” section of Chapter 4, "Administrative Templates for Windows XP."

Windows XP OU

This OU contains child OUs for each type of Windows XP client computer in your environment. Guidance is included in this guide for desktop and laptop computers. For this reason, a Desktop OU and a Laptop OU have been created.

  • Desktop OU. This OU contains desktop computers that constantly remain connected to your network. The settings that are applied to this OU are discussed in detail in Chapter 3, "Security Settings for Windows XP Clients," and Chapter 4, "Administrative Templates for Windows XP."
  • Laptop OU. This OU contains laptop computers for mobile users that are not always connected to your network. Chapter 3, "Security Settings for Windows XP Clients," and Chapter 4, "Administrative Templates for Windows XP" provide detailed discussion of the settings that are applied to this OU.

GPO Design to Support Security Management

Use GPOs to ensure that specific policy settings, user rights, and behavior apply to all workstations or users within an OU. The use of Group Policy instead of manual configuration makes it simple to update a number of workstations or users in the future with additional changes. Manual configuration is inefficient, because it requires a technician to visit each client computer. Also, if policy settings in domain–based GPOs are different than those that are applied locally, the domain–based GPO policy settings will overwrite the locally-applied policy settings.

 

Figure 2.2 GPO application order

Figure 2.2 GPO application order

See full-sized image

 

This figure shows the order in which GPOs are applied to a computer that is a member of the Child OU, from the lowest order (1) to the highest (5). Group Policies are applied first from the local policy of each Windows XP workstation. After the local policies are applied, any GPOs are applied at the site level, and then at the domain level.

For Windows XP client computers that are nested in several OU layers, GPOs are applied in order from the highest OU level in the hierarchy to the lowest. The final GPO is applied from the OU that contains the client computer. This order of GPO processing—local policy, site, domain, parent OU, and child OU—is significant because GPOs that are applied later in the process will overwrite those applied earlier. User GPOs are applied in the same manner.

The following considerations apply when you design Group Policy.

  • An administrator must set the order in which you link multiple GPOs to an OU, or the policies will be applied by default in the order they were linked to the OU. If the same setting is configured in multiple policies, the policy that is highest on the policy list for the container will take precedence.
  • You may configure a GPO with the Enforced option. If you select this option, other GPOs cannot override the settings that are configured in this GPO.Note: In Windows 2000, the Enforced option is referred to as the No Override option.
  • You may configure an Active Directory, site, domain, or OU with the Block policy inheritance option. This option blocks GPO settings from GPOs that are higher in the Active Directory hierarchy unless they have the Enforced option selected. In other words, the Enforced option has precedence over the Block policy inheritance option.
  • Group Policy settings apply to users and computers, and are based on where the user or computer object is located in Active Directory. In some cases, user objects may need policy applied to them based on the location of the computer object, not the location of the user object. The Group Policy loopback feature gives the administrator the ability to apply user Group Policy settings based on which computer the user is logged on to. For more information about loopback support, see the Group Policy white paper that is listed in the “More Information” section at the end of this chapter.

The following figure expands the preliminary OU structure to show how GPOs may be applied to Windows XP client computers that belong to the Laptop and Desktop OUs.

 

Figure 2.3 Expanded OU structure to accommodate Windows XP–based desktop and laptop computers

Figure 2.3 Expanded OU structure to accommodate Windows XP–based desktop and laptop computers

See full-sized image

 

In the previous example, laptop computers are members of the Laptop OU. The first policy that is applied is the local security policy on the laptop computers. Because there is only one site in this example, no GPO is applied at the site level, which leaves the Domain GPO as the next policy to be applied. Finally, the Laptop GPO is applied.

Note:The desktop policy is not applied to any laptops because it is not linked to any OUs in the hierarchy that contains the Laptop OU. Also, the Secured XP Users OU does not have a corresponding security template (.inf file) because it only includes settings from the Administrative Templates.

To show how precedence works, consider an example scenario in which the Windows XP OU policy setting for Allow logon through Terminal Services is set to the Administrators group and the Laptop GPO setting for Allow logon through Terminal Services is set to the Power Users and Administrators groups. In this example, a user whose account is in the Power Users group can log on to a laptop through Terminal Services because the Laptop OU is a child of the Windows XP OU. If the No Override policy option in the Windows XP GPO is enabled, only those with accounts in the Administrators group are allowed to log on to the client computer through Terminal Services.

Security Templates

Security templates are text files that contain security setting values. They are subcomponents of GPOs, The policy settings that are contained in security templates can be modified in the MMC Group Policy Object Editor snap-in, and they are located under the Computer Configuration\Windows Settings\Security Settings folder. You can also modify these files with the MMC Security Templates snap-in or with a text editor such as Notepad. Microsoft recommends that you use the Group Policy Object Editor snap-in to manage policy settings in security templates that are in GPOs, and that you use the Security Templates snap-in to manage policy settings in stand-alone security templates.

Some sections of the template files contain specific access control lists (ACLs) that are defined by the Security Descriptor Definition Language (SDDL). For details about how to edit security templates and SDDL, see the “More Information” section at the end of this chapter.

Security Template Management

It is very important to store a production environment's security templates in a secure location in the infrastructure. Access to security templates should only be assigned to the administrators who are responsible for Group Policy implementation. The security templates that are included with Windows XP, Windows 2000, and Windows Server 2003 are stored in the %SystemRoot%\security\templates folder by default. As explained in Chapter 1, the security templates that are included with this guide are copied to the \Windows XP Security Guide Tools and Templates\Security Templates folder when you execute the .msi file that is included with the WinZip archive file that contains this guide. (The download version of the Windows XP Security Guide is available at https://go.microsoft.com/fwlink/?LinkId=14840.) You may want to copy or move the security templates from this folder to a new location on test computers while you assess and refine the settings to fit your organization’s business requirements. After testing is complete, you should move the final versions of the security templates to a centralized location, such as the default location of the built-in security templates.

The %SystemRoot%\security\templates folder is not replicated across domain controllers. Therefore, you will need to select a domain controller to hold the master copy of the security templates so that you do not encounter version control problems with the templates. This best practice ensures that you will always modify the same copy of the templates.

Importing a Security Template

Perform the steps in the following procedure to import a security template.

To import a security template into a GPO

  1. Navigate to the Windows Settings folder in the Group Policy Object Editor.
  2. Expand the Windows Settings folder and select Security Settings.
  3. Right-click the Security Settings folder, and then click Import Policy...
  4. Select the security template you want to import, and click Open. The settings from the file will be imported into the GPO.

Administrative Templates

Additional security settings are available in Unicode-based files that are called Administrative Templates. These files contain registry settings that affect Windows XP and its components, along with other applications such as Microsoft Office 2003. Administrative Templates may include computer settings as well as user settings. Computer settings are stored in the HKEY_LOCAL_MACHINE registry hive. User settings are stored in the HKEY_CURRENT_USER registry hive.

Administrative Template Management

It is important to store the Administrative Templates that are used in a production environment in a secure location in the infrastructure, just as it is important to store the security templates securely. Only administrators who are responsible for Group Policy implementation should have access to this location. Administrative Templates that ship with Windows XP and Windows Server 2003 are stored in the %systemroot%\inf directory. Additional templates for Office 2003 are included with the Office 2003 Resource Kit. The Administrative Templates that are provided by Microsoft should not be edited because they may change when service packs are released.

Adding an Administrative Template to a Policy

In addition to the Administrative Templates that shipped with Windows XP, you may want to apply the Office 2003 templates to those GPOs in which you want to configure Office 2003 settings. Or you may have created custom Administrative Templates that are unique to your organization. Use the following procedure to add an administrative template to a GPO.

To add an Administrative Template to a GPO

  1. Navigate to the Administrative Templates folder in the Group Policy Object Editor.
  2. Right-click the Administrative Templates folder and then click Add/Remove Templates.
  3. In the Add/Remove Templates dialog box, click Add.
  4. Navigate to the folder containing your Administrative Template files.
  5. Select the template you want to add, click Open, and then Close.

Domain Level Group Policy

The domain level Group Policy includes settings that apply to all computers and users in the domain. This guide suggests that you configure domain level settings in a new GPO rather than in the built-in Default Domain Policy. The reason for this suggestion is that it will facilitate your ability to restore the default settings if the changes that are introduced in this guide cause problems. You should note that some applications automatically configure the Default Domain Policy, and policy settings that are changed by such applications may conflict with settings that are defined in the Domain Policy GPO that is described in this guide. However, the risk of such an occurrence is small, because only a handful of settings are configured at the domain level. Domain level security is discussed in detail in Chapter 3, “The Domain Policy" of the Windows Server 2003 Security Guide, which is available at https://go.microsoft.com/fwlink/?LinkId=14845.

Password Policy Settings

Complex passwords that change regularly reduce the likelihood of a successful password attack. Password policy settings control the complexity and lifetime of passwords and can only be configured by Group Policy at the domain level. For information about how to set password policies directly in the local Security Account Manager (SAM) on stand-alone computers, see Chapter 5, "Securing Stand-Alone Windows XP Clients."

This section discusses each password policy setting for the EC and SSLF environments.

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

The following table summarizes the password policy setting recommendations for the two types of secure environments defined in this guide. More detailed information about each of the settings is provided in the following subsections.

Table 2.1 Password Policy Setting Recommendations

Setting Domain controller default EC SSLF

Enforce password history

24 passwords

24 passwords

24 passwords

Maximum password age

42 days

90 days

90 days

Minimum password age

1 day

1 day

1 day

Minimum password length

7 characters

8 characters

12 characters

Password must meet complexity requirements

Enabled

Enabled

Enabled

Store password using reversible encryption for all users in the domain

Disabled

Disabled

Disabled

Enforce password history

This policy setting determines the number of unique new passwords that have to be associated with a user account before an old password can be reused. The value for this policy setting must be between 0 and 24 passwords. The default value for Windows XP is 0 passwords, but the default setting in a domain is 24 passwords. To maintain the effectiveness of this policy setting, use the Minimum password age setting to prevent users from repeatedly changing their password.

Configure the Enforce password history setting to 24 passwords for the two security environments that are defined in this guide.

Maximum password age

Values for this policy setting range from 1 to 999 days. (You may also set the value to 0 to specify that passwords never expire.) This policy setting defines how long a user can use their password before it expires. The default value for this policy setting is 42 days. Most passwords can be cracked; therefore, the more frequently the password is changed the less opportunity an attacker has to use a cracked password. However, the lower this value is set, the higher the potential for an increase in calls to help desk support.

Configure the Maximum password age setting to a value of 90 days for the two security environments that are defined in this guide.

Minimum password age

This policy setting determines the number of days that a password must be used before a user may change it. The range of values for this policy setting is between 1 and 998 days. (You may also set the value to 0 to allow immediate password changes.) The default value for this policy setting is 0 days.

The value for the Minimum password age setting must be less than that specified for the Maximum password age setting, unless the value for the Maximum password age setting is configured to 0, which causes passwords never to expire. If the value for the Maximum password age setting is configured to 0, the value for this policy setting can be configured to any value between 0 and 999.

If you want the Enforce password history setting to be effective, configure this value to be greater than 0. If the Minimum password age setting is 0, users can cycle through passwords repeatedly until they can re-use an old favorite.

Configure the Minimum password age setting to a value of 1 day for the two security environments that are defined in this guide. This value discourages users from repeated re-use of the same password because it requires them to wait a full day before they can change passwords. It also encourages users to remember new passwords because they must use them for at least a day before they can reset them. Finally, it does not allow users to circumvent the Enforce password history setting restriction.

Minimum password length

This policy setting determines the least number of characters that make up a password for a user account. There are many different theories about how to determine the best password length for an organization, but perhaps "pass phrase" is a better term than "password." In Microsoft Windows 2000 and later versions, pass phrases can be quite long and can include spaces. Therefore, a phrase such as "I want to drink a $5 milkshake" is a valid pass phrase; it is a considerably stronger password than an 8 or 10 character string of random numbers and letters, and yet is easier to remember. Remember that users must be educated about the proper selection and maintenance of passwords, especially with regard to password length.

In the EC environment, ensure that the value for the Minimum password length setting is configured to 8 characters. This policy setting is long enough to provide adequate security, but still short enough for users to easily remember. In the SSLF environment, configure the value to 12 characters.

Password must meet complexity requirements

This policy setting checks all new passwords to ensure that they meet basic requirements for strong passwords. By default, the value for this policy setting in Windows XP is configured to Disabled, but it is Enabled in a Windows Server 2003 domain.

Each additional character in a password increases its complexity exponentially. For instance, a seven-digit all lower-case alphabetic password would have 267 (approximately 8 x 109 or 8 billion) possible combinations. At 1,000,000 attempts per second (a capability of many password-cracking utilities), it would only take 133 minutes to crack. A seven-character alphabetic password with case sensitivity has 527 combinations. A seven-character case-sensitive alphanumeric password without punctuation has 627 combinations. An eight-character password has 268 (or 2 x 1011) possible combinations. Although this might seem to be a mind-boggling number, at 1,000,000 attempts per second 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 @.

Proper use of the password settings can make it very difficult, if not impossible, to mount a brute force attack.

Store password using reversible encryption for all users in the domain

This policy setting determines whether the operating system stores passwords in a way that uses reversible encryption; it provides support for application protocols that require knowledge of the user's password for authentication purposes. Passwords that are stored with reversible encryption are essentially the same as plaintext versions of the passwords. For this reason, this policy setting should never be enabled unless application requirements outweigh the need to protect password information. The default value for this policy setting is Disabled.

This policy setting must be enabled when using the Challenge-Handshake Authentication Protocol (CHAP) through remote access or Internet Authentication Service (IAS). It is also required when using Digest Authentication in Microsoft Internet Information Services (IIS).

Ensure that the Store password using reversible encryption for all users in the domain setting is configured to Disabled, which is how it is configured in the Default Domain GPO of Windows Server 2003 and in the local security policy for workstations and servers. This policy setting is also Disabled in the two environments that are defined in this guide.

Preventing Users from Changing Passwords Except When Required

In addition to the password policies that are described earlier in this chapter, centralized control over all users is a requirement for some organizations. This section describes how to prevent users from changing their passwords except when they are required to do so.

Centralized control of user passwords is a cornerstone of a well-crafted Windows XP security scheme. You can use Group Policy to set minimum and maximum password ages as discussed previously. However, frequent password change requirements can enable users to circumvent the Enforce password history setting for your environment. Requirements for passwords that are too long may also lead to more help desk calls 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 security design requires that users change their passwords only when prompted by the operating system after their passwords have reached the maximum age of 42 days. To achieve this level of control, administrators can disable the Change Password... button in the Windows Security dialog box that appears when you press CTRL+ALT+DELETE.

You can implement this configuration for an entire domain through Group Policy, or implement it for one or more specific users by editing the registry. For more detailed information about this configuration, see Microsoft Knowledge Base article 324744, "How To: Prevent Users from Changing a Password Except When Required in Windows Server 2003,” which is available at https://support.microsoft.com/default.aspx?scid=324744. If you have a Windows 2000 domain, see Microsoft Knowledge Base article 309799, "How To: Prevent Users from Changing a Password Except When Required in Windows 2000" at https://support.microsoft.com/default.aspx?scid=309799.

Account Lockout Policy Settings

The account lockout policy is an Active Directory security feature that locks a user account and prevents logon after a specified number of failed logon attempts occur within a specified time period. Logon attempts are tracked by domain controllers. The number of allowed attempts and the time period are based on the values that are configured for the account lockout settings. The duration of the lockout can also be specified.

These policy settings help prevent attackers from guessing user passwords, and they decrease the likelihood of successful attacks on your network environment. However, an enabled account lockout policy will probably result in more support issues for network users. Before you enable the following settings, ensure that your organization wants to accept this additional management overhead. For many organizations, an improved and less-costly solution is to automatically scan the Security event logs for domain controllers and generate administrative alerts when it appears that someone is attempting to guess passwords for user accounts.

You can configure the account lockout policy settings in the following location in the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy

The following table includes the account lockout policy setting recommendations for both of the security environments that are defined in this guide. More detailed information about each of the settings is provided in the following subsections.

Table 2.2 Account Lockout Policy Setting Recommendations

Setting Domain controller default EC SSLF

Account lockout duration

Not defined

15 minutes

15 minutes

Account lockout threshold

0 invalid logon attempts

50 invalid logon attempts

10 invalid logon attempts

Reset account lockout counter after

Not defined

15 minutes

15 minutes

Account lockout duration

This policy setting determines the length of time that must pass before an account is unlocked and a user can try to log on again. The setting does this by specifying the number of minutes a locked out account will remain unavailable. If the value for this policy setting is configured to 0, locked out accounts will remain locked out until an administrator unlocks them. The Windows XP default value for this policy setting is Not Defined.

To reduce the number of help desk support calls and also provide a secure infrastructure, configure the value for the Account lockout duration setting to 15 minutes for both the EC and SSLF environments that are defined in this guide.

Although it might seem like a good idea to configure the value for this policy setting to never automatically unlock accounts, such a configuration will likely increase the number of calls that the help desk receives to unlock accounts that were locked by mistake. The recommended setting value of 15 minutes was determined to be a reasonable amount of time for users to wait to log on again if they are locked out of their accounts. Users should also be made aware of how this policy is configured so that they realize they only need to call the help desk if they have an extremely urgent need to regain access to their computer.

Account lockout threshold

This policy setting determines the number of logon attempts that a user can make before an account is locked. Authorized users can lock themselves out of an account by mistyping their password or by remembering it incorrectly, or by changing their password on one computer while logged on to another computer. The computer with the incorrect password will continuously try to authenticate the user, and because the password it is using to authenticate is incorrect, the user account is eventually locked out. To avoid accidental lockout of authorized users, set the account lockout threshold to a high number. The default value for this policy setting is 0 invalid logon attempts, which disables the account lockout feature.

Configure the value for the Account lockout threshold setting to 50 invalid logon attempts for EC environments and 10 for SSLF environments.

Because it is possible for an attacker to use this lockout state as a denial of service (DoS) by triggering a lockout on a large number of accounts, your organization should determine whether or not to use this policy setting based on identified threats and the risks you wish to mitigate. There are two options to consider for this policy setting.

  • Configure the value for Account lockout threshold to 0 to ensure that accounts will not be locked out. This setting value will prevent a DoS attack that attempts to lock out accounts in your organization. It will also reduce help desk calls, because users will not be able to lock themselves out of their accounts accidentally. However, this setting value will not prevent a brute force attack. The following defenses should also be considered:
    • A password policy that forces all users to have complex passwords made up of 8 or more characters.
    • A robust auditing mechanism to alert administrators when a series of account lockouts occurs in the environment. For example, the auditing solution should monitor for security event 539, which is a logon failure. This event means that the account was locked out at the time the logon attempt was made.

The second option is:

  • Configure the value for Account lockout threshold to a value that will provide users with the ability to accidentally mistype their password several times but will lock out the account if a brute force password attack occurs. A setting value of 50 invalid logon attempts for EC environments and 10 for SSLF type environments should ensure adequate security and acceptable usability. This configuration will prevent accidental account lockouts and reduce help desk calls, but will not prevent a DoS attack as described in the previous option.

Reset account lockout counter after

This policy setting determines the length of time before the Account lockout threshold resets to zero. The default value for this policy setting is Not Defined. If the Account lockout threshold is defined, then this reset time must be less than or equal to the value for the Account lockout duration setting.

Configure the value for the Reset account lockout counter after setting to 15 minutes for both the EC and SSLF environments that are defined in this guide.

If you leave this policy setting at its default value or configure the value to an interval that is too long, your environment could be vulnerable to a DoS attack. An attacker could maliciously perform a number of failed logon attempts on all users in the organization, which will lock out their accounts as described earlier in this chapter. If no policy is determined to reset the account lockout, administrators would have to manually unlock all accounts. Conversely, if a reasonable time value is configured for this policy setting, users would be locked out for a set period until all of the accounts are unlocked automatically. The recommended setting value of 15 minutes was determined to be a reasonable amount of time that users are likely to accept, which should help to minimize the number of calls that are made to the help desk. Users should also be made aware of how this policy is configured so that they realize they only need to call the help desk if they have an extremely urgent need to regain access to their computer.

User Rights Assignment Settings

User rights are described in detail in Chapter 3, "Security Settings for Windows XP Clients." However, the Add workstations to domain user right should be assigned to all domain controllers and therefore is discussed in this chapter. Additional information about member server and domain controller settings may be found in the Chapters 4 and 5 of the Windows Server 2003 Security Guide.

Add workstations to domain

This policy setting allows the user to add a computer to a specific domain.

Table 2.3 User Rights Assignment Setting Recommendations

Setting Domain controller default EC SSLF

Add workstations to domain

Authenticated Users

Administrators

Administrators

For the Add workstations to domain setting to take effect, it must be assigned to the user in a GPO that is applied to all of the domain controllers for the domain. A user who is assigned this right can add up to 10 workstations to the domain. Users who are assigned the Create Computer Objects permission for an OU or the Computers container in Active Directory can also join a computer to a domain and add an unlimited number of computers to the domain, regardless of whether they have been assigned the Add workstations to domain user right or not.

By default, all users in the Authenticated Users group have the ability to add up to 10 computer accounts to an Active Directory domain. These new computer accounts are created in the Computers container.

In an Active Directory domain, each computer account is a full security principal with the ability to authenticate and access domain resources. Some organizations want to limit the number of computers in an Active Directory environment so that they can consistently track, build, and manage them. Such management efforts can be hampered if users are allowed to add workstations to the domain. Also, this user right provides users with a way to perform activities that are more difficult to trace because they can create additional unauthorized domain computers.

For these reasons, the Add workstations to domain user right is assigned only to the Administrators group in the two environments that are defined in this guide.

Security Option Settings

Account policy must be defined in a GPO that is linked at the domain level, such as policy settings in the Default Domain Policy. Domain controllers always obtain account policy from the domain level GPOs, even if there is a different account policy set in a GPO that is applied to the OU that contains the domain controller.

Three security option settings that are similar to account policies should be considered at the domain level. You can configure these security option settings in the following location in the Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

The following table summarizes the security option setting recommendations for the two types of secure environments that are defined in this guide. More detailed information about each of the settings is provided in the following subsections.

Table 2.4 Security Option Setting Recommendations

Setting Domain member default EC SSLF

Microsoft network server: Disconnect clients when logon hours expire

Not defined

Enabled

Enabled

Network Access: Allow anonymous SID/NAME translation

Not defined

Disabled

Disabled

Network Security: Force logoff when logon hours expire

Disabled

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 network outside their user account's valid logon hours. This policy setting affects the server message block (SMB) component. When this policy setting is enabled, it causes client computer sessions with the SMB service to be forcibly disconnected when the client's logon hours expire. If it is disabled, an established client computer session is allowed to continue after the client's logon hours have expired. When enabling this policy setting, ensure that the Network security: Force logoff when logon hours expire setting is also enabled.

Note:Server message block is the foundation for shared resources in Windows networks. Settings that affect SMB will therefore affect shared resources such as folders and printers.

If your organization has configured logon hours for users, then it makes sense to enable the Microsoft network server: Disconnect clients when logon hours expire setting. Otherwise, users who are assumed to be unable to access network resources outside of their logon hours may actually be able to access those resources through sessions that were established during allowed hours.

If logon hours are not used in your organization, this policy setting will have no affect, even if it is enabled. If logon hours are used, then user sessions will be terminated when their logon hours expire.

Network Access: Allow anonymous SID/NAME translation

The Network Access: Allow anonymous SID/NAME translation setting determines if an anonymous user can request the SID for another user. If this policy setting is enabled on a domain controller, a user who knows an administrator's SID attributes could contact a computer that also has this policy setting enabled and use the SID to obtain the administrator's account information. That person could then use the account to initiate a password guessing attack. The default setting on member computers is Disabled. However, the default setting for domain controllers is Enabled. If this policy setting is disabled, the following systems may be unable to communicate with Windows Server 2003–based domains:

  • Microsoft Windows NT® 4.0–based Remote Access Service servers.
  • 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.
  • Microsoft SQL Server that run on Windows NT 3.x–based or on Windows NT 4.0–based computers.
  • SQL Server that runs on Windows 2000–based computers that are located in Windows NT 3.x domains or in Windows NT 4.0 domains.
  • Users in Windows NT 4.0 resource domain who want to assign permissions to access files, shared folders, and registry objects to user accounts from account domains that contain Windows Server 2003 domain controllers.

Network Security: Force logoff when logon hours expire

The Network Security: Force logoff when logon hours expire setting determines whether to disconnect users who are connected to the local network outside their user account's valid logon hours. This policy setting affects the SMB component.

If you enable this policy setting, client computer sessions with the SMB server will be disconnected when the user’s logon hours expire and they will be unable to log on to the system until their next allowed access time. If you disable this policy setting, established client computer sessions will be maintained after the user’s logon hours expire. To affect domain accounts, this policy setting must be defined in a GPO that is linked to the domain root.

Kerberos Policy

Policy for the Kerberos version 5 authentication protocol is configured on domain controllers, not member computers of the domain. This policy determines settings that are related to the Kerberos protocol, such as ticket lifetimes and enforcement. Kerberos settings do not exist in the local computer policy. In most environments, the default values for these settings should not be changed. This guidance does not provide any changes for the default Kerberos policy. For more information about these 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.

OU Level Group Policy

Security settings that are included in the OU Level Group Policy should be specific to the OU. Such settings include both computer settings and user settings. To facilitate manageability and improve security, the section that discusses software restriction policy (SRP) is separated from the other security settings in this guidance. Chapter 6, "Software Restriction Policy for Windows XP Clients," provides detailed information about SRP.

Group Policy Security Settings

You will need to create a GPO for each category of Windows XP computer in your environment. Laptops and desktops are divided into separate OUs in this guidance to apply GPOs that are customized for each of these computer categories.

Software Restriction Policy Settings

Create dedicated GPOs to configure SRP settings in your environment. There are compelling reasons to keep the SRP settings separate from the remaining Group Policy settings. One reason is that SRP is conceptually different from other Group Policy settings. Options are not enabled or disabled, and values are not configured. Instead, SRP requires administrators to identify the set of applications that will be supported, what restrictions will be applied, and how exceptions will be handled. Another reason is to facilitate a quick recovery if a catastrophic mistake is made when SRP policies are implemented in the production environment: administrators can temporarily disable GPOs where SRP settings are defined and not affect any other security settings.

Group Policy Tools

Several tools that ship with Windows XP make it easier to work with GPOs. A brief overview of some of these tools is provided in this section. For more information about these tools, see online Help in Windows XP.

Forcing a Group Policy Update

Active Directory updates Group Policy periodically, but you can force the version on your client computers to be updated with Gpupdate, a command-line tool that ships with Windows XP Professional. The tool must be run locally on client computers.

To update a local computer with this tool, execute the following at a command prompt:

gpupdate /force

After you run Gpupdate, the following confirmation information will display:

C:\Documents and Settings\administrator.MSSLAB>gpupdate /force
Refreshing Policy...
User Policy Refresh has completed.
Computer Policy Refresh has completed.
To check for errors in policy processing, review the event log.
C:\Documents and Settings\administrator.MSSLAB>

For user-based Group Policy, you will have to log off and log back on to the computer you are using to test policies. Computer polices should be updated immediately.

To see additional Gpupdate options, execute the following at a command prompt:

gpupdate /?

Viewing the Resultant Set of Policies

Two tools that ship with Windows XP allow you to determine what policies have been applied to computers in your environment, when they were applied, and in what order.

  • RSoP Snap-in. This tool (RSoP.msc) is an MMC snap-in tool that displays the aggregate settings of all policies that have been applied to a computer. The tool may be run locally or remotely from another computer. For each policy setting, the RSoP tool shows the computer setting and the source GPO.
  • Gpresult. A command-line tool that provides statistics on when Group Policy was most recently applied to a computer, what GPOs were applied to the computer, and in what order. The tool also provides information about any GPOs that were applied through filtering. The Gpresult tool can be used remotely or locally on client computers.

Group Policy Management Console

The Group Policy Management Console (GPMC) is an MMC snap-in that is available as an optional component with Windows Server 2003 Service Pack 1. It is used to manage all Group Policy-related tasks. GPMC helps to plan, stage, deploy, report, script, and troubleshoot the application of GPOs. More information see the Enterprise Management with the Group Policy Management Console home page at https://www.microsoft.com/windowsserver2003/gpmc/default.mspx.

Summary

Group Policy is an Active Directory–based feature that allows you to control user and computer environments in Windows Server 2003 and Windows 2000 domains. Before you apply Group Policy to the Windows XP desktops in your environment, you must perform certain preliminary steps in your domain.

Group Policy settings that are stored in Group Policy objects (GPOs) on the domain controllers in your environment are linked to sites, domains, and OUs that reside within the Active Directory structure. It is important to understand Active Directory structure and the security implications of configuring different design options within it before you implement Group Policy.

Group Policy is an essential tool for securing Windows XP. This chapter included details about how you can use it to apply and maintain a consistent security policy across your network from a central location.

The chapter also provided information about the different levels of Group Policy and about special tools that can be used to update the Group Policy in your environment.

More Information

The following links provide additional information about Windows XP Professional security-related topics.

  • For more information about Active Directory management and design, see the white paper "Design Considerations for Delegation of Administration in Active Directory" at https://go.microsoft.com/fwlink/?LinkId=18349.
  • For more information about Active Directory design, see the white paper "Best Practice Active Directory Design for Managing Windows Networks" at https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx.
  • For more information about Group Policy, see the white paper "Step-by-Step Guide to Understanding the Group Policy Feature Set" at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/stepbystep/gpfeat.mspx.Also, see the Windows Server 2003 Group Policy home page at https://www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx
  • For more information about Windows XP Security, see the "Microsoft Windows XP Professional Resource Kit" at https://www.microsoft.com/WindowsXP/pro/techinfo/productdoc/resourcekit.asp.
  • For an overview of the security features for Windows XP, see the white paper "What's New in Security for Windows XP Professional and Windows XP Home Edition" at https://www.microsoft.com/technet/prodtechnol/winxppro/evaluate/xpsec.mspx.
  • For more information about Administrative Templates, see the white paper "Using Administrative Template Files with Registry-Based Group Policy" at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/management/gp/admtgp.mspx.
  • For more information about the Group Policy Management Console (GPMC), see the GPMC site at https://www.microsoft.com/windowsserver2003/gpmc/default.mspx.
  • For more information about the Group Policy Update tool (Gpupdate), see https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/refrgp.mspx.
  • For more information about the Understanding RSoP (RSoP) tool, see https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/rspoverview.mspx.
  • For more information about the Group Policy Results tool (Gpresult), see https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/gpresult.mspx.
  • For more information about how to delegate authority in Active Directory, see the Windows 2000 Resource Kits section on planning "Distributed Security" at https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsca_pt3_stbp.mspx.

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

Download

Get the Windows XP Security Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions