Dec 082013
 

Well, we’ve made it through the debug logs for normal mode and merge mode and now it is on to replace mode and time to answer our original question, “In replace mode, when does the user configuration portion of policies which apply to the computer object get applied.  Is it applied when the computer starts up?  Or is it applied when a user logs on?”

This post is part 3 of a 3 part series where we are examining the debug output for each policy processing mode:

  1. Loopback Policy Processing Debug Series – Normal Mode
  2. Loopback Policy Processing Debug Series – Merge Mode
  3. Loopback Policy Processing Debug Series – Replace Mode

Our OU structure still hasn’t changed, but here it is again.  The workstation that we’ll be using, XP01, is in the HR OU.

loopback_1

The user that will be using, John.Galt, is in the Users OU.

loopback_2

Replace Mode

Here is the full text log file: replace_UserEnv.log [171.08 KB] (previously loopbackReplace.log)

At 3:03:07:041 AM, computer policy begins evaluation of workstation XP01.

loopback_3

 

Policy evaluation for the workstation begins in normal mode.

loopback_4

 

 

Policies are enumerated starting with the OU closest to the workstation, then working through the parent OUs, on to site policy, and finally to the local policy.

loopback_5

 

The computer configuration portion of policy is completed at 3:03:12:018 AM.

loopback_6

A few seconds later, the user John Galt logs on to the workstation and at 3:03:30:996, policy processing begins evaluation of user John Galt.

loopback_7

Policy evaluation for the user begins in replacement mode.

loopback_8

This discards the user account policies and reinitiates enumeration of workstation policy, applying the user portion of those policies which apply to the workstation.

loopback_9

The user configuration portion of policy is completed at 3:03:32:189 AM.

loopback_10

The user configuration portion of the policies which apply to the workstation are not applied with the computer configuration portion because the policy engine evaluates the computer portion of policy and the user configuration portion of policy at separate times.  The computer configuration portion is evaluated when a workstation boots.  The user configuration portion of policy is evaluated when a user logs on.  And this is where the state of the loopback policy setting is evaluated as well (which is how the policy engine knows which policy processing mode to enter).

Well, I am tired of looking at log files and I am sure that you are tired of seeing pictures of log files.  In a future loobpack policy processing blog (and hopefully the last for a while) will be a look at how loopback policy processing can go wrong.

792 total views, 33 views today

Dec 052013
 

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.

domain_policy

At this point, it’d be helpful for us to take a look at where our objects live in the OU structure:

user_computer_ou

 

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.

workstation_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.

loopback_auth_users

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.

policy_screensaver

Because loopback policy processing is being restricted with security group filtering, we can leave the default Read and Apply permission on the ScreenSaver15 policy.

sc15

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.

users_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.

workstations_ou

And the workstation has been added to the Loopback group.

workstation_loopback

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:

screen_saver

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.

rsop

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.

73 total views, 1 views today

Dec 042013
 

When it rains it pours I suppose.  Just after I dropped the last loopback policy processing post, I got an email from another friend at Microsoft asking about how replace mode actually works.

What he wanted to know exactly was when does the user configuration portion of policies which apply to the computer object get applied.  Is it applied when the computer starts up?  Or is it applied when a user logs on?

It’s a fair question.  The loopback policy setting is configured in the computer configuration portion of policy so it seems logical that the computer could pick up on the fact that loopback policy is configured in replace mode.  Knowing that user policy won’t be used, it could very well just apply the user configuration portion of applicable policy at startup instead of waiting for a user logon to occur.

So, how does the user configuration portion of policies linked to a computer object’s parents get applied when loopback policy processing is in replace mode?  Well, before we answer that question, let’s actually take a look at debug logging for each of the different modes.  To do this, we are going to set the UserEnvDebugLevel registry value to log verbose output to a log file, userenv.log, as explained in KB221833.  We’ll use the same user and computer account for each of the policy application modes, normal, merge mode, and replace mode.

Originally I intended for this to all go into a single post but it just started to get too big so I am now separating these out into a 3 part series.  This is part 1 of the 3 part series:

  1. Loopback Policy Processing Debug Series – Normal Mode
  2. Loopback Policy Processing Debug Series – Merge Mode
  3. Loopback Policy Processing Debug Series – Replace Mode

Besides the images in the walkthrough, I have included the log files for each of the policy modes.  The final post will have the explanation of when the policy engine applies the user configuration portion of policy in replace mode and why it does it when it does.  At the end of each post is a consolidated UserEnv log which includes snippets of each of the modes.

First, here is what our OU structure looks like.  The workstation that we’ll be using, XP01, is in the HR OU.

ouStructureWorkstation

The user that we’ll be using, John Galt, is in the Users OU.

ouStructureUser

Normal Mode

One last thing, the captures in these posts are limited to what is needed to compare between the different modes of policy processing.  That is, if we were looking at debugging policy processing in normal mode by itself, we would want to capture quite a bit more than what is below (like the deferred evaluation of GPOs, CSE processing, etc).

