How To: Setting Up Active Directory Group Policies

Uh-oh: that fancy new reporting application you're planning to deploy requires opening a port in Windows XP Firewall. Now what? You could write a script or purchase a desktop-management suite to assist you, but if your organization has Microsoft's Active Directory, you've got everything you need to open that firewall port. AD's Group Policy feature lets you control the myriad settings for your users, desktops and servers.

With Group Policy, you can manage your network from on high, governing the specifics of how your users and computers operate within your AD environment. Once you start using it, you'll be amazed at how quickly and easily you can deploy changes to the masses, set up consistent desktop and server configurations, control the end-user experience, lock down workstations and even control the Windows XP firewall. But, as with any powerful tool, you must exercise caution and responsibility to keep end users happy. Test, document and troubleshoot the changes you make to your environment using Group Policy before you employ it.

Group Policy 101

At the foundation of Group Policy are the policy settings--specific attributes that dictate control over the configurable aspects of Windows (such as which ports are open in the XP Firewall). Policy settings are targeted at the logged-in user or the computer. They can be security settings for auditing, logging and logon restrictions; running scripts at start-up, shutdown, logon or logoff; installing software; redirecting user folders; and manipulating the registry over administrative templates.The policy settings framework is extensible using configuration files, also known as ADM templates. If a specific application in your organization has an ADM template, you can, for example, control that application's settings using Group Policy. Unfortunately, there are few third-party ADM templates, though more are being developed.

To apply policy settings to users and computers in your AD environment you must first configure a Group Policy Object (GPO), which resides in a special folder called "Group Policy Objects" within the AD domain. A GPO is a named collection of configured policy settings. As a best practice, only configure those settings necessary to accomplish an administrative task inside a GPO. If as part of your corporate security policy you require Windows Firewall be enabled on each computer, for example, you could create a GPO titled "Default Windows Firewall Settings" and configure the policy settings to match the desired firewall behavior on the target workstations, just like you would in the Windows control panel. Note that if the targeted operating system doesn't understand the setting, it will ignore it.

The policy settings in the GPO don't get enforced until you link the GPO to an Active Directory site, domain or organizational unit (OU). Once the GPO is associated with a site, domain or OU, the policy settings take effect for the users and computers defined within the scope of that container. If we link our firewall GPO at the domain level, for example, the policy settings apply to all XP workstations and 2003 servers in the domain. If we instead link the GPO to the Product Management Group (PMG) OU, the firewall settings only apply to computers inside that OU. GPOs can be linked in multiple places such as two different OUs, and a site, domain or OU can even have multiple GPOs linked to it.The flexibility of linking GPOs teaches us three lessons. First, targeting the GPO at a specific context lets you create smaller, task-specific GPOs. These GPOs can be applied at the appropriate level in the AD. That's in contrast to lumping all policy settings into monolithic GPOs at the site, domain and OU levels. Under this scenario, copies of the same policy settings would exist in more than one place, creating a maintenance nightmare.

Second, linking GPOs is useful for testing your configuration, since you can target the GPOs at a test OU and then verify the settings before re-linking them to the OUs in which the actual users and computers reside. Third, the OU structure in your AD tree layout should be organized in a manner conducive to the application of GPOs--it's difficult to apply firewall settings to only Windows XP workstations, for example, if both servers and workstations exist in the OU to which the GPO is linked.

So in what order is each GPO applied? Group Policy works from the "outside in," first processing any local policies, then applying the site, domain and subsequent OU GPOs and working its way toward the object's resting place in the Active Directory tree. If any policy settings conflict along the way, the last setting applied rules. So, for example, with a computer object in the PMG/Computers OU in Active Directory, the local computer policy is applied first and then from there any site GPOs, any domain GPOs, the GPOs of the PMG OU and finally, any GPOs linked to the PMG/Computers OU. Similarly, policy settings applied to user logons do the same but follow the path to the user object's resting-place in AD. AD overrides policies set on the individual computer.

Tools of the Trade

Your Windows Active Directory environment has everything you need to get started with Group Policy, including the GPO editor for configuring policy settings inside the actual GPOs, as well as the Active Directory Users and Computers tool for linking GPOs at the domain and OU levels. But, as anyone who has tried to loosen a screw with a butter knife knows, there are far more suitable tools for the job.

The Group Policy Management Console SP1 (GPMC SP1,) is a free download from Microsoft that addresses several shortcomings of the Group Policy management interface in Windows. GPMC separates where the GPOs actually live in the domain from the places where they are linked. So, for any given GPO, it's easy to determine where it's being used in AD and what policy settings are configured without having to open the Group Policy object editor. In addition, it lets the system administrator easily view the GPOs linked at the site, domain and OU levels, along with the processing order of the GPOs at these levels. Bottom line: This new user interface offers a clearer relationship between GPOs and the containers (AD site, domain or OU) where they are actually being targeted.

You also can more easily perform backups and restores of GPOs with GPMC, something severely lacking in the native GP management interface in Windows. It's also easy to manage multiple domains from within the GPMC and move GPOs from one domain to another. This feature is also useful if you need to test your GPOs on a separate domain and then migrate them into the production domain once they've been given a clean bill of health.

