Understanding the Roles of Server 2003 Security Policies

by [Published on 17 Jan. 2006 / Last Updated on 17 Jan. 2006]

Windows domains rely on policy-based security mechanisms, but Windows security policy deployment can be confusing to the uninitiated. What's the difference between the local security policy, domain security policy and domain controller security policies? When and how do you use each? How do you use site GPOs and OU GPOs for best security, and how do they all interact together? What security policy tools are included with the operating system and how is each used? This article will provide an overview of the roles of Server 2003 security policies and how to use them to secure your systems and network.

Policy-based Security: What does it Mean?

A security policy can be defined as a set of rules and practices that govern how an organization manages and protects its assets (which can include facilities, equipment, infrastructure or information). IT security focuses on the protection of:

  • Computer systems/software
  • Network connectivity
  • Sensitive or confidential information

Policy-based security, then, begins by defining the organization’s philosophy and priorities in regard to protection of the above. This is the management definition of “security policy.” Application of the rules and practices outlined in the policy statement is then accomplished via the technical definition of “security policy.”

In this context, a security policy is a template used to select and configure the various security mechanisms supported by the operating system or application. Modern Windows operating systems support many different types of security policies, which are configured through the Group Policy interface.

Security Policy Interfaces and Tools

The operating system tools that are used to configure, manage and apply security policies locally or across a Windows domain include:

  • Local Security Policy MMC: This interface is used to configure security settings that apply only to the local computer. It’s accessed via the Administrative Tools menu in Control Panel. Local settings include: password policy, account lockout policy, audit policy, IPsec policy, user rights assignment, and others. Local Security Policy is not used on domain controllers; they are governed by the Domain Controller Security Policy.
  • Default Domain Security Settings: You use this interface to set security policies for all computers in a domain. These settings override the Local Computer Policy settings for domain members if there is a conflict between the two. This interface is accessed via the Group Policy tab in the Properties of the domain node in Active Directory Users and Computers (Administrative Tools menu).
  • Domain Controller Security Settings: You use this interface to configure security settings for the domain controllers in the domain. These settings take precedence over the Domain Security Policy for DCs. This interface is accessed by logging onto the domain controller as an admin and selecting Domain Controller Security Policy from the Administrative Tools menu.
  • Resultant Set of Policies (RSoP): RSoP is a tool that allows you to query existing and planned policies and get the results of the query so you can see the effects that policy changes would have, before actually applying them.

Note:
The Group Policy Management Console (GPMC) consolidates Group Policy management tasks that previously had to be accessed from several different interfaces. The GPMC can be downloaded from the Microsoft Web site at http://www.microsoft.com/downloads/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en.

Server 2003 Security Policies

Security policies that can be configured through the Server 2003 GUI and command line tools include:

  • Account policy: allows you to define password requirements (length, complexity, maximum age, history), lockout parameters (number of permitted logon attempts, duration of lockout) and Kerberos key policies (how long the keys are valid).
  • Audit policy: allows you to set up security auditing and define which events will be logged (for example, failed/successful logon attempts, access to specific resources, etc.).
  • Cryptographic policy: allows you to control the algorithms used by TLS/SSL.
  • Domain policy: allows you to add and remove computers and create trusts between domains.
  • Firewall policy: allows you to set standard policies for Windows Firewall for all the computers within a domain or OU.
  • IPsec policy: allows you to configure the use of Internet Protocol Security (IPsec) to encrypt data in transit over the network.
  • EFS policy: allows you to define whether EFS can be used to encrypt files and folders on NTFS partitions.
  • Disk quota policy: allows you to enable/disable and define defaults for disk quotas, and specify what happens when a quota limit is reached.
  • PKI policy: allows you to define support for PKI policies regarding auto-enrollment for digital certificates issued by the Windows Server 2003 certification authority.
  • Smart card usage policy: allows you to require smart cards to be used for Windows logon to provide multi-factor authentication.

Group Policy Objects

Security settings can be applied through Group Policy Objects (GPOs) at various levels of the Active Directory hierarchy. A GPO is essentially a collection of policy settings that affect users and computers, and which is associated with an Active Directory container object (site, domain, OU) or local computer. One GPO can be linked to multiple containers or multiple GPOs can be linked to a single container. Group policies are inherited by child objects and are applied from highest to lowest. Group policies are processed in the following order:

  • Local GPO (applies to the local computer only). This is accessed via the Local Security Policy interface described above.
  • Site GPO (applies to all users and computers in all domains in the site). These are accessed and edited through the Group Policy tab on the Properties sheet of a site, which you access by right clicking the site in the Active Directory Sites and Services administrative tool.
  • Domain GPO (applies to all users and computers in the domain). These are accessed via the Active Directory Users and Computers tool or the Group Policy Management console as described above.
  • OU GPO (applies to all users and computers in the OU, and in any OUs nested within the OU). These are accessed through the Group Policy tab on the Properties sheet of the OU, which you access by right clicking the OU in the Active Directory Users and Computers MMC.

As you can see, Group policy applies to all the users and computers in the container to which the GPO is linked. It does not affect security groups, but you can filter Group Policy according to security groups by setting a group’s permissions on the GPO.

Group Policy information for all but local policies is stored in Group Policy containers and in the Group Policy template. The Group Policy container is an area in the Active Directory. The Group Policy templates are folders located in the \Policies folder within the SysVol folder on the domain controllers. Each template folder contains a file named Gpt.ini in its root, which stores information about the GPO. The domain in which each GPO (except those for local policies) is stored is the storage domain. A GPO can be linked to domains other than the one in which it’s stored.

Note:
Even though Group Policy can be processed across domains, it’s best to avoid cross-domain GPO assignments because it slows down logon and startup when the Group Policy has to be obtained from a different domain.

By default, you can create new GPOs and edit existing GPOs if you’re a member of one of the following groups:

  • Domain administrators
  • Enterprise administrators
  • Group Policy Creator owners

These Group Policies won’t apply to members of these groups unless they have the Apply Group Policy attribute set as a member of some group to which they belong. However, by default, Authenticated Users have Read permissions to GPOs with the Apply Group Policy attribute, and members of the above groups are also members of the Authenticated Users group. If you don’t want the policy to apply to administrators, you can set the Apply Group Policy attribute to Deny for the Domain admins and Enterprise admins groups. This will override the Apply Group Policy – Allow attribute that’s set on the Authenticated Users group for those admins, since a Deny setting in any group to which you belong always takes precedence.

Summary

Windows Server 2003 relies on policy-based security, and policies are implemented via Group Policy. Understanding the relationship of organizational policies to the application of Group Policy, and how policy deployment works at different levels. For more detailed information about configuring security policies in Windows Server 2003, see the following resources:

 

See Also


The Author — Deb Shinder

Deb Shinder avatar

Debra Littlejohn Shinder, MCSE, MVP (Security) is a technology consultant, trainer and writer who has authored a number of books on computer operating systems, networking, and security.