General GP Concepts
.. GPMC
.. Create/Edit GPOs
.. Targeting GPOs
.. Applying GPOs
.. Developer Issues
Extensions
.. Admin Templates
.... Windows Firewall
.... Internet Explorer
.. Security Policy
.. Software Installation
.. IE Maintenance
.. Scripts
Policy Exceptions
.. Loopback
.. Enforce/Block
.. Slow Links
.. WMI Filters
Reference
.. Third Party Products
.. KB Articles
.. Community
Loopback |
Loopback processing is a feature that allows a more precise level of control over user policy settings for a targeted machine. Usually, user policy settings are derived entirely from the GPOs associated with the user account (based on it's location in the Active Directory). With loopback processing, however, the user policy settings in the GPOs associated with the machine are applied.
A common use of loopback is on Terminal Services machines. In this scenario, it is common for the Group Policy administrator to set specific user policy settings for the server to ensure that all users using the machine receive a defined set of user policy settings.
Two modes options when applying loopback processing:
- Replace Mode: The user policy is defined entirely from the GPOs associated with the machine. Any GPOs associated with the user are ignored.
- Merge Mode: The user policy settings applied are the combination of those included in both the machine and user GPOs. Where conflicts exist, the machine GPOs "win".
Loopback Setting Technical Details:
In order to define the Loopback Processing setting, the following steps should be followed.
- Open the Group Policy Object editor (gpedit.msc). See Create/Edit GPOs for details.
- Expand the Computer Configuration node. Under Computer Configuration, expand the Administrative Templates node.
- Within the Administrative Templates node, expand the System node, and then the Group Policy node.
- Locate the setting "User Group Policy loopback processing mode". Double click this setting, and define the setting as needed.
When the loopback setting is enabled on a machine (either via local policy or domain policy), the behavior of group policy application changes in one of two ways, depending on the selected mode. It should be noted that while the setting affects the behavior of application of user policies, the setting itself is applied to the machine the user logs on to.
- Merge Mode: When Merge mode is selected, application of user-based group policy begins as normal:
- The distinguished name of the user is evaluated for it's location in the Active Directory. For example, the user John Smith in the Boston OU at BigCompany Corporation might have a distinguished name of CN=John Smith,OU=Boston,DC=BigCompany,DC=Com.
- Group policy parses the Distinguished Name, and attempts to locate policies that apply to users at each "stage" of the name. The search is performed from left to right (e.g. the Boston OU is searched first, then the domain root of BigCompany). Finally, the Active Directory Site of the user is evaluated for user policies.
- Based on the effective permissions of the user, Group Policy determines which of these policy objects (if any) should apply to the user.
- Policies are then applied in a last in, first out (LIFO) series. So, any policies that applied at the site level are applied first, then the domain, and finally at the OU containing the user. If multiple policies were defined at the OU or domain level, the policy with the highest precedence is added to the list first (so it will be processed last, and overwrite earlier policies).
To this point, policy processing is exactly like normal. However, once 'normal' processing has completed, a second iteration begins:
- As before, Goup Policy evaluates the Distinguished Name - except this time, it is the Distinguished Name of the Computer, rather than the User. For our example, let's say that the computer is in the Headquarters OU under the BigCompany root. The Distinguished Name is OU=Headquarters,DC=BigCompany,DC=Com.
- The same processing rules apply as before: Group Policy evaluates policies at each level of the Distinguished Name, adding policies to the stack of policies to apply. The difference is that Group Policy is now searching for User policies that are defined in the computer's organization structure.
- This second set of policies is applied (again, Last In, First Out), with any policy setting conflicts being "won" by the last policy to apply the setting. So, if more restrictive settings are defined for users in a policy object linked to the Headquarters OU, those settings will apply to the user when logging onto a machine with Merge mode applied.
Typically, Merge mode is defined on Terminal Servers in an environment. The reason for this is that Administrators typically want to enforce a specific set of desktop and security settings, to help minimize potential variables that lead to unpredictable behavior on the Terminal Server. By enabling Merge mode, and defining all potential problem policy settings, the Administrator can enforce a consistent user experience.
- Replace Mode: Replace mode is actually simpler to explain than Merge mode:
- In Replace mode, the user's Distinguished Name is not evaluated for Group Policy processing. Instead, we rely entirely on the Distinguished Name of the machine the user is logging onto.
- Again using the previous example, the Distinguished Name OU=Headquarters,DC=BigCompany,DC=Com would be evaluated for User Policies, with any policies that the user has permissions to read and apply being enforced.
- As before, the list of policies to apply is built from closest to farthest away (OU=Headquarters first, then DC=BigCompany, etc..). The list is then applied in reverse order, so that the OU settings have highest precadence.
- The "normal policy set" for the user is ignored completely. Part of policy application is to delete the settings applied previously, so no (managed) settings will carry over to apply when Replace is defined, unless that setting was also defined in the User Settings applied during Replace mode.
Replace mode is useful for environments where specific policies are required regardless of the rights and settings of the user. Kiosk systems are a good example of this; an Administrator would typically have an unrestricted desktop experience. If that user logs onto a Kiosk machine, he or she would normally have a "wide open" desktop. This might be dangerous, so it may be useful to enable Replace mode to enforce a specific set of enforced settings.
A Loopback Example:
The easiest way to try and illustrate Loopback is with an example.
Take a domain with two OUs, one for computers and one for users. Now create and link one GPO to each container (GPOA linked to the domain, GPOB linked to CompOU, GPOC linked to UserOU).
It should look like this:
Domain . . . . . . . GPOA
/ \
GPOB . . . CompOU UserOU . . . . GPOC
When Group Policy applies (startup/logon/periodic refresh, nothing unusual here) the following GPOs will apply:
Computer/User mode | GPO List |
Computer (always) | GPOA, GPOB |
User Normal | GPOA, GPOC |
User Loopback Replace | GPOA, GPOB |
User Loopback Merge | GPOA, GPOC, GPOA, GPOB |
- Computer will always get the same list of GPOs - loopback only affects users policies.
- In replace mode, the user will get the list of GPOs that apply to the computer - the user list is replaced with the computer list.
- In merge mode, the user will get a combination or concatenation of both the user and computer lists.
Make sense so far?
Now for the next trick. Loopback only determines which GPOs will be processed. Loopback will not make computer policies (in GPOB) apply to users!
Keep in mind that each GPO has user policies and computer policies. So in the above example, if you set a user policy in GPOB, the only way to get that policy to take effect is to make sure that the GPOB is in the list of GPOs that the apply to the user. Using Loopback as illustrated here is one method of accomplishing this. Linking it to the domain or to the other OU is another method.
Comments:
From Syspro - 3/3/08 3:05 PM
From orion1971 - 2/29/08 5:07 PM
From tserna - 10/4/07 6:09 PM
From xlr8forward - 10/23/06 2:41 PM
For clarification, why do we need 2 policies, one for computer configuration and one for users?
Thanks..
From Bart [81.246.56.124] - 5/19/06 12:18 PM
What Peter tells here above is correct. But there's a way to put a filter on the user policies so it only applies to them.
Even if you place computer permissions on the loopback policy, it's only applied to that computers.
The best thing is to create an AD group, put some user accounts in it. And give only that group the rights to be applied.
From Peter [84.195.10.220] - 2/25/06 5:10 AM
Loopback policies work this way:
In one ou you need two policies:
1) Machine policy with lookback set
2) User policy with your settings
Your computer to apply it to need to be in the same OU
The user setting will appy to any user logging onto these computers regardles if they are in this OU or not.
That is why it is a loopback policy.
From Pankaj Goyal [210.211.171.50] - 2/23/06 1:35 AM
Hi,
I have a one question regarding Group policy applied to a particular machine. I have a machine named tech1 in domain. I want that only one domain user hsingh is able to log on to this particulat machine, no other domain user should be able to login to this machine.Can u tell me how I can do this so that only hsingh is able to login to that particulat machine unabling the other domain users to use that machine.
From Richard Blears [195.8.178.214] - 8/10/05 3:49 AM
I have an ongoing issue with loopback processing. I have an ou with my citrix servers in it, this has a group policy called citrix users , block policy inheritance is set against this ou and the group policy loopback processing with replace has been set. Ok here is my problem, i have a user who is in another ou with a group policy applied, i do not want the settings in this gpo to be applied when the user logs onto a citrix application, problem is that policy is applied. What am i doing wrong?
Comments please.
From Jerome Cruz [130.76.32.15] - 7/15/05 3:10 PM
The only GPO settings applied by policies at the root of a domain that cannot be overidden by other GPO (as applied to domain accounts) are the "Account Policies" settings located in the DDP (Default Domain Policy). All other GPO based settings can be changed, or blocked (using Block Inheritance at the OU level), or "made to apply anyway" through use of the Enforce option.
The reason that only the "Account Policies" cannot be altered is that the GUID of the standard DDP policy is the same in EVERY Microsoft Active Directory domain and the Domain Controllers are hard-coded to read those account policies (from that GUID alone). That's why we can only have a single set of "Account Polices" settings for any single domain. All other settings are "fair game".
From Richard Blears [195.8.178.214] - 7/14/05 6:40 AM
My understanding is that Group Policy at the domain leve will be applied regardless of wether or not loopback and or block inheritance has been set. At least that is what I am experiencing, and it seems to explain some of the strange behaviour that i have been getting, paticularly with screensaver locking in a citrix environment.
Any comments.
From Alan Cuthbertson [220.237.178.230] - 6/13/05 4:40 PM
1. Place blocking on the Citrix OU to stop any policies from the Domain applying to the CITRIX OU. this will stop all policies from the domain, except those with No Override.
2. Use security filtering on the specific policy and put the Citrix server(s) in the deny list
3. Apply an additional policy on the Citrix OU that disables Lock screen
My preference would be option 3. This will give you a policy that shows the differences between a normal machine and a Citrix machine.
From JD [130.36.62.127] - 6/9/05 1:53 PM
Hey - I'd like to talk to the guy who stated that dropping domain policies on a user who is also using Citrix? We've seen weird behaviors in this area. Clients are logged into domain, then log into citrix getting "unlock computer" screens. Use of loopback-replace mode is enforced, but domain policy which enabled password protect screensaver and the timeout are still getting applied to the user. Citrix server sending "unlock computer" when it believes client is no longer active. However, this is not the case.
Clients are PC W2K professional, DCs Windows 2003, citrix servers W2K or Windows 2003
Anyone else comment?
From Me, Myself, & that guy over there... [156.75.192.111] - 4/26/05 12:28 PM
From TimCarter - 3/8/05 4:59 PM
OK, should be of some use for my users which have both Terminal server applications starting by default (no desktop access) and their own XP desktops.
Will all administrators logging on to the specified Terminal server also get the program forced upon them if it is set in the Terminal server Manager for that server?
Tim
Last Modified 3/7/05 10:10 AM
to orion1971: This is probably not the best place to get answers on your Group Policy problems. Try going to www.gpoguy.com/lists.htm and register to join the GPTALK list. As to your problem, it sounds like it is behaving correctly. The user must be a member of the OU that the Policy is applied to. Being a member of a security group that has apply access to the policy is not enough. Security filtering is an additional requirement i.e. you must be a member of the OU AND be a member of a group that has APPLY authority. (Note:Member of the OU means "a member of that OU or of a child OU". See also http://grouppolicy.editme.com/Targeting)