The Administrator Shortcut Guide to Active Directory Security Chapter 3

{LANG_NAVORIGIN} Operating System Microsoft
By: Derek Melber, Dave Kearns, and Beth Sheresh, 04/14/2005

GPO Application

We saw in the last section that GPOs can only apply to computer and user accounts. When considering what the application of the GPO is, you will need to take into account the following three criteria: physical location, domain membership, and location in AD. All three of these criteria match perfectly with the different locations to which a GPO can be linked in AD:

• Physical location—AD site
• Domain membership—AD domain
• Location in AD—AD OU

An easy way to remember where a GPO can be applied is to use the acronym that is developed from these locations: SDOU. We will also see that this acronym is used for inheritance and precedence. As for the application of GPOs at each level in AD, there are different issues to consider for each.

GPOs at AD Sites
By default, there are no GPOs linked to any GPO site. The most likely reason for this default setup is that there is only one site in a default AD forest. This site would include every domain controller, server, and client. There are very few policies that should affect every single computer in the forest, so there are no GPOs linked here by default.

If you are considering whether to link a GPO to a site, bear in mind that all of the computer accounts that are physically located in the subnet that is defined by the site will be affected. This will include domain controllers, servers, and clients. For most GPO policies, this inclusion is too widespread influence. In most environments, domain controllers and clients need to be configured differently to accommodate their role in the domain. The rare cases in which GPOs are linked to sites might include configuring clients for RAS subnets and for Software Update Service (SUS).

GPOs at AD Domains
There is an existing GPO linked to every domain in the forest. This GPO is named Default Domain Policy. The main responsibility of this GPO is to configure the Account Policies for the domain user accounts. The account policies include the password policies, account lockout policies, and Kerberos policies. These policies will control how many characters a password contains, how often the password is changed, what happens if a user forgets his or her password, and the Kerberos ticket details.

Additional GPOs can be linked to the domain, but the same problem occurs at the domain level as it did at the site level. The domain includes domain controllers, servers, and clients, which means that all of these computer objects will be affected by the GPO that is linked to the domain. If the User Configuration section of the GPO is configured, all user accounts in the domain will be affected, including the Administrator account, other domain administrators, IT staff, executives, developers, and employees. In most cases, these user accounts need to be dealt with uniquely; thus, setting a policy that affects them all the same is not generally beneficial.

GPOs at AD OUs
Like the domain level, there is a default GPO linked to the only OU in a new domain. The only OU is the Domain Controllers OU and the default GPO is named Default Domain Controller Policy. This GPO is designed to establish the default security for the domain controllers, which includes establishing the user rights and configuring some security options.

OUs are inherently designed to contain other objects, so it makes sense to use OUs to organize user and computer accounts. As we will soon see, the design of what is contained in the OUs is driven by the GPOs that will be linked to the OU and therefore apply to the objects in the OU. The other deciding factor for the OU design will be delegation of administration.

For most AD environments, the majority of all GPO links will be to OUs. Because the different types of objects that caused problems at the site and domain level can be organized into their own separate OUs, the GPO dilemma is solved when they are linked to OUs.

Inheritance
GPOs follow very strict rules, and obey the rules of inheritance. The rules of inheritance dictate that GPOs will apply in a certain order when there is more than one GPO to be applied. When talking about the inheritance of GPOs, it is important to understand all of the different GPO locations that must be considered. We have already discussed that a GPO can be linked to the site, domain, and OU. There is a fourth location that comes into play when discussing inheritance: the local GPO.

The local GPO is on every computer that runs Win2K and later. The local GPO can’t be removed, but it can be blank, containing no policies that have been configured. By default, the local GPO is not configured.

Order of GPO Application
GPOs can be linked to sites, domains, and OUs. There is also a local GPO on every computer. So which has the highest priority when they are applied to a user and computer account? To answer this question, we must look at the acronym that we defined earlier—SDOU. We are going to add the local GPO to the mix, which now creates our final acronym of LSDOU. This acronym presents the order of application for GPOs.

First, the local GPO applies. Although this GPO resides directly on the computer that it will configure, it has the least priority when compared with the other AD GPOs. Next, the site GPOs apply. These will most likely be few, if any, GPOs. After the site GPOs, are the GPOs linked to the domain, which include the default GPO that is linked to the domain, which configures the domain user accounts’ password restrictions. Finally, the OU GPOs apply and have the final say over all other GPOs. These are the GPOs that are closest to the computer and user objects that reside in AD.

