Loopback demystified

Hello there. Often I see confusion about what Group Policy Loopback processing is, how it works and what to take care of when using it. Microsoft’s documentation on Loopback processing, although technically correct, seems somewhat “hard to understand”:

http://technet.microsoft.com/en-us/library/cc978513.aspx
http://technet.microsoft.com/en-us/library/cc779327.aspx
http://technet.microsoft.com/en-us/library/cc785074.aspx

Here’s my explanation about Loopback processing. Comments and feedback are welcome!

What is Loopback intended for?

Imagine one of the following scenarios:

·       You have workstations and Terminal Servers. On both, there’s a “Shutdown” item in the start menu. That’s ok for workstations, but not for Terminal Servers. So, on the Terminal server, the “Shutdown” item shall be disabled via Group Policy. Unfortunately, all start menu related GPO settings are user settings that we now require to be different on two computers, but for the SAME user… We need “additional” user settings – that’s Loopback “Merge” Mode. Merging appends GPOs to the common  GPO set for a user.

·       You have computers accessible for public users (i.e. “Kiosk Terminals”). On these, all users should get the same locked down settings (commonly: IE as  shell, no context menu, no caching and so on). So on these computers, we need a common set of user GPOs than enforces the lockdown, regardless of who is logging on. We need “different” user settings – that’s Loopback “Replace” Mode. “Replace” in fact replaces the common  GPO set for a user with a completely different GPO set.

How does Loopback change how GPOs are applied?

You may already know that GPOs are processed according to their linkage to Active Directory Sites, Domains and OUs – down to where our account (user or computer) resides. This “tree” is called the “Scope of Management” (SOM). See http://msdn.microsoft.com/en-us/library/cc232530.aspx for a complete description of GPO application.

This is our “corp.contoso.com” domain. It has a “corp root” OU where we put servers, workstations and users in appropriate Sub-OUs where several policies are linked. All GPOs  (even those linked to “Workstations”) contain one or more user settings.

We have an “user” account residing in corp.contoso.com/Corp Root/Users/Backoffice. His “common” GPO set looks like this:

Policy Name	Policy Link (SOM)
Headquarters Site Policy	corp.contoso.com/Configuration/Sites/Headquarters-Site
Corporate Domain Policy	corp.contoso.com
Corp Root Policy	corp.contoso.com/Corp Root
Users Policy	corp.contoso.com/Corp Root/Users
Backoffice Policy	corp.contoso.com/Corp Root/Users/Backoffice
Users Policy – enforced	corp.contoso.com/Corp Root/Users
Corp Root Policy – enforced	corp.contoso.com/Corp Root
Corporate Domain Policy – enforced	corp.contoso.com
Headquarters Site Policy – enforced	corp.contoso.com/Configuration/Sites/Headquarters-Site

As the table shows, GPO processing starts at Site level, then walks down from the Domain level to the “Backoffice” OU, applying all non-enforced GPOs. Then it walks the same way back, processing enforced GPOs. And with “last writer wins”, this ensures that enforced GPOs in fact DO win.Now let’s have a look how processing works when Loopback “Merge” mode is enabled:

Policy Name	Policy Link (SOM)
Headquarters Site Policy	corp.contoso.com/Configuration/Sites/Headquarters-Site
Corporate Domain Policy	corp.contoso.com
Corp Root Policy	corp.contoso.com/Corp Root
Users Policy	corp.contoso.com/Corp Root/Users
Backoffice Policy	corp.contoso.com/Corp Root/Users/Backoffice
Users Policy – enforced	corp.contoso.com/Corp Root/Users
Corp Root Policy – enforced	corp.contoso.com/Corp Root
Corporate Domain Policy – enforced	corp.contoso.com
Headquarters Site Policy – enforced	corp.contoso.com/Configuration/Sites/Headquarters-Site
Headquarters Site Policy	corp.contoso.com/Configuration/Sites/Headquarters-Site
Corporate Domain Policy	corp.contoso.com
Corp Root Policy	corp.contoso.com/Corp Root
Workstations Policy	corp.contoso.com/Corp Root/Workstations
Desktops Policy	corp.contoso.com/Corp Root/Workstations/Desktops
Workstations policy – enforced	corp.contoso.com/Corp Root/Workstations
Corp Root Policy – enforced	corp.contoso.com/Corp Root
Corporate Domain Policy – enforced	corp.contoso.com
Headquarters Site Policy – enforced	corp.contoso.com/Configuration/Sites/Headquarters-Site

We now have two cycles of GPO processing. The first is exactly the same as it was without Loopback. The second cycle also starts at Site level and walks down from the Domain. But this time, although we are processing user GPOs, it walks down to “Desktops” and applies User GPOs linked at “Workstations” and “Desktops”.

Remark: User GPOs processed in the second cycle only get applied as long as the workstation account (!) has at least read access to the GPO. See http://support.microsoft.com/kb/953768.This feature enables us to link a GPO to „Desktops“ that has „Remove and prevent access to the Shut Down, Restart, Sleep and Hibernate commands” enabled and has Security filtering for “Domain Users” (so all users will apply the GPO) and for the workstations only where we need this setting enabled (i.e. Terminal Servers).

