There is nothing particularly difficult about Group Policy deployment in order to harden your server, but the deployment...
process is something of an art form.
Group Policies are arranged in a hierarchical manner that allows you to use a collection of many different Group Policies to form a resultant set of policies. The real trick to deploying Group Policies is to figure out which Group Policy settings need to apply to which users (or computers) and then arrange the Group Policies in a way that will allow that to happen.
Unfortunately, you cannot deploy Group Policies directly to users, groups or individual computers. Instead, you apply them to one of the four levels of the Active Directory: a local computer, an Active Directory site, a domain or an organizational unit. What this means is if you have different users with different security needs, you will have to arrange those users in the Active Directory so you can apply the correct Group Policy settings to them.
Where to start
The most common way of accomplishing this task is to organize users and/or computers into organizational units and then create a Group Policy Object at the organizational unit level of the Active Directory that will apply to objects within that organizational unit. Of course, Group Policies can contain very large numbers of security settings, and it would be a lot of work to define every possible setting every time you need to create a new organizational unit.
Fortunately, you don't have to. Instead, administrators will commonly create domain-level Group Policies that contain security settings that should apply to all of the objects in the domain. Only settings that are unique to a particular organizational unit are included in the organizational unit's Group Policy. When a user logs on, the resultant policy is compiled by combining the domain and the organizational unit policies (along with any other applicable policies that might exist).
It's possible for contradictions to occur between Group Policies. For example, a domain-level policy might disable the Windows AutoPlay feature, while an organizational unit-level policy might set a particular default behavior for AutoPlay. When a contradiction occurs between policies that apply to a user or to a computer, Windows usually resolves the contradiction by allowing the higher-level policy setting to take precedence. For example, in the situation that I just described, the organizational unit-level policy would take precedence over the domain-level policy if any contradictions should exist. Keep in mind, though, that settings from policies with a lower precedence are only overwritten if a higher-level policy has a contradictory value.
If the higher-level policy does not address a particular setting contained in a lower-level policy setting, then that setting will still apply. For example, if a domain-level policy setting set disabled AutoPlay, and an organizational unit-level policy did not address AutoPlay at all, then when the policies are combined, AutoPlay would remain disabled because there is nothing in the organizational unit-level policy that causes the setting to be overwritten. In case you are wondering, Group Policies are applied in the following order: local computer (the local computer policy resides on the workstation and is not a part of the Active Directory), site, domain and organizational unit.
Be on the lookout
Hopefully, the idea that Group Policies are applied in a particular order and that the most recently applied setting takes precedence is clear to you. Unfortunately, things are not always that simple. There are two settings that can be applied to Group Policies that can completely throw the hierarchy out of whack; these are the no override and the block Inheritance attributes.
Microsoft created these attributes as a way of preventing blanket policy settings from applying to Group Policies over which you want to maintain tight control. The basic idea behind the no-override attribute is that it prevents a higher-level policy from overwriting a Group Policy setting.
The block inheritance attribute works a bit differently. Earlier, I showed you how a Group Policy setting from a lower-level policy could remain in effect if a higher-level policy does not specifically address the setting. When this happens, it is called inheritance. The block inheritance attribute prevents policy settings from being inherited from lower-level policies.
One last thing you need to know about the way Group Policies are applied is that you can also use access control lists (ACLs) to control which users or groups a policy applies to. For example, if you were to open the Active Directory Users and Computers console and right click on the domain and select the Properties command from the resulting shortcut menu, you would see the domain's properties sheet. One of the tabs on this properties sheet is the Group Policy tab. It lists all of the Group Policy Objects that are linked to the domain. If you right click on a Group Policy Object and select the Properties command from the shortcut menu, you will see the Group Policy Object's properties sheet. One of the tabs on this properties sheet is the Security tab. You can use the Security tab to edit the policy's access control list.
Normally, everybody needs at least read access to the policy (administrators need full access so they can edit the policy). However, if there is a particular group of users to which you do not want the policy to apply, then you can just deny those users read access to the policy. Of course, a better practice is to just place those users into a different organizational container so the policy would not apply; but you may occasionally find that you have no choice but to use ACLs to control policy enforcement.
As you can see, the hierarchical nature of Group Policies can make them difficult to manage. If possible, though, avoid using the block inheritance and no override attributes as well as Group Policy ACLs, because doing so will make management much easier.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit his personal Web site at www.brienposey.com.