Although GPOs apply in the order of LSDOU, it is important to fully understand how the concept of GPO application works. When a GPO applies to an object, the GPO policy settings are gathered in the order or least priority to most priority. If no GPO policy settings conflict, the order of application is inconsequential. It is only when the GPO policy settings conflict that the precedence of GPO application becomes a factor. Figure 3.3 illustrates how GPO precedence works and what the outcome of the GPO application should be.


Figure 3.3: GPOs apply in the order of LSDOU; when there are no conflicts, all of the settings apply from each GPO.

It is when a policy setting in two different GPOs conflicts that the concepts of precedence and GPO application take affect. The policy setting from the GPO with the highest priority or precedence will be the one that applies to the object, when there is a conflict between two different GPOs. Figure 3.4 illustrates this behavior.


Figure 3.4: When a policy setting in two GPOs conflict, the setting with the highest priority will apply to the object.

Once you fully understand how GPO conflicts are handled from GPOs at different locations in AD, you might wonder what happens when there is more than one GPO at any one level. This situation is not possible at the local level. However, at the SDOU levels it is not only possible but also highly likely at the OU level. Figure 3.5 illustrates what GPOs at the same location would look like.


Figure 3.5: Sites, domains, and OUs can have multiple GPOs linked to them.

When there is more than one GPO linked to a single location in AD, the overall precedence does not change regarding the LSDOU. However, at each level, there is an additional calculation regarding which GPO has precedence at that level. From Figure 3.5, you can see that there are three GPOs. The one at the bottom of the list, No Run, has the least priority, and the one at the top of the list, Lockdown, has the highest priority.

We know that there are two considerations when applying GPO precedence. First, the LSDOU order is essential, with the GPOs linked closer to the target object receiving the highest priority. The second consideration is the order of the GPOs that are linked to the site, domain, or OU. Those at the top of the list will have a higher priority than those at the bottom of the list.

Controlling GPO Application Order
If the default permissions, settings, and hierarchy is left alone, there is little more to discuss with regard to GPO application. However, there are instances and situations that might require additional configurations to control how the GPO application occurs. In the following sections, we will discuss four methods to control the inheritance of the standard GPO application.

Block Policy Inheritance
The typical inheritance is to have the GPO settings append to one another from LSDOU, unless there is a conflict. Then, in the event of a conflict, the GPO with the highest priority wins. The block policy inheritance setting breaks those rules.

The block policy inheritance setting can be configured only at the OU and domain levels. The site level does not support the option to block any policy inheritance. It would only be blocking the local GPO, which it can’t do. If the site GPO is to alter the local GPO, it must do so with a conflicting GPO setting. The local GPO is the first one to apply, so there would be nothing to block even if it could be configured at this level.

Thus, the only two locations that can block policy inheritance are at the AD level, so you will either need to be on the Group Policy tab on the property page of the domain or OU, or you can use the Group Policy Management Console (GPMC). If you are using the AD Users and Computers console, you will need to access the block policy inheritance option by following these steps:

1. Right-click on either the domain or OU level where the configuration will occur.
2. Click on the Properties menu option.
3. Select the Group Policy tab.
4. Select the Block Policy inheritance check box, as Figure 3.6 shows.

Figure 3.6: The domain and OU levels can block policies from lower in the GPO application order.

The result of this setting is that the policies at the local GPO and site GPOs (and the domain GPOs if the OU is configured) will not be a factor in the application of GPOs for the target objects in the configured location. The reason is that the blocking of policy inheritance blocks all other GPOs and policies at the other levels.

No Override
Imagine that a junior-level administrator has just configured the block policy inheritance setting at an OU three levels deep in the AD structure. You, as the domain administrator, have configured GPOs at the domain and top-level OUs to configure all aspects of security for both the computer and user accounts. You find out that the computer and user accounts are not receiving your GPO settings from the domain and OUs because they are being blocked. As you can imagine, this spot is very compromising and can be scary and frustrating. However, there is no need to worry—there is a setting that can trump the block policy inheritance setting. This setting, the no override setting, can’t be stopped by the blocking of policy inheritance. Unlike the block policy inheritance setting, which is global for all GPOs above the location of AD, the no override setting is GPO specific.

The no override setting can be configured for any GPO at the SDOU levels. It can’t be configured at the local GPO level. To configure the no override setting, you can go to the same Group Policy tab while in the AD Users and Computers console, or you can configure the Forced setting inside the GPMC. To configure no override for a GPO from the Group Policy tab, follow these steps:

