Santa Gates has a special toy from the land of Windows 2000. Question is, how does it work?

The Gift of Group Policy

Santa Gates has a special toy from the land of Windows 2000. Question is, how does it work?

• By Roberta Bragg
• December 01, 2000

“And what do you want for Christmas, little girl?” Santa asked as I sat on his knee, picking fake white hair out of my teeth.

Grinning up at him I said, “I want to be able to sit at one console, issue commands, then put my feet up and let the server push these policies out across the enterprise. I want to be able to granularize that control so different groups of computers and users can receive special instructions, and, when necessary, I can delegate some of my duties to my minions. And Santa? Could you rub my neck?”

“Here,” he said. “Have a candy cane.”

Father Christmas didn’t come through for me last year, but Santa Bill did. Windows 2000 has a few new tricks, and one of them provides me with much of what I wanted. With Windows 2000 Group Policy you, too, can spin your web of control around your little universe and beyond. But, like many gifts, you may not know just what to do with it when you first take off the wrapping. Not to worry—there are lots of little helpers in the form of wizards, help files, and 500-plus pages of documentation in the Windows 2000 Server Resource Kit.

Don’t get put off by the large amount of information available on Group Policy. While properly planning and implementing Group Policy will require a lot of work, the payoff is tremendous. So what, exactly, is Group Policy, what is it good for, and why am I so excited?

Group Policy Basics

The concept is simple:

• Determine what’s different about computers and users.

• Place like users and computers into groups.

• These groups become the Organizational Units in your Win2K empire.

• Write a policy stating how each group should be managed and secured.

• Implement the policy using the tools provided.

• Let the operating system enforce this policy across the enterprise.

The concept is clear—even the physical implementation process is simple—but truly understanding how it works and designing the correct solution for your Win2K network can be difficult. To do so, you’ll need to understand not only how to use the tool and what you want to happen where, but also how the process happens. Let’s start with some definitions.

Group Policy Object—A GPO is policy definition. You can open a GPO in a Microsoft Management Console and define or modify specific settings.

Group Policy Container—A GPC is an object in the Active Directory to which a GPO can be linked. Current GPCs are sites, domains and OUs. Nothing else can have a GPO linked to it.

Group Policy Editor—The GUI interface used to view and edit a GPO. The general belief is that Group Policy only affects users with domain accounts and Win2K computers that are in the domain. Strictly speaking, this is true. Group Policy can’t be used to manage Windows NT or Windows 9x computers—nor can it be used to manage users with accounts in a Windows NT domain. However, even Win2K computers that aren’t in a domain (standalone systems) do have a Local Security Policy object applied to them.

Group Policy and Security Groups

Granted, they’re confusing, but I don’t think either name is going to change, so let’s get this straight right now: Group Policy can’t be linked to Security Groups. Group Policy is linked to GPCs. GPCs contain collections of users and computers, printers, shares, security groups, and the like. If a GPO is linked to a GPC, it’ll be applied to the users and computers that are part of that GPC. Since security groups can contain users from multiple GPCs (a domain-level security group, for example, might have users from many different OUs), the GPOs impact is restricted to the user and computer accounts within the GPC.

In Figure 1, the triangle represents the ACME domain. The domain has two non-default security groups, Clerks and Managers. Both are part of the Westport OU. John’s account is in the Westport OU, and he’s a member of the Clerks group. Peter’s account is in the Westport OU, and he’s a member of the Managers group. Alice’s account is at the domain level, and she’s a member of the Managers group. The GPO linked to the Westport OU includes the restriction that all users’ desktop screens must display the “Gold Petal” wallpaper. When Peter and John log on, their desktops show this wallpaper. When Alice logs on, her desktop doesn’t.

Figure 1. Application of Group Policy depends on the location of the user account, not the security group.

Even though Alice and Peter are members of the same security group, and that security group is in the Westport OU, the application of the policy depends on the location of the user account, not the security group. By default, when linked to a GPC, the GPO applies to all users and computers in the GPC, regardless of their membership in a security group. You can, however, filter the application of a GPO policy.

