Security is a key concern for network administrators. One of the main ways to secure Windows Server 2003 is through the use of group policies. If you're a former Windows NT administrator, you're probably used to the concept of system policies. In this article, I'll show you how group policies differ from system policies, how they integrate with Active Directory, and other topics to help you begin to develop a group policy implementation plan. I'll also show you how to create and apply them.
Group policies versus Windows NT system policies
Before I get too much further into what group policies are and what they can do, let's take a minute to look at what they are not so that you might avoid some potential confusion.
If you're an experienced Windows NT user, you're probably familiar with system policies. Windows NT provides a tool called the system policy editor, or Poledit.exe, that lets you define groups of registry settings to apply certain change control and security restrictions for Windows NT Workstation and Server computers and users (as well as Windows 9x systems).
In a nutshell, Poledit.exe lets you create a policy file that you distribute to clients, either locally or from a server (most commonly through the NETLOGON share), to control the user's working environment. The settings are incorporated into the registry at the logon, defining the working environment and the system restrictions for the computer and the user. User settings in the policy file are applied to the HKEY_CURRENT_USER branch of the registry, and computer settings are applied to the HKEY_LOCAL_MACHINE branch.
Windows NT System Policies also provide for group policies, which also define registry settings that Windows NT incorporates into the HKEY_CURRENT_USER branch of the registry at logon. Windows NT group policies have priority numbers assigned to them, and they apply according to that priority.
By contrast, group policies in Windows Server 2003 provide a much broader scope of control over the user environment and restrictions, and they use a completely different mechanism for application. Rather than come from a policy file, the group policy objects are stored in Active Directory and apply to the user's configuration at the startup, logon, logoff, and shutdown. As you'll see shortly, Windows Server 2003 group policies offer considerably more control over the user and computer environment than Windows NT system policies, and they provide much greater flexibility in terms of application, administration, and security.
Another important difference between Windows NT system policies and Windows Server 2003 group policies is the ability that users have to, in effect, change or bypass system policies, limiting their security and in many ways their effectiveness. Users can open the Registry Editor and change registry settings defined by the system policy, negating the effect of the system policy (or at least the portion of the policy that related to the modified registry setting). Windows NT system policies also can cause problems when a user's group membership changes, because elements of the system policy might conflict with the user's new needs and responsibilities. Overcoming the problem requires directly modifying the user's registry or applying a different system policy through the user's profile, both of which require manual intervention either by the user or by an administrator.
By contrast, Windows Server 2003 group policies can be applied based on site, domain, and OU, and they can be further controlled through security group membership. This means that Windows Server 2003 group policies apply automatically and follow the user automatically. If the user moves to a different security group or other container in the AD, the group policies that apply to that group or container automatically apply to the user at the next logon. Restrictions and other policy settings defined by the user's old group membership are replaced automatically by the new policies.
So, if you're an experienced Windows NT user who is comfortable with Windows NT system policies, don't throw out everything you know about them. Just keep in mind that Windows Server 2003 group policies are quite different and in almost all respects replace system policies on Windows NT systems. If you're currently using system policies on your Windows NT systems, you can continue to do so. To fully implement the benefits of group policies across the domain, however, you'll need to upgrade Windows NT systems to Windows Server 2003.
Given the exceptional degree of control as well as ease and flexibility for administration that Windows Server 2003 group policies provide, upgrading to Windows Server 2003 becomes much more attractive and cost effective. If you examine the ramifications that poor change control can have on your organization and the costs associated with that, then the cost justification for upgrading all of your Windows NT systems to Windows Server 2003 could be much easier to make to those who hold the purse strings.
Overview of group policies
Perhaps the best way to start to understand group policies is through the tool by which you configure and manage them: the Group Policy Editor (GPE). The Group Policy Editor, shown in Figure A, runs as part of the Microsoft Management Console (MMC).
|The Group Policy Editor runs as part of the Microsoft Management Console.|
To open the GPE as a standalone console, open the file Gpedit.msc, located by default in the %systemroot%\System32 folder. You also can use the GPE as a snap-in with AD-centric consoles such as the Active Directory Users and Computers console or the Active Directory Sites and Services console. This gives you flexibility and access to group policy objects (GPOs) in the context of the task at hand.
To access the group policies through the AD consoles, click the Group Policies tab of a site, domain, or organizational unit (OU). An advantage to working with group policies through the AD consoles is that you can see the hierarchy of GPOs in the Group Policy page, as Figure B shows.
|The Group Policy page shows the hierarchy of GPOs.|
You use the GPE to create GPOs. You can think of the GPOs as the security documents you create through the console. GPOs are associated with three types of AD containers: sites, domains, and OUs. When a security principal is a member of a particular container, the GPOs associated with that container apply to that principal. For example, assume that the domain techrepublic.com contains an OU named Support and that there are two GPOs associated with that container. Groups, users, and computers that are stored in the Support container come under the influence of the policies defined by those two GPOs.
You'll learn how to use the GPE to create and modify GPOs and associate them with containers in the AD in a later installment of this series. First, however, you need to understand GPO hierarchy and inheritance.
Understanding group policy hierarchy and inheritance
Any GPO can be linked to multiple sites, domains, or OUs (multiple containers), and a given container can have multiple GPOs linked to it. When multiple GPOs link to the same container, the GPOs are, in effect, merged, although you can set the order of precedence to define how the GPOs are applied, creating a policy hierarchy. If policies conflict, the hierarchy resolves the conflict, with the policy higher in the hierarchy taking precedence.
GPOs linked to a site apply to all users and computers in the site. GPOs linked to a domain apply to all users and computers in the domain. They also apply by inheritance to all users and computers contained in child OUs of the domain. Inheritance does not, however, flow across to other domains even where trust relationships exist. As with a domain, GPOs linked to an OU apply to all users and computers in the OU and by inheritance to all child OUs of that OU.
Windows Server 2003 applies group policy in a specific order to support the group policy hierarchy. Policies are cumulative, and the last instance of a particular policy applied overwrites any previous instances of that policy. Windows Server 2003 applies GPOs in the following order:
- Local group policy
- GPOs linked to sites
- GPOs linked to domains
- GPOs linked to OUs, with parent OUs processed first followed by child OUs
If you consider the order in which Windows Server 2003 applies group policies, you'll begin to understand the group policy hierarchy. The local group policy resides at the bottom of the hierarchy and has the least significance, since policies assigned after it through the upper levels of the hierarchy take precedence. At the next level is the site, then the domain, then the OU.
By allowing policies in higher levels to overwrite policies in lower levels, Windows Server 2003 provides for inheritance of policies from higher layers. For example, assume you belong to the OU Callcenter, which is a child OU of Support. Some policies would be applied directly by the GPOs associated with the Callcenter OU, while others would be inherited from the Support OU. Inheritance gives you a means of distributing policies across a wide range without having to micromanage them.
Group policies provide two options to control the way policies are applied and refine inheritance. The No Override option for a policy prevents lower levels of the hierarchy from overriding the policy and applying their own. For example, assume you want to enforce a particular policy across the domain regardless of what administrators of various OUs have defined for the policy. You specify the No Override option for the policy at the domain-level GPO, which then prevents any down-level containers from overriding the policy.
The Block Policy Inheritance option is the second option Windows Server 2003 provides for controlling inheritance. This option prevents policies defined at higher levels of the hierarchy from overriding those assigned to the immediate container. For example, enabling Block Policy Inheritance for the Callcenter child OU would prevent policies defined at the parent Support OU from being applied. Nevertheless, the No Override option always takes precedence over the Block Policy Inheritance option. So, Block Policy Inheritance blocks inheritance of only those policies defined by GPOs for which the No Override option is not set.
You can set the No Override and Block Policy Inheritance options by opening the Properties page for the object and clicking the Group Policy tab. When you do, you'll see the screen shown previously in Figure B. To set the No Override option, select the policy and click Options. Next, select the No Override check box. To block policy inheritance, simply select the Block Policy Inheritance check box from the main Properties page.
It's important to understand that you assign the No Override and Block Policy Inheritance options at the GPO level, not at the individual policy level. These two options, therefore, apply to all policies defined by a given GPO, not just selected policies. If a setting is not defined by a higher-level GPO, however, the policies in the current container will apply.
When you view your current policies through the Local Security Settings console, you'll see two columns that enumerate the setting: Local Setting and Effective Setting. The Effective Setting column illustrates the effect of policy inheritance, and where the two columns differ, the Effective Setting column identifies the policy assigned by the level in the hierarchy having precedence (taking No Override and Block Policy Inheritance into consideration).
Administration and delegation of group policies
Group policies are so useful and flexible not just because of what they enable you to do, but also because of how they enable you to do it. GPOs allow you to delegate administrative control over group policies at any level that suits your enterprise's needs. For example, you might delegate administrative control of an OU's GPO to a specific user or group within that OU, giving that user or members of that group the ability to make policy changes that affect their level in the domain while restricting them from making changes at higher levels.
Although I haven't even covered GPO creation yet, it's important for you to start thinking about administrative and security issues before you even start managing group policies. It's critical that you put in place the necessary security framework to provide the appropriate level of control over group policies to ensure their effectiveness and prevent them from being compromised. So, we'll look at configuring security for group policy management before we look at actual GPO creation or management.
As I've mentioned, support for administrative delegation is one of the key benefits of group policies. You can delegate the following three tasks independently of one another:
- Manage group policy links at the site, domain, and OU levels
- Create GPOs
- Edit GPOs
For example, you might grant the ability to create GPOs only to specific administrative groups, while others have the ability to edit those GPOs. You might also enable certain security groups to manage GPOs at specific levels, while other groups manage other levels. One group might have the ability to manage all GPOs throughout the site, while other groups have the ability to manage GPOs only at the domain level and at all underlying levels. Still other groups might manage only the GPOs that apply at their particular level in the domain.
How you structure delegation within the enterprise depends in large part on the extent of the enterprise. If yours is a small organization with one domain and only two domain controllers (DCs) and a handful of OUs, you'll probably administer all GPOs yourself. As the enterprise grows to encompass more OUs and more domains, managing GPOs would rapidly become a full-time job. In that scenario, delegation would enable several administrators to control the GPOs that fall under their area of responsibility and knowledge.
Configuring administration for group policies
In order to manage group policies, you must have access to a DC for the Active Directory in which the GPO resides. This means that your account or group membership must give you the right to log on locally to the DC. If your account is a member of the Domain Admins or Administrators group on the DC, you already have this right. While you could add this right to individual users who need to manage group policies, granting rights through individual accounts is poor practice. Instead, create a security group (named LocalLogon or GPOAdmins, for example), grant that group the right to log on locally, then place accounts in the group as needed.
You define the ability of non-administrative accounts and groups to log on locally through the Default Domain Controller GPO, which is linked by default to the Domain Controllers OU in Active Directory. To grant additional groups (such as delegated administrators) the right to log on locally, start the Active Directory Users and Computers console to create the security group to which you want to grant the right for local logon. When the console starts, expand the domain, right-click Domain Controllers, and choose Properties.
In the Domain Controller's property sheet, click the Group Policy tab, select Default Domain Controllers Policy, and click Edit. In the resulting Group Policy console, select the branch Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignment, as shown in Figure C. Double-click Allow log On Locally and use the resulting Security Policy Setting dialog box to add or remove security groups as needed.
|Configure Allow Log On Locally through the Default Domain Policy.|
You also need Read/Write permission in the DC's Sysvol folder to make changes to objects in the AD. If you're configuring group policy delegation, configure permissions for the Sysvol folder to allow the delegated administrators Read/Write access to the folder.
In addition, you need appropriate administrative permission to the site, domain, or OU in which the GPO resides. To delegate administration, open the Active Directory Users and Computers console and locate the AD object to delegate (such as OU). Right-click the object, and choose Delegate Control. In the Delegation Of Control Wizard, click Next.
When prompted by the wizard, click Add to select the users or groups who will have delegated authority, then click Next. Keep in mind that the users or groups you select must have the appropriate rights already discussed to be able to manage GPOs in the selected container.
From the Tasks To Delegate list, select the tasks for which the specified user or group will have delegated authority. For example, select Manage Group Policy Links to enable the specified user or group to manage links in the selected container. Click Finish to complete the wizard.
To delegate control over group policies, you define rights at the container level to control the use of MMC consoles in general and group policy-related snap-ins in particular. If users can't load the MMC or the group policy-related snap-ins, they can't manage group policies, so your next step is to configure access to the MMC and the snap-ins at the container level.
To do so, open the Active Directory Users and Computers console and locate the container where you want to configure delegation. Right-click the container and choose Properties, then click the Group Policy tab. Select the group policy for the object and click Edit. If a group policy doesn't exist yet, click New to create one. In the Group Policy console, expand the branch User Configuration/Administrative Templates/Windows Components/Microsoft Management Console/Restricted/Permitted Snap-ins/Group Policy, as shown in Figure D. Double-click a policy to enable or disable it.
|Configure MMC and GPO snap-in policies to control delegation.|
Group policies represent a big change in Windows Server 2003. Once you start working with them, you quickly learn how powerful they are and how much you can do with them.