Server 2003 User Group Policy: Using GPOs and Active Directory Objects in Windows Server 2003

Server 2003 User Group Policy: Using GPOs and Active Directory Objects in Windows Server 2003
Page content

Using Group Policy Objects

Group policy enforcement can be tricky. Administrators are constantly reminded that the simplest solution is the best, yet are beset by unique challenges that require unique and not-so-simple solutions. Having a firm grasp on how Group Policies are linked and applied to the various groups on the network can go a long way in helping new and seasoned Admins tackle these challenges.

Group Policy settings are stored as virtual objects called Group Policy Objects. Multiple objects can be configured, and the Administrator is able to name them in order to keep track of their purpose easier. For example, they may want to create a GPO that contains a few settings that they want applied to the entire domain, as well as other GPOs that enforce specific policies to smaller groups. They could configure it so that the entire network has the Require CTL+ALT+DEL at Login policy enforced, but only the Accounting OU is disallowed use of Windows Messenger. To do that, they would configure two GPOs - one for the domain and one for Accounting.

Multiple GPOs can be linked to a single site, domain, or OU, and a single GPO can be linked to as many of these as you choose. They can not be linked to individual users, computers, or security groups. So, if you want to prevent Jan and Sara from spending most of the work day gossiping back in forth over Windows Messenger instead of getting their work done, you could simply place them in an OU named “Chatterboxes” and link a GPO that disables use of Messenger to it. Piece of cake.

Sites, Domains, and Organizational Units

As we mentioned above, GPOs can be linked only to the Site, Domain, and OU ‘containers’. Sites and Domains are default objects, but specific Organizational Units must be created. Most enterprise Administrators base their OUs on existing department names, ie: Accounting, Helpdesk, HR, Executive, etc. and then create GPOs with set policies that explicitly apply to each group and their various needs. Even if explicit policies do not need to be enforced, many will create the OUs to simplify any future changes and maintain a logical organizational structure.

When you link multiple GPOs to a single object, like the Domain, policies are enforced in an order that you specify. This order is called “Link Order”, and the lowest link order is processed last, and therefore has the highest precedence. It may take some time to get used to the counter-intuitive idea that the lowest is the most important, but you’ll get there eventually. Defined policies with higher precedence will overwrite ones with lower precedence if there is any conflict. However, undefined policies are not considered. If the GPO with the lowest precedence enforces the Account Lockout Policy, and all of the higher precedence GPOs leave it Undefined, then the policy will be enforced. If, however, one of the higher precedence GPOs specifically defines not to enforce the Account Lockout Policy, then the policy will not be enforced.

Lastly, Group Policy is processed in a specific order across the entire network. That order is as follows:

1. Local GPO - A GPO on a single computer is processed first (and therefore has lowest priority).

2. Site - Any GPOs linked to a site are processed next.

3. Domain - GPOs linked to individual domains are processed third.

4. OU - GPOs linked to OUs are processed last, and therefore have the highest priority. This allows for maximum flexibility in enforcing various GPOs on individuals or departments.

You can view the effective policies on any Site, Domain, or OU by selecting its Group Policy Inheritance tab.