Despite their name, AD group policies can only be assigned to Sites, Domains, and Organization Units. But there is way that you can trick Active Directory into assigning policies to groups, which it doesn't want to do.
Group policies are like old NT system policies on steroids. They only work on Win2k machines, but they are worth the hassle. The biggest difference between the two is that group policies undo themselves. To remove an NT system policy, in practice, you had to write another policy that reversed the first policy. When you remove an AD policy, the policy is automatically removed from all affected users.
It's that "all affected users" thing that can be kind of confusing at first. Let's say you want to establish a policy that allows system administrators to change their system clock (by default Win2k machines sync with net time and don't allow users to change it.) You generate a Group Policy Object that says anybody impacted by the object is allowed to change his system clock. Now here's the catch. You can only apply group policies to Sites, Domains, and Organization Units (OUs). You see this grouping that Microsoft calls SDOUs come up frequently. So how do you allow system administrators in the accounting department to change their system clock without allowing all the accountants the same privilege?
You can apply a group policy to a group using the "permissions" property of the group policy object (GPO). A GPO may not be a file, but you can control who has access to the GPO in the same way you control who has access to a file. That means you can control which users, or which groups, have access to a GPO. Therefore, you can apply the GPO to the entire accounting OU, but only allow the SysAdmin group access to the GPO.
A word of caution is in order here. While you can use access privilege to apply group policies, you may not want to use it. Group policies operate on all the containers previously mentioned, sites, domains and OUs. They can be applied to OUs that are contained in other OUs that have different GPOs applied. Group policies are inherited, inheritance can be blocked, the inheritance blocking can be overridden, and now you're about to mess with whether particular groups have access to particular GPOs. Carefully consider whether future troubleshooting is worth today's filtering solution.
Procedure:
Create a group policy using the procedure outlined at
http://www.microsoft.com/windows2000/techinfo/planning/management/groupsteps.asp
Apply the policy to a container (preferably OU) that contains the group you want to influence.
Restrict access to the GPO to only the group you want to influence.
Here are some other documents on Group Policy administration:
Intro to Group Policy
http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolicyintro.asp
Group Policy White Paper
http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp.
Kevin Sharp is a registered professional engineer, writer and yoga teacher living in Tucson, Arizona, and gains his expertise from a variety of professional activities. His engineering outlets include Web consulting for Supply Chain Systems Magazine, focusing on the fulfillment side of electronic commerce. His writing interests have produced books and articles on the economic impact of technology on manufacturing and distribution organizations.