So What Can You Do with Group Policy?

Group Policy affects many features of Win2K. Using Group Policy, you can perform the following functions:

• Manage software installation

• Implement logon and logoff scripts

• Administer computers and users with extensive lists of features (similar to Systems Policy in NT and Windows 9x)

• Implement and manage security policy for the enterprise

While I can’t cover any of these in extreme detail, you can get a good idea of the range and scope of coverage by opening up the default Domain Policy. To examine this GPO:

1. Open the Active Directory Users and Computers console from Start | Programs | Administrative Tools.

2. Right-click on the domain object (the topmost object in the hierarchical display).

3. Select the Group Policy tab.

4. Click the Edit button.

5. Scroll, click and expand each item.

6. Double-click on items to see the possibilities each has for configuration.

7. Note defaults.

8. Note that on Administrative templates, an Explain tab is available. Click on this tab to read what the item will do. This valuable feature can help you understand what making a change will do so that you won’t have to guess from the possibly misleading title of the policy.

To further understand Group Policy policies, use the Server Resource Kit tool, gp.chm. This file is a collection of html pages that explain all of the policies.

Scope

So you’ve been looking at the GPO for the domain and are assuming that changes made here will roll out to every user and computer in the domain. You’re correct—to a point. Group Policy application depends on several things, including definitions on the local, site, domain and OU levels; user and computer definition location; GPO permissions (see “Filtering Group Policy”); and the No Override and Block Inheritance options.

As you know, GPOs can be linked at the site, domain and OU levels. In addition, a local Security Policy exists on every Win2K computer whether or not it’s in a domain. This policy is the security policy on the standalone computer. When a computer joins a domain, this policy is limited by the application of policy elsewhere.

The location of a GPO limits its direct application to computers and users within its GPC. However, if a GPC is nested within another GPC, then the settings of the external GPC will be applied to the users and computers within the nested GPC. GPOs linked to these child GPCs will also be applied to computers and users contained within them. So a policy applied at the domain level can affect all computers and users in the domain, but a policy at the OU level only affects the computers and users in that OU.

In our example, users and computers in the Westport OU are affected by their local computer security policy, the domain policy, and the GPO linked to the Westport OU. The order of all policy application and the resolution of conflicts are carefully orchestrated by the rules of policy inheritance, which I’ll explain shortly.

And What Can Group Policy Do to You?

Is all of this sounding too complex to figure out and apply? How many of you didn’t use Systems Policy in NT for this very reason? Are you thinking that you’ll just manage your systems using the other built-in tools? Are you postulating that Group Policy is for large enterprise operations? Think again.

If you don’t understand and use Group Policy, it’ll use you. There are default policies in place, and the hierarchical application of Group Policy will occur whether or not you elect to understand it. Sometimes, editing a GPO is the only way to change how things work. Where do you modify user rights in the domain? How about setting event log policy, Kerberos, or IPSec policy? How can you enable Audit? That’s right, you make changes in Group Policy.

It’s also important to understand that some policy changes should only be made at a particular place.

• Password settings and other Account Policies can only be set in the domain GPO. Settings made elsewhere won’t have an impact on domain users.

• Audit Policy for most computers in the domain can be set in the domain GPO; but to enable auditing for Domain Controllers, you must do so in the Domain Controllers’ GPO.

• Changing the name of the Administrator account must be done in the Domain Computers’ GPO.

Got that down? OK, make some changes to Group Policy and then visit other computers in the domain. What? The changes aren’t being displayed there? Even though Group Policy can be used to control all of the computers in the domain, changes won’t occur immediately. Changes are applied according to default rules that can be modified by—you guessed it—setting Group Policy. By default, computer policy is refreshed at boot, and user policy at logon. Both computer and user policies are refreshed periodically throughout the day—every five minutes for domain controllers and every 90 minutes for all other systems. The normal process of Active Directory replication will also affect the application of Group Policy.

