It’s not the first time that we’ve talked about it and it certainly won’t be the last – Microsoft’s well-intentioned proliferation of information sometimes can actually create confusion through incomplete information or contradiction, perceived or real. Loopback policy processing is one of those technologies that is destined to fit into this bucket.
It comes up pretty frequently in the newsgroups and not long ago we responded to one such question here: http://tinyurl.com/loopbackpolicyprocessing. I was going to leave it there but today I had a friend at Microsoft ask how it worked (well, really, why the implementation they were using wasn’t working) so I decided to post the contents of my newsgroup response here with a little polishing.
Understanding loopback policy processing really requires that we understand standard policy architecture, policy evaluation, and policy application. The first thing to remember is that precedence and application of policies for users and computers is typically evaluated separately (except for loopback processing) as a user and computer may be, and likely are, in separate OU structures. Though there may be overlap, there is also a fair chance that the policy set for each object diverges somewhere.
Loopback policy processing changes that dynamic some and creates an intersection of user and computer policies. There are two possible modes with Loopback Policy Processing, Merge Mode and Replace Mode. There’s plenty of documentation explaining how this technology works but I think the easiest way to understand this technology is with an illustration. Let’s walk through how policy application to computers and users typically works, then we’ll look at loopback policy processing with merge mode, and finally loopback policy processing with replace mode.
Here’s the typical policy application scenario:
a. A computer starts up and applies the computer portion of the policies that apply to the computer object through the layers of the OU structure where the computer resides. Let’s say for the sake of this illustration that there are 4 of them in reverse order of precedence:
4. default domain policy
3. efs
2. restricted_groups
1. fdccb. A user comes along, logs on and applies the user portion of policies linked to the user object’s parents through the layers of the OU structure where the user resides. Let’s say for the sake of this illustration that there are 2 of them in reverse order of precedence:
2. default domain policy
1. desktopEND RESULT: Computer portion of policies linked to the computer object’s parents (or site) are applied; User portion of policies linked to the user’s object’s parents (or site) are applied. What the actual resulting policy settings will be depends on the user that logs on.
Here’s loopback policy with merge mode enabled on the same user and computer:
a. A computer starts up and applies the computer portion of the policies that apply to the computer object through the layers of the OU structure where the computer resides. let’s say for the sake of this illustration that there are 4 of them in reverse order of precedence:
4. default domain policy
3. efs (pretend we added the loopback policy setting here)
2. restricted_groups
1. fdccb. A user comes along, logs on, and applies the user portion of policies that are linked to the user object’s parent objects through the layers of the OU structure where the user resides. Let’s say for the sake of this illustration that there are 2 in reverse order of precedence:
6. default domain policy
5. desktopAND any settings in the user portion of the same policies as applied to the computer object in the same order of precedence:
4. default domain policy
3. efs
2. restricted_groups
1. fdccEND RESULT: Computer portion of policies linked to the computer object’s parents (or site) are applied; User portion of policies linked to the user object’s parents (or site) are applied and they are overwritten by any conflicting policy settings in the user portion of policies linked to the computer object’s parent (or site)
Finally, here’s loopback policy with replace mode enabled on the same user and computer:
a. A computer starts up and applies the computer portion of the policies that are linked to the computer object’s parents through the layers of the OU structure where the computer resides. Let’s say for the sake of this illustration that there are 4 of them in reverse order of precedence:
4. default domain policy
3. efs (pretend we added loopback setting here)
2. restricted_groups
1. fdccb. When the user comes along, the user portion of policies that apply to the user object’s parent containers are not applied. Only the user portion of the policies that are linked to the computer object’s parent objects are applied and in the same order of precedence as above:
4. default domain policy
3. efs
2. restricted_groups
1. fdccEND RESULT: Computer portion of policies linked to the computer object’s parents (or site) are applied; User portion of policies linked to the computer object’s parents (or site) are applied. The user object’s policies are discarded altogether.
I know that can be a lot to take in. Microsoft not only cautions the use of loopback policy processing because it can be a performance hit (read slow logons) but also because, as previously mentioned, using it correctly really requires a solid understanding of policy structure, policy evaluation, and policy application and an understanding of loopback policy processing. For this reason, in most instances, it tends to cause more problems than it solves. But it doesn’t have to. Hopefully this gives some clarity to loopback policy processing and helps you avoid some common pitfalls.