Ever have an instance where you needed to apply a consistent user experience on a specific computer no matter who logs in... but also allow their individual user settings to come through to map drives or favorites?
Group Policy Loopback mode to the rescue.
The default behavior of Group Policy application goes like this: If a
user account that resides in an OU falls under the scope of a Group
Policy, it will apply all settings that are defined in the User
Configuration-node in the Group Policy Editor. They just apply the user
portion of the policy. So do computers. They just apply the Computer
Configuration settings from all Group Policies under whose scope they
fall. Quite simple logic: User logs in -> user account in Active
Directory -> User Configuration applies; Machines boots up ->
computer account in Active Directory -> Computer Configuration
applies.
Given the problems above, people sometimes need to have certain User
Configuration policies applied – on all workstations. That can be
useful if you run a Terminal Server environment where people need to
get certain User Configuration settings like screen savers or
something. You might also need that if you want to run machines with a
predefined user environment, no matter who logs in. Locked down kiosk
computers for example. This all are points where Group Policy’s
Loopback processing mode can help. By linking a Group Policy object
with the loopback processing setting enabled to an OU, you force the
computer (~computer accounts) to look at and apply the user
configuration settings of all Group Policies as well:
Computer Configuration\Administrative Templates\System\Group Policy\
How does Group Policy application work, if you have enabled
loopback? Well, let’s create a scenario. Bob wants to log on to the
domain using his machine machine1. Machine1 lies in the scope of a
Group Policy that enables loopback processing. When booting the
computer, Bob will not notice any changes to the computer. It simply
boots up - in the background, all computer configuration settings that
machine1 should get applied, will be applied. Until now, normal
behavior. Bob can now log in. After he logged in, machine1 will process
the following policies depending on what loopback mode was configured
on machine1.
If Merge Mode was selected, machine1 will first
pull and apply all user configuration settings from the Group Policies
of Bob’s Active Directory user account. That is, what would also happen
if loopback wasn’t configured. After having applied Bob’s policies,
machine1 applies all user configuration settings that are configured
for the machine1 computer account in Active Directory. The fact that
machine1’s user configuration settings get applied after Bob’s ones
means, that machine1’s settings will win if there is a
setting-contradiction. Last policy wins, or last writer win? if we want
to say so.
If Replace Mode was selected, machine1 simply
applies all user configuration settings of the Group Policies given for
machine1’s Active Directory user account - nothing more. With Replace
Mode enabled, the machine doesn’t even look at the settings Bob would
normally get applied.
Not that, when machine1 looks at the user configuration settings it
shall apply, it actually impersonates the user logged in. In our
scenario, if Bob was logging in, machine1 will look at all policies it
should apply according loopback, but with Bob’s permissions on every
policy.
|