Here is the full text log file: normal_UserEnv.log [165.5 KB] (previously noLoopback.log)

Here is the consolidated log file: consolidated_UserEnv.log [15.93 KB]

Not long after the workstation is booted, at 2:54:14:195 AM, (yea, that’s pretty precise), computer policy begins evaluation of workstation XP01.

normalWorkstationEnter_2

Policy evaluation for the workstation begins in normal mode.

normalWorkstationMode_2

Policies are enumerated starting with the OU closest to the workstation, then working through the parent OUs, on to site policy, and finally to the local policy.

normalWorkstationGPOEnumeration_2

The computer configuration portion of policy is completed at 2:54:19:232 AM.

normalWorkstationComplete

A few seconds later, the user John Galt logs on to the workstation and at 2:54:38:098 AM, policy processing begins evaluation of user John Galt.

normalUserEnter_2

Policy evaluation for the user begins in normal mode.

normalUserMode_2

Policies are enumerated starting with the OU closest to the user, then working through the parent OUs, on to site policy, and finally to the local policy.

normalUserGPOEnumeration_2

The user configuration portion of policy is completed at 2:54:40:359 AM.

normalUserComplete

This is the standard process that we see with our users and workstations on a daily basis.  For each object, the computer or user, the policy set is built, starting with the OU closest to the user and working all the way to the domain head, on to site policies, and finally to local policy.  Then the appropriate portion (computer configuration for workstations and user configuration for users) of policies are applied in reverse order of enumeration, starting with the local policy, then to site policy, then the domain head, and on down through the OU structure until it gets to the nearest parent of the object itself.  This allows the closest policy settings to win.

More advanced versions of normal policy processing would include the use of settings like Enforced, Block Inheritance, Security Group Filtering, WMI Filtering,  and Item-Level Targeting.  For this illustration though, we are keeping it as simple as possible and assuming that none of these are configured.

In part 2, Loopback Policy Processing Debug Series – Merge Mode, we’ll see how policy processing works in merge mode.

 

 

454 total views, 1 views today

Dec 042013
 

This post is part 2 of a 3 part series where we are examining the debug output for each policy processing mode:

  1. Loopback Policy Processing Debug Series – Normal Mode
  2. Loopback Policy Processing Debug Series – Merge Mode
  3. Loopback Policy Processing Debug Series – Replace Mode

In our last post, we reviewed the UserEnv log to see how policy is applied to workstations and users under normal circumstances.  In normal mode, processing of workstation group policy restricts itself to those settings configured in the computer configuration node of applicable policies and user group policy restricts itself to those settings configured in the user configuration node of applicable policies.

Now things are going to change a little bit with the introduction of loopback policy processing in merge mode.  Our OU structure has not changed, but so you don’t have to go look at previous posts I have included it here.  The workstation that we’ll be using, XP01, is in the HR OU.

ouStructureWorkstation3

The user that will be using, John.Galt, is in the Users OU.

ouStructureUser4

Merge Mode

Here is the full text log file: merge_UserEnv.log [171.92 KB] (previously loopbackMerge.log)

Here is the consolidated log file: consolidated_UserEnv.log [15.93 KB]

At 2:47:02:753 AM, computer policy begins evaluation of workstation XP01.

mergeWorkstationEnter_2

Policy evaluation for the workstation begins in normal mode.

mergeWorkstationMode_2

Policies are enumerated starting with the OU closest to the workstation, then working through the parent OUs, on to site policy, and finally to the local policy.

mergeWorkstationEnumerateGPOs_2

The computer configuration portion of policy is completed at 2:47:02:993 AM.

mergeWorkstationComplete

A few seconds later, the user John Galt logs on to the workstation and at 2:54:38:098 AM, user policy processing begins evaluation of user John Galt.

mergeUserEnter_2

Policy evaluation for the user begins in merge mode.

mergeUserMode_2

Policies are enumerated starting with the OU closest to the user, then working through the parent OUs, on to site policy, and finally to the local policy.

mergeUserEnumerateGPOs_2

Once both lists are defined, they are merged together.  Settings configured in the user portion of policies linked to the workstation’s parents apply last.

mergeUserComputerMergingTogether_2

The user configuration portion of policy is completed at 02:47:29:824 AM.

mergeUserComplete

Policy application has completed successfully and any user configuration settings which were applied to policies which are applicable to XP01 have overwritten those policy settings which applied to John.Galt.  The initial evaluation of XP01 evaluated the GPOs which applied but then only applied those settings in the computer configuration node of the applicable policies.  When John.Galt logged on, then the user policy processing engine evaluated the applicable policies for John.Galt and XP01, applying only the policy settings in the user configuration node.

This process is very similar to what we saw in Loopback Policy Processing Debug Series – Normal Mode except with the additional evaluation of the user configuration policies for the workstation after evaluation of the user policy settings.

In part 3, Loopback Policy Processing Debug Series – Replace Mode, we’ll get far away from normal and see how policy processing works in replace mode.

394 total views, 4 views today