Breathing easier? Wait. Since Group Policy can be linked to GPCs, the impact of these multiple policies on the user’s computer and his or her account will depend on where in the Active Directory hierarchy the policy is linked. Group Policies are inherited from GPOs higher in the AD, and the impact is cumulative. But what happens when there’s a conflict?

Understanding Group Policy Inheritance

To get a grip on inheritance, you must first back up and make sure you’re clear on the hierarchical structure of AD GPCs, AD replication, and the design of an OU structure.

Active Directory Group Policy Containers
As you know, sites express the physical design of your network and can include multiple domains. A domain can have computers in multiple sites. This is important, because GPOs can be linked at the site level. You need to pay attention here because of the implication of cross-domain application of policy and the problems inherent in applying Group Policy across slow links.

Domains are security boundaries. As such, GPOs linked at the domain GPC affect all computers and users in the domain. Also, there are some parts of Group Policy that can only be set at the domain level. Thus, Account Policies such as password and Kerberos policies can only be set in GPOs linked to the domain GPC. Account Policies set anywhere else—say, at the OU level—will only affect local databases.

OUs are contained within the domain and can contain other OUs. In fact, an entire OU hierarchy can be constructed to deal with complex administrative requirements.

AD Replication Impact on Group Policy Application
Every Active Directory architect must take into account the impact of AD replication on the environment. AD replication is the reason why changes made someplace in the AD are appropriately changed elsewhere.

One of the largest concerns is the frequency of replication and the delay inherent in even the smallest structure. Information on the additions of users or changes to their passwords, for example, isn’t immediately available on all domain controllers in the domain. It takes time for that information to be replicated. A good design can help rectify this problem, but there will still be delays.

The application of changes to Group Policy, likewise, is hit by AD replication. Part of the process includes the delay in making the change and the distribution of the information to the appropriate location so that it can be replicated and applied. Another part has to do with when Group Policy is applied. So even in a single-domain, single-domain-controller environment, a change to group policy won’t be immediately applied to a computer in the domain.

In a larger environment, delays can be much longer. How long will depend on the size of the enterprise, the effectiveness of the AD design (including OU nesting levels), and the application of Group Policy settings.

OU Hierarchy Design
Computer and user accounts will be affected by all GPOs linked to the GPC they’re members of, as well as the GPOs linked to any of their GPCs’ parents. In a simple AD structure—one with a single OU level—a user or computer that’s a member of an OU may be affected by five GPOs:

• The local security policy on the Win2K computer

• The site GPO

• The domain GPO

• The domain controller GPO

• The OU GPO

In a more complex AD design the user has the potential of being affected by these GPOs as well as those linked to any OU under which the OU is nested. The OU structure can slow performance and delay applications in three ways:

• A deeply nested OU structure and/or multiple GPOs at each level can severely increase the time it takes to log on.

• A deeply nested OU structure and/or multiple GPOs at each level can stretch out the time it takes a system to boot.

• Since Group Policy is periodically applied throughout the day, the intricacy of the structure and normal replication delays can increase the time it takes before the change actually takes effect.

Group Policy Inheritance

Here’s the scoop on the inheritance process. When a computer boots and a user logs on, Group Policy is applied in the following order:

1. Local policy

2. Site policy

3. Domain policy

4. Top level OU (at the top of the hierarchy) policy

5. The next OU in the hierarchy policy

6. Subsequent OUs in the hierarchy policy

For purposes of discussion, I’ll speak of the policies above others in this list as the distant policies and those underneath them as closer-level policies. The following rules, deviations, and exceptions apply:

• If multiple GPOs are linked to the same GPC, the policies are applied in the reverse order of their listing. Thus, in Figure 2, first the Green Policy will be applied and then the Red Policy. Any conflicts between the policies will be resolved in favor of the Red Policy.

Figure 2. If multiple GPOs are linked to the same GPC, the policies are applied in the reverse order of their listing.

• If a policy isn’t defined at a closer level, any definition at a distant level will still be in effect. So if a policy to set DACLs on a folder is defined in the local policy but not defined in the OU GPO, the DACLs will be set.

• If a policy is defined, enabled, or otherwise, at a distant level and also defined at closer level, the closest level policy will win in the case of conflict.

