Designing Security Settings

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

This section discusses the recommendations and considerations for using security templates and implementing security settings. Before implementation make sure to consider the following design elements. For more information about importing security templates for domain controllers, servers, or workstations, see "Importing Security Templates and Modifying Security Settings in a GPO" later in this chapter.

Use the NTFS file system

You cannot secure Windows-based computers that are installed on file allocation table (FAT) file systems. All the security design and deployment recommendations in this chapter assume that you use the NTFS file system on all computers that you need to secure.

Complete all policy settings before applying them

Make sure that all the settings of your policy are in place before you apply the policy to any GPOs. If you apply the policy in parts, and a user refreshes the policy before all the parts are in effect, this can adversely affect the user’s computer when configuring software restriction policies.

Avoid editing the Default Domain GPO and the Default Domain Controllers GPO

The Default Domain GPO and Default Domain Controllers GPO are vital to the health of any domain. The Default Domain GPO provides the basic domain encryption key, and if that policy is removed or deleted, users cannot unencrypt their files. There are two exceptions:

  • Editing the Default Domain GPO to define account policies, including password policies, account lockout policies, and Kerberos policies.

  • Editing the Default Domain Controllers GPO to define user rights assignment and audit policy for the domain controllers OU.

Set domain account policy in the Default Domain GPO

When you set account policies (including password policies, account lockout policies, and Kerberos policies) in Active Directory, there can only be one domain account policy throughout all servers, workstations, and domain controllers in the domain. The policy is the account policy that is applied at the root domain of a domain tree. Although account policies affect user accounts, the policies are defined on computers.

Avoid linking to a GPO in another domain because this can degrade performance.

Consider precedence of policy application when multiple GPOs are applied

Because a computer can have more than one GPO applied to it, security settings can conflict. From highest to lowest, the settings apply in the following order of precedence: OU, domain, site, and local computer. For example, policies that are defined in Active Directory at the OU, domain, or site level always override the local security policy for a computer if there is a conflict. If the same computer is a member of an OU, the organizational unit policy overrides all other settings. If the computer is a member of nested OUs, the OU that immediately contains the computer takes precedence.

For nested OUs, the GPO that is linked closest to the OU takes precedence. The precedence rules that apply to restricted groups also apply to other Group Policy settings when there is a conflict. For example, if a computer is a member of OU A, which is nested in OU B, and both OUs define Power Users as a restricted group, then the definition of Power Users according to OU A takes precedence on the computer.

To find out which policies are currently applied to a specific computer, use the Group Policy Results node in the GPMC snap-in.

Plan Event log size and wrapping according to business and security requirements

Define Event log size and overwrite of events logs (also known as log wrapping) to match the business and security requirements of your organization’s security plan. Implement these Event log settings at the site, domain, or OU level to take advantage of Group Policy settings.

Understand the use of Restricted Groups

If you create a Restricted Groups policy for a group, any users and groups that are not specified as members of the group within the policy are removed from the group. For example, if you create a Restricted Groups policy for the local Administrators group, and the newly created policy specifies only the Domain Admins group as members, all other members of the local Administrators group (including any local accounts) are removed from the local Administrators group when the policy is applied. Note that if the Restricted Groups members are defined in more than one GPO, only the members that are defined in the GPO with the highest precedence are applied. This also applies to the groups that the group can be a member of.

Be aware that security settings can persist

For Windows Server 2003 and Windows XP, security settings might persist even if the setting is no longer defined in the GPO that originally applied it. This occurs under the following conditions:

  • The setting was not defined for the local computer at the time that the policy setting was applied.

  • The setting is for a registry object.

  • The setting is for a file system object.

Windows 2000 security settings may persist even if the setting is no longer defined in the GPO that originally applied it. This occurs under the following conditions:

  • The setting has not been defined for the local computer at the time that the policy setting was applied.

  • The setting is for a registry object.

  • The setting is for a file system object.

  • The setting is for a service.

  • The setting is for a Restricted Groups policy.

  • The setting is an Event log setting.

All settings that are applied through local policy or a GPO are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database. The database retains a history of all the settings that have been applied to the computer. If a policy defines a security setting and then no longer defines that setting, the setting reverts to the previous value in the database. If a previous value does not exist in the database, the setting remains defined as is. This behavior is sometimes called tattooing.

Any other settings that persist maintain the values that are applied through the policy until that setting is set to a different value.