When you create a GPO, Active Directory creates a GPC for that GPO. This GPC is created as a container object with the groupPolicyContainer object class and is named with a globally unique identifier (GUID). The GPC is then stored under the CN=Policies,CN=System container within the currently selected domain. Active Directory and related tools find the container according to its distinguished name (DN). A DN, as you might recall from Chapter 2, is the exact path to an object in the Active Directory data store.

To see how this works, consider the following example:

Objects in the directory store also have a canonical name, which is specified more like a path. The canonical name for the Sales Policy GPO is:

cpandl.com/System/Policies/{0BF0F7D6-0245-4133-BC78-B98AFBA21F48}

You could access and view the container object for the Sales Policy GPO in many ways, but one way is to use the Advanced view in Active Directory Users And Computers. Follow these steps:

As Figure 13-1 shows, each folder entry under System, Policies represents a GPC container. The name of the folder is the GUID of the related container object. As the Active Directory User And Computer’s folder representation shows, within each GPC there are Machine and User subcontainers that represent the Computer Configuration and User Configuration portions of a GPO, respectively. Depending on which policy areas are configured within a GPO, there might also be additional subcontainers under the Machine and User containers. We’ll explore these additional subcontainers when we talk about how Group Policy settings are processed later.

Figure 13-1. Viewing the policy containers in a domain

Note

Each GPC container represents one GPO, and the GUID name of the container is the GUID of the GPO. Naming a GPC using a GUID guarantees that the GPO is always uniquely named within Active Directory even if two GPOs have the same "friendly name" (the descriptive name you enter when you create the GPO). The only exceptions are the Default Domain Policy and Default Domain Controllers Policy GPOs which have the same GUID regardless of in which domain in the forest they reside.

You can learn more about GPCs by examining the class definition of the groupPolicyContainer object itself. One way to view object attributes is to use the Active Directory Schema snap-in for the Microsoft Management Console (MMC). When you start this snap-in, it makes a direct connection to the schema master for the current Active Directory forest.

Note

The Active Directory Schema snap-in is not available by default. You must install the Administration Tools (Adminpak.msi) from the Microsoft Windows Server 2003 CD-ROM. Or, if you are working with a server, you can simply double-click Adminpak.msi in the %SystemRoot%System32 folder.

Once you install the Administrative Tools, you can add the Active Directory Schema snap-in to a custom console by following these steps:

After you add the snap-in to a custom console, you can view the class definition of the groupPolicyContainer object. In Active Directory Schema, expand the Active Directory Schema node, and then expand the Classes node. When you select groupPolicyContainer, you’ll see a list of the attributes for this object in the right pane. Table 13-1 describes some of the more interesting attributes.

Like any objects in Active Directory, GPOs have a set of permissions that control who has access for editing and processing. You can view the security settings on a GPO, just as you can on any other object in Active Directory. To do this, follow these steps:

Viewing a GPO’s security settings in Active Directory Users And Computers is much like viewing a GPO’s advanced security settings from the GPMC’s Delegation tab—the settings are one and the same. The Delegation tab itself provides a "cleaned-up" view of the security settings. While the GPMC differentiates between managing the delegation of a GPO and the security filtering on a GPO, Active Directory Users And Computers does not. Thus, in Active Directory Users And Computers, you have a slightly different view of a GPO’s security settings.

Table 13-2 lists the permissions associated with each delegation and security filtering task. Delegation determines who can read, edit, delete, or modify security on a GPO. Security filtering determines which user or computer can process the GPO.

Caution

Don’t edit security settings from within Active Directory Users And Computers. If you do, you are modifying only the permissions of the corresponding GPC and not the complete set of permissions for the GPO. Remember that each GPO has a logical and physical representation, so if you edit the permissions on the GPC, the permissions on the GPT are not changed. Always use the GPMC, Group Policy Object Editor, or GPMC scripting interfaces to correctly modify GPO security.

In addition to permissions on the GPO object itself, you can delegate who can create a GPO within a domain. You do this on the Delegation tab in the GPMC with a focus on the Group Policy Objects container, as discussed in Chapter 2.

