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:
- Loopback Policy Processing Debug Series – Normal Mode
- Loopback Policy Processing Debug Series – Merge Mode
- 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.
The user that we’ll be using, John Galt, is in the Users OU.
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.
Policy evaluation for the workstation begins in normal mode.
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.
The computer configuration portion of policy is completed at 2:54:19:232 AM.
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.
Policy evaluation for the user begins in normal mode.
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.
The user configuration portion of policy is completed at 2:54:40:359 AM.
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.