Despite the major improvements GPMC brings to Group Policy, there are still many complicated and counter-intuitive elements you'll have to contend with. Regardless of whether you click on the GPO link or the GPO itself using GPMC, you're manipulating the same thing--the GPO. There are only three things you can do to a GPO link without affecting the underlying GPO. First, you can toggle the enabled or disabled link, thereby controlling application of the GPO to the target container. Second, you can delete the link, which removes its association with the container. And third, you can enforce the GPO link. By enforcing the link, you're telling AD to process the GPO last. This setting is often used to prevent OU-level administrators from overriding domain level policy settings set by a higher-ranking administrator.

All other settings affect the GPO itself. If you click on the "Default Windows Firewall Settings" GPO in the PMG/Computers OU and subsequently alter its policy settings, for example, you're editing the underlying GPO everywhere this GPO is linked so it will now use the new policy settings.

The bottom line here is there are a lot of policy settings and finding the correct one is like finding a needle in a haystack. The only way you can be confident a policy setting will behave as expected is to test it for yourself. You can obtain documentation on all the policy settings outside of the Group Policy editor here.

Documenting and Troubleshooting

If this seems a tad overwhelming, rest easy. GPMC comes with two tools for testing and troubleshooting Group Policy, Group Policy Results and Group Policy Modeling.Group Policy Results is a logging tool. It shows how the GPOs were applied to a specific user and computer, so you won't have to visit the actual workstation to see how Group Policy is being applied. However, because of the tool's dependence on the Windows Management Instrumentation (WMI) service, you cannot log the Group Policy Results of older Windows 2000 computers or of XP/2003 computers not running WMI.

Group Policy Modeling lets you play out "what if" scenarios, rather than logging what actually happened. This tool can be used to observe what policy settings are applied, for example, when users from your PMG OU log on to a computer in the R&D group OU. To use this feature, the domain schema must be updated to support Windows 2003, and the domain must have at least one Windows 2003 domain controller. This tool also simulates advanced processing options, such as loopback processing, WMI filters on GPOs and slow-link processing. You can save your results from Group Policy Results and Modeling to an HTML report for documentation purposes. And each query is saved so it can be run after any GPOs are updated.

A further nuance complicates Group Policy a bit: GPOs get refreshed on the target computers and users differently in Windows XP, 2000 and 2003. Group Policy is a "pull" technology--clients poll the domain for GPO changes every 90 minutes to 120 minutes by default. There's no command you issue on your Domain to immediately apply GPOs to all targets.

There are tools available in Windows, however, that force a refresh from the client computer. These can be quite useful, especially when you're testing your policy settings. If the target workstation is Windows XP or 2003, the GPUPDATE command can pull down any GPOs that have changed since the last refresh from a command prompt. In Windows 2000, with no GPUPDATE command, you'll have to use the older SECEDIT command.

Sometimes, when dealing with firewalls, Windows 2000 computers or stringent corporate security policies, the only way to troubleshoot policy settings may be to log in as the user on the target computer. With a command prompt running GPRESULT, you can get information on the last time a Group Policy was applied, which GPOs were applied, computer and user account privileges, and group membership information. You also can run the older RSOP.MSC policy tool from the Windows workstation to display the applied computer and user settings from each GPO.Group Policy is a powerful weapon that should be part of every Active Directory administrator's arsenal. Just be careful with how you wield it--what seems like a trivial change to even the most experienced administrator may result in a flood of calls to your helpdesk. You'll need to use the Group Policy Management console tools, test your changes prior to deployment or, more important, adopt a full-fledged change management strategy. You'll be wiser for it in the long run.

Michael Fudge Jr. is a system administrator at Syracuse University's School of Information Studies. Write to him at [email protected].

Alternative Approaches

FullArmor PolicyPortal. If you want Group Policy but don't have an Active Directory setup, there are other options. One is FullArmor's PolicyPortal, a Web-based application that lets you set up GPOs and then target them by computer groups you specify through the Web interface. The computers managed by PolicyPortal must have a lightweight agent installed on them. The agent checks in with the PolicyPortal Web site at routine intervals, downloading and applying new policy settings as required.

Probably the coolest feature of PP is the amount of information it gives you. It's digital dashboard on the summary page graphs which machines are up-to-date with which policies, and displays a histogram of when devices last checked in. It also shows you the number of computers in each group and a log of how the policies were applied.The PP application actually uses the GP object editor to create and edit policies, which means you won't have to learn a new way to create policy settings. Since you're only allowed to assign one policy per computer group, you must combine all policy settings for the target devices into a single GPO. This isn't as big of a troubleshooting issue as it is with Active Directory because just one GPO is applied to any given device. In addition, PP offers version control and history for your GPOs, making it simple to rollback any undesirable changes.

PolicyPortal-AD Combo. If you already have Active Directory, you can use PP with it to enforce policy settings over your mobile users who are seldom in the office. However, you'll probably have to maintain Group Policy settings in two places (Active Directory and PolicyPortal) and organize your Active Directory so your road warriors only receive policy settings from the PolicyPortal. Otherwise, troubleshooting what's happening on the workstation will be difficult.