Tuesday, June 15, 2010

GPO loopback, and apply user setting a group of computer account

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?

user setting 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.

No comments:

Post a Comment