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.

Delegate non-domain admin group to workstation

My recent work allow me to watch how Helpdesk works on the workstation deployment. It is a large enviornment, so helpdesk group don't have domain admin right, but they still need full admin right to user workstations, so there is a need to add domain\helpdesk group into each workstation, not the servers.


Here is their ways because they use disk cloning to complete OS/APP installation.


1. join in the domine, and add domain \helpdesk group into this local admin group of this workstation
2. remove this workstation from the domain; a unknown user account will show in local admin group, do NOT delete this one
3. clone this workstation
4. join the new workstation into domain, and this unknown user account will become domain\helpdesk group.


I know I can use restricted group in group policy computer setting to delegate a non-domain admin group to workstations, but the process is tricky and easy to make very serious problem, such as removing domain admin group from each workstations.


The group name must be "Administrators" and the Memebers has to include


Administrator - the local administrator
- Domain Admins
- Remote Administrator

This GPO policy is all-to-all change, not a incremental change, so you have to include every member in the group.

Here is another tutorial on restricted group

http://www.windowsecurity.com/articles/Using-Restricted-Groups.html

use group policy to assign a special group , such as helpdesk, to assume local-admin right for all workstation in a OU, whilke keep domain admins and original administrator in the same control level.

It need to create a GPO and apply to this OU. The modification of this GPO is to go to computer setting\windows setting\security setting\restricted group, and create an in group called "administrators" and include "administrator, < >\domain admins, < >\helpdesk " . The trick is to udderstand the name specified above is used like leg for leg, hand for hand. No more, no less. It carve out the exact setting. If you miss out the domain admins group, you won't find it later. I have a lesson for this when I work for Yak in 2006. This is very tricky, very easy to make mistake.


http://www.windowsecurity.com/articles/Using-Restricted-Groups.html