Remark: Enabling “Merge” mode almost doubles GPO processing time. And if you define Logon Scripts at Domain Level, they will execute twice…

Last, let’s enable Loopback “Replace” mode:

Policy Name	Policy Link (SOM)
Headquarters Site Policy	corp.contoso.com/Configuration/Sites/Headquarters-Site
Corporate Domain Policy	corp.contoso.com
Corp Root Policy	corp.contoso.com/Corp Root
Workstations Policy	corp.contoso.com/Corp Root/Workstations
Desktops Policy	corp.contoso.com/Corp Root/Workstations/Desktops
Workstations policy – enforced	corp.contoso.com/Corp Root/Workstations
Corp Root Policy – enforced	corp.contoso.com/Corp Root
Corporate Domain Policy – enforced	corp.contoso.com
Headquarters Site Policy – enforced	corp.contoso.com/Configuration/Sites/Headquarters-Site

Again, this is very similar to the previous Loopback “Merge” mode, but the user SOM is omitted completely. Only the second cycle from “Merge” mode takes place, applying only user GPOs linked to the computer’s SOM.

As common user GPOs are no longer applied, we now may deploy a specialized GPO set for given computers that applies to all users logging on.

That's all for now, stay tuned!

Introducing myself

Hi all. Forgot this little, but not unusal thing... Who am I, where do I come from?

I'm a computer worker in a german company. We support our customers through delivering complete domain infrastructures including software management, delegation permissions in AD (and concepts, of course) and a security and convenience settings baseline implemented throught group policy.

In my spare time, I play with Lego for the big boys, take care of my house and family (sorry, no link and no photo due to privacy reasons ;-)) and enjoy driving a '79 L82. You know what I mean, don't you? ((:

Ah - and I started working with computing technology back in 1979 with a Texas Instruments TI-59 (famous 960 bytes of magnetic strip memory...).

Now I'm here... And I know, it is "42". Heck - what was the question? Where is my towel???

My first blog post ever - think you enforced your GPOs and you are safe?

Imagine the following scenario: You are administering a wide spread domain, containing lots of OUs. For ease, you delegate GPO adminstration on some OUs to local admins in branch offices. But to maintain corporate guidance, you enforce some GPOs at top level (eg. desktop background and screen saver).

MSDN: GPO evaluation process 


This prevents the "bad guys" in the branch offices to change these corporate settings, right?

Totally wrong.

If you rely on your settings being in place, enforcing is ok. But DO NOT USE ADMINISTRATIVE TEMPLATES!

Here's why not.

Group policy processing is a multi stage process. GPOs have an inheritance order that determines which GPO settings get applied last. And last writer wins. So far, so good. But then, CSEs pop in - the "client side extensions". These are responsible for applying various aspects in GPOs (eg. IE Maintenance, MSI installation and so on).

MSDN: Group Policy Application process


The primary "order" that takes place in GPO processing is the invocation order of CSEs. Each CSE is invoked (in a predetermined order), and then each CSE processes the GPOs containing settings for that CSE. What does that mean for administrative templates?

ADM templates (aka "registry policy") are always processed as the very first CSE. All other CSEs are processed in alphabetical order as found in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. And ADM templates are just registry values. That concludes that each and every CSE processed afterwards is able to change these registry values, and the contents of your corporate guidance GPOs are overwritten. This applies to: Security policies (gpttmpl.inf can be edited to set any registry value), MSI installations, startup scripts and - worst - Group Policy Preferences "Registry".

MSDN: GPO CSE processing order

(Remark: This article states "The Group Policy Registry Extension MUST always execute first"). That's the only statement I ever found that documents why ADM templates are processed first - regardless of the alphabetical order of their GUID {35378EAC-683F-11D2-A89A-00C04FBBCFA2}.)

How does that interfere with your corporate administrative templates?

You enforce a corporate screen saver policy - timeout, executable and so on. This results in several registry values in HKCU\Software\Policies\Microsoft\Windows\Control Panel. The bad guy creates his own GPO, and there he deploys the exact same registry values - but not through ADM templates, but through GPP Registry. This CSE is called AFTER the ADM templates have been processed, and - you already know that - "last writer wins". Gone are your corporate settings, even although you "enforced" them.

CSE processing order in Win 7/2008R2 

(Remark: At Microsoft, I only found this outdated list...)


How to avoid that?

• Deny the usage of GPP "Registry" to subordinate administrators (only makes it harder, but not impossible - I'll cover that in a different post)
• Do not delegate GPO administration (most secure solution!)
• Implement AGPM (available only with SA, but also secure)
• Disable GPP "Registry" (NoMachinePolicy/NoUserPolicy - but also prevents you yourself from using it)

Also in a further post, I'll show you what you can do with that damned screen saver timeout - it's a user setting, but often you'll want it to be different on some COMPUTERS.


Feel free to post feedback or questions, and even feedback on my - hopefully not so bad - english language is appreciated. I'm native german, and even worse, suabian ((-:

BTW: No screenshots? Yes - they would blow up the post.

sincerely, Martin