Group
Policies are normally applied to the user or their PC depending on where they
are located in Active Directory. There are occasions, especially for terminal
servers, when you wish users to have certain policies applied depending on
which computer they log on to. This is where the loopback policy comes into its
own.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".
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.
In
order to define the Loopback Processing setting, the following steps should be
followed.
1. Open the Group Policy Object editor
(gpedit.msc). See Create/Edit GPOs for details.
2. Expand the Computer Configuration node.
Under Computer Configuration, expand the Administrative Templates node.
3. Within the Administrative Templates node,
expand the System node, and then the Group Policy node.
4. Locate the setting "User Group
Policy loopback processing mode". Double click this setting, and define
the setting as needed.
* 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.
