How do group policy settings flow down into the lower containers and objects?

I’ve had a few queries from friends about group policy since my last post so I thought why not answer these queries here on my blog? And, yes, a few of them were about group precedences, hence this short FAQ.

Nội dung chính Show

Normal mode
Loopback: Merge mode
Loopback: Replace mode
Group Policy Loopback Support as described in MS whitepaper:

What is the order of precedence in group policy?

I’ve prepared an illustration which I hope will help to understand the order of precedence for Group Policy.

While this illustration may be self-explanatory (at least I hope it is) there’s actually more to the story…

What is the order of precedence in an OU hierarchy?

GPOs linked to an organizational unit at the highest level in Active Directory are processed first, followed by GPOs that are linked to its child organizational unit, and so on. This means GPOs that are linked directly to an OU that contains user or computer objects are processed last, hence has the highest precedence.

In the example below the “Add Local Admins” GPO will have precedence over the “Enable SCCM Ports” GPO since it will be processed last and thus potentially overriding the settings in the GPO higher up in the hierarchy.

What if several GPOs are linked to an OU?

If you have more than one GPO linked to an OU then the processing order of these GPOs is determined by what is known as the link order. The GPO with the lowest link order will be processed last – in other words the GPO with a link order of 1 has the highest precedence, followed by link order 2, etc.

To confirm the link order open the GPMC console, select the OU you’re interested in and take a look at the Linked Group Policy Objects tab. Here’s an example:

In this case the DisableFirstLoginAnimation GPO will have precedence over the AddLocalAdmins GPO.

What about group policy inheritance and blocking?

GPOs applied to a domain, site or OU are inherited by child containers. As with multiple GPOs in an OU, the processing order is determined by the link order.

You can choose to block inheritance so that settings from a GPO applied in a parent OU, for example, will not be inherited by a child OU. Consider the following screenshot as an example before inheritance is blocked:

As you can see the Computers OU is inheriting the AddLocalAdmins, Default Domain Policy and SCCM_Ports_IN GPOs from parent level containers.

Now, if we disable inheritance on this OU, the processing order is amended like so:

As you can see only the GPO that is applied directly on the OU will be processed with the inheritance blocked.

How does GPO enforcement work?

Simply put, enforcing a GPO means that the setting in the enforced GPO will take precedence over settings in a child object.

Consider our previous example where blocked inheritance on our Computers OU:

Now, if we enforce our Default Domain Policy GPO (as we should be) then this policy will be “forced” to apply on the Computers OU regardless.

aGPOs are assigned to containers (sites, domains, or OUs). They are then applied to computers and users in those containers. GPOs can contain both computer and user sets of policies. The Computer section of a GPO is applied during boot. The User section of a GPO is applied at user login. User GPO processing can be configured three different ways, as documented below. Which processing order to use is determined by the GPO which is applied to the computer.

Example:

Normal mode

Loopback: Merge mode

Loopback: Replace mode

GPOs assigned to local machine during boot (Computer sections of the policy)
Local Machine Policy [LMP] Site GPOs [S2] Domain GPOs [D] OU GPOs [T,B]GPOs assigned to local machine during boot (Computer sections of the policy)
Local Machine Policy [LMP] Site GPOs [S2] Domain GPOs [D] OU GPOs [T,B]GPOs assigned to local machine during boot (Computer sections of the policy)
Local Machine Policy [LMP] Site GPOs [S2] Domain GPOs [D] OU GPOs [T,B]GPOs assigned to user during logon (User sections of the policy)Local Machine Policy [LMP] Site GPOs [S1] Domain GPOs [N] OU GPOs [U]GPOs assigned to user during logon (User sections of the policy)Local Machine Policy [LMP] Site GPOs [S1,S2] Domain GPOs [N,D] OU GPOs [U,T,B]

In terms of order of operations, the GPOs would be applied in this order: LMP,S1,N,U,S2,D,T,B

GPOs assigned to user during logon (User sections of the policy)Local Machine Policy [LMP] {From Computer location} Site GPOs [S2] Domain GPOs [D] OU GPOs [T,B]

Detailed Computer Configuration Application Order: Windows NT System Policies, if the computer is a member of a Windows NT 4.0 Domain that uses them, are applied first. Then Windows 2000 GPOs are applied, starting with Local GPO – This is the only one if the computer is in a Windows NT 4.0 Domain.

Detailed User Configuration Application Order: Mandatory/Roaming Profile, if present, is applied first. Then Windows NT ntuser.pol is applied if the user is from a Windows NT 4.0 Domain that uses System Policy. Then Windows 2000 GPOs are applied, starting with Local GPO.

Group Policy Loopback Support as described in MS whitepaper:

Group Policy is applied to the user or computer, based upon where the user or computer object is located in the Active Directory. However, in some cases, users may need policy applied to them, based upon the location of the computer object, not the location of the user object. The Group Policy loopback feature gives the administrator the ability to apply Group Policy, based upon the computer that the user is logging onto.

To describe the loopback feature, we’ll use an example. In this scenario, you have full control over the computers and users in this domain because you have been granted domain administrator rights.

The following illustration shows the Streetmarket domain, which is used to work through this example.

Figure 8. The Streetmarket domain

When users work in their own workstations, they should have Group Policy applied to them according to the policy settings defined, based on the location of the user object. However, when users log on to a computer whose computer object is in the in the Servers OU, they should get user policy settings based on the computer object location, rather than the user object location.

Normal user Group Policy processing specifies that computers located in the Servers OU have the GPOs A3, A1, A2, A4, A6 applied (in that order) during computer startup. Users of the Marketing OU have GPOs A3, A1, A2, A5 applied (in that order), regardless of which computer they log on to.

In some cases this processing order may not be appropriate, for example, when you do not want applications that have been assigned or published to the users of the Marketing OU to be installed while they are logged on to the computers in the Servers OU. With the Group Policy loopback support feature, you can specify two other ways to retrieve the list of GPOs for any user of the computers in the Servers OU:

Merge mode. In this mode, during logon the user’s list of GPOs is gathered normally by using the GetGPOList function, and then GetGPOList is called again using the computer’s location in the Active Directory. Next, the list of GPOs for the computer is added to the end of the GPOs for the user. This causes the computer’s GPOs to have higher precedence than the user’s GPOs. In this example, the list of GPOs for the computer is A3, A1, A2, A4, A6, which is added to the user’s list of A3, A1, A2, A5 which results in A3, A1, A2, A5, A3, A1, A2, A4, and A6 (listed in lowest to highest priority).
Replace mode. In this mode, the user’s list of GPOs is not gathered. Only the list of GPOs based upon the computer object is used. In this example, the list is A3, A1, A2, A4, and A6.

The loopback feature was implemented in the Group Policy engine, not in the GetGPOList function. When the Group Policy engine is about to apply user policy, it looks in the registry for a computer policy, which specifies which mode user policy should be applied in. Then, based upon this policy, it calls GetGPOList, as appropriate.