1. Select the GPO link that you want to force with the no override setting.
2. Click the Options button (or, you can just double-click the cell under the No Override column to get a check mark to appear)
3. Select the No Override check box, as Figure 3.7 shows.

Figure 3.7: The no override setting at the site, domain, or OU takes precedence over the block policy inheritance setting at the domain or OU level.

Security Group Filters
Another way to control the typical inheritance of GPO application is to change the default behavior of security group filtering. What exactly is security group filtering? Security group filtering is a fancy word for modifying the access control list (ACL) of the GPO. Because the GPO is an object in AD, it has an ACL.

The process for modifying the ACL of the GPO is identical to that of a file, folder, or registry key. Of course, the detailed permissions are a bit different, because the GPO is a unique object type. The default permissions of every GPO provide the Read and Apply Group Policy permissions, which allow computer and user objects to receive GPO settings as Table 3.3 shows.

Access Control Entry	Permission
Authenticated Users	Read - Allow Apply Group Policy - Allow

Table 3.3: Default permissions allowing all computer and user accounts to receive GPOs.

Read and Apply Group Policy permissions are the only permissions required to receive a GPO. If either of these permissions is not provided for an object, the object will not receive the GPO settings for that GPO. Remember that the Authenticated Users group includes all computer and user accounts (all domain controllers and the Administrator account).

We need to combine two concepts to ensure that the concept of ACLs on GPOs is clear. Notice that the default ACL on the GPO provides a group for the filtering of the GPO. This particular group includes every computer and user account in the domain. However, we saw in the earlier scenarios that the computer or user account must be in the path of the GPO to receive the GPO settings.

If you refer back to Figure 3.2, Table 3.1, and Table 3.2, you can see that you were not concerned with the ACL of the GPO. The GPOs from Table 3.1 simply had the default permissions, which allowed every account in the path to receive the settings. What if you wanted to restrict BettyF from receiving the GPO settings linked to the Users OU? BettyF is currently receiving the GPO because she is a member of the Authenticated Users group. To restrict her from receiving the GPO, you can simply add her to the ACL explicitly, giving her Deny permissions to either Read or Apply Group Policy, or Deny her both permissions.

Make sure you consider the following key points when establishing GPO security group filters:

• The ACL that is configured for the GPO is a property of the GPO, not a property of the GPO link to the SDOU.
• Troubleshooting GPO filtering can be difficult. The GPMC and other third-party tools are needed to help find where GPO filtering is established.
• Security group filtering should be used as a last resort for solving a unique GPO application problem. The best way to avoid the use of security group filtering is to design your AD properly.

WMI Filters
A final method used to control the default behavior of GPO inheritance is the use of WMI filters. WMI is a remarkable tool that can not only help with GPO application but also with routine network administration. With regard to GPOs, the WMI filter helps determine whether a target account should receive the GPO settings.

For example, if the GPO is installing a software package that is larger than 250MB installed, it would be beneficial to find out if the target computer has enough hard drive space before the installation begins and subsequently fails. So, the WMI query determines whether there is more than 250MB of hard drive space. If the query says “yes,” the software is deployed. If the query returns “no,” the GPO is ignored for that target account.

WMI filters are individual files that contain the query. These files are then associated to the GPOs. To associate a WMI filter to a GPO from within the Active Directory Users and Computers console, follow these steps: Select the Group Policy tab on the Properties window for the SDOU where the GPO is linked.

1. Select the GPO from the list, and click Properties.
2. Select the WMI Filter tab on the HR Properties window.
3. Select the “This filter” radio button, and click Browse/Manage.
4. Click Advanced on the Manage WMI Filters window, click New, and type a name for the WMI filter into the Name field.
5. Type the query that you will use into the Queries text area. An example might be to check for the installation of Windows XP Professional, which would use the following text
   RootCIMV2; SELECT * FROM Win32_OperatingSystem WHERE Caption LIKE “Microsoft Windows XP”
6. Click Save, OK, OK again in the Properties windows, and OK one more time in the next Properties window.

The following list highlights additional key considerations when working with WMI filters:

• WMI filters only apply to WS2K3 and Windows XP; Win2K target computers ignore that WMI filter and apply the GPO.
• WMI filters are associated with the GPO, not the GPO link.
• If a WMI filter file is deleted, but the associate to the GPO is not, the GPO will not apply to any target. The WMI filter extension will return a set of null for targets that meet the query.

Your IP address will be sent with this e-mail

From e-mail to e-mail