I wanted to follow-up on a previous post and respond to a newsgroup post with this loopback policy processing model. I am taking the inspiration for this from the newsgroup post though there is some deviation for the sake of the illustration. Okay, let’s go.
In our globally-applied Default Domain Policy, a screen saver timeout is set to 30 minutes. Right now, this is the only screen saver timeout policy in the domain. This policy setting exists in the User Configuration portion of the Default Domain Policy so it typically is consumed only during user policy application.
At this point, it’d be helpful for us to take a look at where our objects live in the OU structure:
While in many cases this global screen saver timeout may be acceptable, specific business units have now decided that they want to be able to control the screen saver timeout on their computers, regardless of the user that logs on. Right now, only the HR business unit knows what they want that timeout value to be, however, the two other business units are looking to follow suit and are currently working to figure that out.
In order to accomplish this we are going to need to use loopback policy processing to force user policy settings to apply to our workstations. Because we still want to apply other relevant user settings configured in policies throughout the domain, we are going to enable loopback policy processing in merge mode.
Since the other business units will soon be adopting the screen saver timeout by machine as well, we are going to configure loopback policy processing at the parent Workstations OU.
Though it is anticipated that this will apply to all organizational workstations, we have been asked if we could control which machines get this for now. To accomplish this, we have created a group called Loopback and we will filter the application of the policy using security group filtering by removing the Read and Apply permission from Authenticated Users and granting those permissions to the Loopback group.
Each business unit will have a unique screen saver timeout policy configured and linked to their OU. Since the HR business unit knows what they want that to be, we are going to create and configure that policy with the 15 minute timeout as they have requested. And this is where it gets a little confusing.
We know that the screen saver timeout policy setting is configured in the User Configuration of group policy which typically is applied to users. However, since we are using loopback policy processing we are going to configure the screen saver timeout policy in the User Configuration of our new ScreenSaver15 policy but link it to the OU where our computers reside.
Because loopback policy processing is being restricted with security group filtering, we can leave the default Read and Apply permission on the ScreenSaver15 policy.
So, if we’ve configured it correctly, the effective screen saver timeout setting for any user that logs on to an HR resource will get the 15 minute screen saver timeout instead of the 30 minute timeout. Let’s make sure that it’s working.
The user account that we are going to log on with is named John.Galt and it is located in the Users sub-OU of the Accounts OU.
The computer account that we are going to log on to is named XP01 and it is located in the HR OU under the Workstations OU.
And the workstation has been added to the Loopback group.
Now let’s log on and make sure it’s working. Logging on to the XP01 workstation with the user John.Galt yields the 15 minute screen saver timeout. We can see that through the display properties on the workstation:
By running a resultant set of policy (RSoP) on the machine we can see this setting came from the ScreenSaver15 policy which is linked to the HR OU. The HR OU contains only computer accounts.
And now we can breathe a sigh of relief! We got the policies configured with the end state that we were looking for.
But let’s step out of our lab world for a second though and talk about this because loopback policy processing is not all sunshine and roses.
A couple of things I want to point out. First, the loopback policy setting can be applied to a machine through any applicable computer policy. Second, once that setting is applied, it impacts all applicable computer policies regardless of whether those policies also have the loopback policy setting configured or not. Additionally, though it didn’t come through in our walkthrough, this can create very frustrating conditions where a policy setting which we want to apply to users is now being overwritten by a conflicting policy which is linked to a parent of the computer object. For instance, with loopback policy processing enabled, the screen saver timeout policy in the Default Domain Policy was actually applied again but was overwritten by the ScreenSaver15 policy which is linked to a parent closer to our computer. You can see that in the Demystifying Loopback Policy Processing blog post. And we haven’t even begun to consider how setting a policy to Enforced or configuring an OU to Block Inheritance.
In a future post I am going to walk through how loopback policy processing can go wrong.