• Default GPOs exist. You should examine them for default policies that will affect your GPO design.

• There are defined locations for the settings of some policies. Policies set anywhere else will have no impact. An example of this is password policy, which is set at the domain level.

• A GPO can be designated NO OVERRIDE. If it is, no other policy will override its settings.

• A domain or OU can be designated Block Inheritance. If it is, it won’t inherit the GPO settings of other GPCs.

• A GPO designated NO OVERRIDE will not be blocked by Block Inheritance.

An example of Group Policy Inheritance is displayed in Figure 3.

Figure 3. Group Policy inheritance defines the process of application within an OU.

In this figure, there are GPOs at each level in the hierarchy. Only one item in each GPO is identified for simplicity’s sake. Please note, I’m just giving you an example of how policy would be applied. The following list describes the process that occurs in the application of Group Policy to the users and computers within the PURPLE OU.

1. The local policy is applied. If the computer is a server, the default is set to not allow all users to log on locally. If the computer is Professional, the group Everyone has the right to log on locally.

2. The domain policy is applied. The right to log on locally isn’t defined. The group Everyone still has the right to log on locally to Professional systems, but not to servers.

3. The policy of the RED GPO is applied. The right to log on locally isn’t defined. The logon message (banner) is defined. The group Everyone will have the right to log on locally on Professional, but not on servers. All users logging on will be presented with the logon banner.

4. The policy of the PURPLE GPO is applied. This policy gives the group Everyone the right to log on locally. No matter what the computer is, Server or Professional, all users can log on locally. All users will be presented with the logon banner.

Would users logging on to computers in the BLUE OU or the RED OU be able to do so? (Only if the computer was a Professional or the server had a modified local security policy.)

Policy Filtration Now that you know that GPOs are applied to computers and user members of a GPC, you might be wondering if this default activity can be changed. Of course it can! To understand how, open the property pages for the GPO and select the Security tab. You’ll see the familiar structure for assigning DACLs on an object. The permissions are different, but the process is the same. To limit the application of a GPO within a GPC, you simply allow or deny the Apply Policy and Read Policy permissions to the specific security groups you desire. Note that when you first open the security pages, the Authenticated Users group is given these permissions. This means the policy is applied by default to any users within the GPC who have been authenticated. (Policy for users is first applied at logon.) To restrict or filter this application, you need to adjust the permissions for the desired security groups. Do you remember Alice and Peter from the example? Alice didn’t get the “Gold Petals” wallpaper because her account wasn’t in the Westport OU, but Peter did because he was. If management decides that members of the Managers group should have the ability to choose their own wallpaper, you can do this via the filtering process. Add the Managers group to the security pages and give them the Deny Apply Policy Permission. The following figure shows this. To limit the application of a GPO, simply allow or deny policy permissions to specific security groups. Now when Peter logs on, his screen won’t display the “Gold Petals” wallpaper. You can also filter the application of Group Policy to specific computers within the GPC by creating or using default computer groups and filtering the application of policy. By default, the GPO is applied to all computers whose accounts are in the linked GPC. —Roberta Bragg

Zeroing in on Security

So what’s got me breathing heavily and my fingers all twitchy on the keyboard? It’s the implication of that fourth bullet in the “What can you do…” heading above (Implement and manage security policy for the enterprise). Like every cool tool, it’s not the size that counts, but what you can do with it.

As I cross the world preaching security, I’m often subject to sighs of indifference that later change to groans when my audience decides it wants to implement security in a Windows network, but realizes the tedium of doing so. Group Policy gives us a tool that can be used effectively to implement, maintain, and audit security policy in the enterprise.

I’ve introduced the basics to you. Next, you must design your policy with the possibilities and implications firmly in mind and the goals and structure of your organization always guiding your steps. In fact, the design of your security policy and its implementation through Group Policy should be part of the design, deployment and on-going maintenance of your Win2K network.

If you’ve already implemented Group Policy in your enterprise and would be willing to allow me to use your design as a case study in a project I’m working on, let me know.