Jim Boyce has shown you how you can use group polices to your advantage on your Windows 2000 server. Nevertheless, they can be pretty broad in scope. How do you narrow them down? In this Daily Feature, he shows you how to do just that by introducing you to DACLs.
Welcome to Jim Boyce’s on-going discussion about Windows 2000 group policies! Previously, Jim has shown you how to prepare to use group policies on your network, what they do, and how they work. If you’ve missed any of the previous parts to this series, check them out:
- “Preparing to use Windows 2000 group policies“
- “Understanding Windows 2000 group policies“
- “Understanding group policy processing“
- “Creating a Windows 2000 audit policy“
Why do I need to filter group policies?
By default, group policy objects (GPOs) apply to all users who are members of the site, domain, organizational unit (OU), or local computer to which the GPO is linked. You can use security groups to filter GPO influence, however, by controlling how the GPO is applied based on security group membership. For example, you might want GPOs in an OU to apply to all users except a certain group of power users. Or, perhaps you want to apply a particular GPO to only one specific group.
A little DACL’ll do ya
Each GPO includes a discretionary access control list (DACL) that defines permissions for the GPO, and you can use the DACL to control how the GPO is applied. If a user or group can’t read the GPO, then those settings can’t be applied to that user or group, thereby giving you a means of applying or preventing the application of the GPO by allowing or denying access to it. The DACL also includes a permission called Apply Group Policy that lets you specifically define whether or not a group or user has the GPO applied to it.
The DACL applies to the GPO as a whole, which means that you can use the DACL to allow or deny access to the entire GPO, not to individual portions of the GPO. The Folder Redirection and Software Installation portions of the GPO, however, have additional ACLs, which enable you to refine the way policies in those portions are applied based on security group membership.
You can access the Security settings for a GPO either through the Group Policy console or through the container where the GPO is linked. Open the Group Policy console and right-click the root node of the Group Policy snap-in, choose Properties, and click the Security tab. Or, open the container in the appropriate AD snap-in (such as Active Directory Users And Computers), open the properties for the container, click the Group Policy tab, select a GPO, click Properties, and click the Security tab. You can then use the Security page to set basic and advanced security properties by user and group.
In order for a GPO to apply to a group, the group must have both Read permission and Apply Group Policy permission for the GPO. By default, all GPOs have these permissions for Authenticated Users. Domain Admins and Enterprise Admins have Read, Write, Create All Child Objects, and Delete All Child Objects permissions. Because administrators fall under the Authenticated Users purview, they also implicitly have the Apply Group Policy permission, even though it is not set explicitly in the GPO’s properties.
If a group has Read permission and Apply Group Policy permission for the GPO, the GPO is applied to that group. If you want to prevent a GPO from applying to a specific group, you can simply remove the Apply Group Policy permission from the group. As long as the GPO is not applied through Authenticated Users or another group, the selected group won’t have the GPO applied. You also should remove the Read permission for all groups to which you do not want the GPO applied. Leaving the Read permission intact enables members of the group to read the GPO, which could present a security risk. More important, however, is the fact that removing the Read permission improves performance. And, although it will seldom be a problem in most organizations, group policy fails if a user has the Read permission in more than 1,000 GPOs in a given domain.
Another reason to configure permissions on GPOs is to restrict access to them for administrative purposes. For example, you might configure permissions on a particular GPO to allow it to be managed by a power user in the OU or group to which the GPO applies. Having Full Control in a GPO enables you to modify the GPO but not link it to sites, domains, or OUs. You can use the Delegation Wizard to grant that ability.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.