Underlying GPO creation delegation is a set of permissions in Active Directory. These permissions are for creation of new GPOs rather than delegation of existing ones, so the permissions are set on the Policies container (CN=Policies,CN=System). This makes sense because the Policies container is the parent container of all GPCs that are created in a domain.

The permission that is granted on the Policies container is Allow: Create groupPolicy-Container Objects. If you grant this permission to a user or group, the user or group can create new GPC objects under that container and can thus create new GPOs in the designated domain.

You can view the security permissions on the Policy container by following these steps:

Caution

Again, don’t edit security settings from within Active Directory Users And Computers. Always use the GPMC, Group Policy Object Editor, or GPMC scripting interfaces to correctly modify GPO security.

To round out the discussion of security on the GPC, we should also discuss how the default security is set on a GPO. When you use the GPMC to create a new GPO on Windows Server 2003, a new GPC is created in the Policies container with a set of default permissions. These default permissions include the following Access Control Entries (ACEs):

This list is controlled via the defaultSecurityDescriptor attribute on the instance of the groupPolicyContainer schema class object within your Active Directory domain. You can modify this attribute to include other security principals so that when a new GPO is created, those principals have permissions on the GPO. The defaultSecurityDescriptor attribute on the groupPolicyContainer takes the form of a Security Descriptor Definition Language (SDDL) string. For more information on creating SDDL strings, see Chapter 15.

Let’s walk through the steps for viewing and modifying the defaultSecurityDescriptor on the groupPolicyContainer class in order to add a new group to the default security settings on newly created GPOs. Our example includes a domain global security group called GPO Admins that contains administrative users who need to be able to edit any newly created GPOs within a domain. In this case, we want to ensure that this group always has permissions on new GPOs. To add the security group to the default security settings of newly created GPOs, you use the ADSI Edit snap-in for the MMC.

Note

The ADSI Edit snap-in is not installed by default—it is instead included in the Windows Server 2003 Support Tools. Once you install the Support Tools, you can use and work with ADSI Edit as you can other MMC snap-ins.

D:P(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)
(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;CO)(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)
(A;CI;RPLCLORC;;;AU)(A;CI;LCRPLORC;;;ED)

(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)
(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)
(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;CO)
(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)
(A;CI;RPLCLORC;;;AU)
(A;CI;LCRPLORC;;;ED)

Modifying the defaultSecurityDescriptor Attribute

If you want to add a new group to the default security settings on a newly created GPO, you add an SDDL string for this group to the defaultSecurityDescriptor attribute. The easiest way to do this is to place your mouse pointer at the end of the existing set of strings and add it from there.

If you want to give a group called GPO Admins the same rights on newly created GPOs as the Domain Admins group gets automatically, you can use the SDDL string for Domain Admins as a template and modify it for the GPO Admins group. The Domain Admins string looks like this:

(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)

This string results in Domain Admins having Edit Settings, Delete, and Modify security permissions on all newly created GPOs. To grant this same set of permissions to the GPO Admins group, you simply add this SDDL string to the end of the defaultSecurityDescriptor attribute and change the DA to the SID of the GPO Admins group. For example, if the SID for that group is S-1-5-21-817735531-4269160403-1409475253-1123, the new SDDL string is as follows:

(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;S-1-5-21-817735531-4269160403-1409475253-1123)

After this new SDDL string is appended to the end of the defaultSecurityDescriptor attribute, you simply click OK in the String Attribute Editor dialog box to commit the change. Newly created GPOs will have the new GPO Admins ACE associated with them. You can verify this by creating a test GPO and checking the security on the GPO’s Delegation tab in the GPMC (Figure 13-4).

Figure 13-4. Viewing a newly created GPO with a modified defaultSecurityDescriptor

Caution

Be careful when editing the defaultSecurityDescriptor attribute. Removing or changing existing SDDL strings can cause incorrect security to be applied to new GPOs when they are created.

Tip

After you make the change to the defaultSecurityDescriptor attribute, it might not be applied right away to newly created GPOs. You can make sure the change is committed to the schema by starting the Active Directory Schema MMC snap-in tool, right-clicking the Active Directory Schema node, and choosing Reload The Schema. The change must then be replicated to the rest of the domain controllers.