5.2 How Group Policy Works

Unfortunately, Group Policy isn't something you can just jump in and start using. Group Policy is heavily integrated with Active Directory and requires a good bit of planning before it can be used effectively. Most of that planning simply involves understanding how Group Policy works.

Because Group Policy works within Active Directory, you have a lot of flexibility in applying Group Policy settings to your users and computers. Active Directory allows you to create any number of different Group Policy Objects, or GPOs, which are a collection of settings. You can link a GPO to an organizational unit (OU), site, or domain within Active Directory. When a computer starts up or a user logs on to the domain, any GPOs that are linked to the domain, site, or OU the computer or user resides in are automatically applied.

Group Policy applies to both computers and users; however, some settings may apply only to computers or to certain users of a computer. Computer policies are always applied before user policies.

GPOs are applied in a specific order:

Settings from the local policy are applied first, if they've been configured.
If a GPO is linked to the computer's site, it applies next. Because users don't belong to sites, this is applicable only to computers.
If a GPO is linked to the user's (or computer's) domain, it applies next.
Any GPOs linked to the OUs that contain the user's (or computer's) account are applied next, in order. For example, suppose a user account is contained in an OU named Sales, which in turn is contained in an OU named NorthAmerica. Any GPO linked to NorthAmerica will apply first, and any GPO linked to Sales will apply next.

The memory aid for this application is LSDOU?local, site, domain, organizational unit. This is the order in which policies are always applied. As you can see, if a user configures local policy, it is overwritten by any domain-based GPO that configures the same setting. This is one way that Group Policy forces companywide settings to take effect on all computers. It's important to note that GPOs don't "merge" in some way. For example, if you link a GPO to a domain and a different GPO to a subordinate OU, those two GPOs don't get magically added together by the operating system. Instead, they both apply in order?any settings configured in the domain's GPO will apply, and then any settings configured in the OU's GPO will apply. If the domain's GPO, for example, specifies a companywide standard wallpaper bitmap and the OU's GPO specifies a different bitmap, then the OU's GPO will "win" simply because it applies last. On the other hand, if the OU's GPO didn't contain any settings for the wallpaper bitmap, the domain's setting would take effect, because it applied first, and nothing in the OU's GPO contradicted it.

Security Showdown: Group Policy Philosophy

Safety in numbers or all your eggs in one basket? Windows Server 2003 allows you to manage GPOs any way you like, whether you prefer to create many smaller GPOs, each implementing a small number of policies, or create a few giant GPOs that include all your settings. Which is better?

Mike: My philosophy on Group Policy is simple: the fewer the better. The primary benefit for this is simplicity. As we know, complexity is the enemy of security. Having numerous tiny policies scattered through your sites, domains, and organizational units is as complex as you can make it. It's an open invitation to unintended policy application?whether it's too much or too little policy applying. Then the nightmare of unwinding which policy applied to which computer and why begins to unfold.

Creating one policy for domain controllers, one at the top level of the domain, and perhaps the occasional one at OU level is more than sufficient. You can immediately identify where a policy is coming from, as policy is applied in a very specific location. This policy can be as detailed as you like, containing numerous settings. It also speeds up client logon, as one larger policy is far easier to apply than hundreds of small ones.

The single-GPO method also has a benefit specific to security. Having one policy ensures that all computers receive the same set of policies. This is extremely important when you have documented security policies that are mandated across the organization. With one well-configured policy, you can ensure complete compliance with these policies. If you have numerous little policies, you might never know that at some obscure OU buried in your tree, there's a policy that was misconfigured and blocks a required policy setting. Or you might not know about it until it's too late.

If you can apply the intended settings with one or two GPOs in an organization, do it.

Don: Perhaps, Mike, but I prefer many, smaller GPOs to the big monolithic ones you're prescribing. True, it takes more time and effort to manage many GPOs, but I find that they can be used more effectively. For example, a single GPO that implements a root certification authority trust can be widely applied across multiple domains if it doesn't contain a billion other settings that might not be so globally applicable.

Smaller GPOs also make it easier to apply GPOs in just the right place for the perfect effect. Larger GPOs tend to get deployed at the domain and site levels, ignoring the flexibility of deploying more customized settings to specific OUs when the situation calls for it. Larger GPOs also make it harder to use the Block Policy Inheritance and No Override features to control GPO application. Granted, those features can make it tough to figure out what policies a user will actually receive, but Windows Server 2003's new RSoP feature in Active Directory Users and Computers provides an easy way to get a resultant set of policies.

For flexibility, precision application of settings, and more fine-tuned control, many, smaller GPOs are the way to go.

Mike: I'll buy that, but for pure ease of management and troubleshooting, I'll continue to advocate fewer, larger GPOs. Of course, in the real world, the right answer is somewhere in the middle, right? As few GPOs as you can have but as many as you need.

Because you can have multiple layers of GPOs, you need to be especially careful about where you place them. For example, you might use domain-level GPOs to enforce broad corporate security guidelines, while using more specific, OU-level GPOs to enforce security settings that are specific to a particular department or office. Site-level GPOs can be used to apply settings that are specific to a particular office or other geographic location. For example, you might use a domainwide GPO to specify a standardized wallpaper bitmap and then use a site-specific GPO to configure foreign-language versions of the bitmap for your company's international offices.

GPO configuration can become quite complex. Administrators can configure OUs to block any higher-level GPOs and also configure specific GPOs so that they cannot be blocked by an OU's configuration. While complex GPO configuration is beyond the scope of this book, you should definitely become familiar with the capabilities of Group Policy before you begin using them in your production domain. Try to avoid using the blocking and overriding capabilities of GPOs until you're completely at ease with how they work and how they will complicate your domain's GPO management. For more information on GPO blocking and overriding, see http://www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/entserver/Block.asp.

How Does Group Policy Actually Configure a Computer?

Modern Windows operating systems?Windows 2000, Windows XP, and Windows Server 2003?obtain most of their configuration settings from the registry. Group Policy works by modifying the registry on a computer, thereby modifying the computer's behavior.

The registry contains two main hives that are affected by Group Policy. The first hive, HKEY_LOCAL_MACHINE, contains settings that apply to a computer and all the users of that computer. The other main hive, HKEY_CURRENT_USER, contains settings that are specific to the user that is currently logged on to the computer. Group Policy also contains a computer configuration section and a user configuration section, which correspond to the two registry hives. Group policy settings in the user configurations section, for example, are applied to HKEY_CURRENT_USER when the user logs on to the domain.

Group Policy works with only Windows operating systems that include native Active Directory support: Windows 2000 Professional, the Windows 2000 Server family, Windows XP Professional, and the Windows Server 2003 family.