Group Policy Mechanics – A Deep Dive

Group Policy MechanicsDid you ever want to know how Group Policy really works behind the scenes, such as how Active Directory knows that a GPO is linked up to a particular OU or how it connects up to the files in Sysvol? If you do then this is the post for you.

Why is it useful to understand the deep dive mechanics?

Two reasons:

  1. Troubleshooting – if you understand how something works then you’re more likely to be able to fix it
  2. You’re a geek! – I mean that in a nice way. If you’re really into this stuff and want to expand your knowledge and make yourself stand out from your colleagues, then this extra bit of knowledge can help.

The Key Elements of Group Policy

The Group Policy Object (GPO)

The GPO has two main parts:

  • Settings
  • Metadata

Settings:

The settings are the actual, well settings that you configure within the GPO. These are divided into either Computer or User settings.

Each GPO in the domain has it’s own folder in Sysvol and the settings for the GPO are stored under that. The name of the folder isn’t the friendly GPO name i.e. “Desktop Lockdown Policy” but rather Active Directory uses the GUIDs to identify it. Sysvol is sync’d around all domain controllers within the domain using either the older NTFRS service or hopefully the newer DFSR. This means you have access to your GPOs no matter which DC authenticates you.

Sysvol

The default GPOs have the same GUIDs each time, for example the following well known GUID starting with {31B2F340-…is always the Default Domain Policy:

GPO GUID Names

Metadata:

The metadata is the stuff stored in the AD database itself (NTDS.DIT) and contains all the information about the GPO such as where it’s linked, it’s name, security permissions etc. Pretty much all of the GPO related stuff except the settings which are the Sysvol files.

How it’s linked up

Now we understand the two main parts of Group Policy (Settings and Metadata) let’s see how it’s all linked up, starting with the metadata.

Viewing the GPO Metadata

To view the metadata for a particularly GPO we need to look at AD itself. We’re going to explorer a couple of different tools starting with Active Directory Users and Computers and then use LDP which will give us a different view of the same information.

Active Directory Users and Computers (dsa.msc)

  1. Open AD Users and Computers
  2. Click on the View menu
  3. Enabled Advanced Features (this enables more information to be viewed such as the System container)

DSA.MSC

Now if you scroll down to /System/Properties and right-click on one of the GPOs (GUIDs), then go to the Attribute Editor tab, you’ll be able to scroll down as see the various pieces of metadata for that GPO. This includes the displayName, location in Sysvol which is the gPCFileSysPath attribute and many others.

AD User Group Policy Propertiesldp.exe

LDP is another tool present on domain controllers that can be used to view the Active Directory structure. I tend to prefer this simply as it gives you all the attributes on one screen.

To use this:

  1. On a domain controller go Start / Run and type ldp.exe. Click on Connection, then click OK (leave the Server field blank and it will bind to the computer you’re on, assuming it’s a DC)
  2. Now click on Connection again, then click Bind and select Ok to bind on as the currently logged on user

LDP

4.  Now select View, Tree and a the BaseDN dialog hit enter click OK (leaving the field blank which means it will bind to the BaseDN which is what we want.)

LDP Bind

5. Now just like you did in AD Users and Computers, double-click on System… / Policies… and one of the GPO GUIDs. This will display all the attributes on the right

TIP: Right-click on the right hand pane and select Clear Output to clear the screen

LDP Group Policy Output

Linking the GPO Metadata <-> Organisation Units

For a GPO to apply it must be linked to either a Site, Domain or Organizational Unit. (SDOU) . This is done via the gPLink attribute located on the SDOU.

If you double-click on the Domain Controllers OU you’ll see the attributes for that OU. On the right you can see the gPLink attribute which references the all the GPOs that are linked here. In this case it’s the GPO starting {6AC1788C…} which is the Default Domain Controllers GPO.

gPLink AttributeIf you click on the Site or Domain objects you’ll see the same gPLink attributes. Note that you can have multiple GPOs referenced here as you can have multiples GPOs linked to the same SDOU.

Linking GPO Metadata to Sysvol Settings

So now we know how the GPOs are linked to the OUs etc. Now what about the settings in Sysvol?

Going back to the GPO we can see there is a gPCFileSysPath attribute which tells the GPO where the settings are stored in Sysvol as a UNC path

Sysvol GPO
Client Processing

On the client computer (or server) processing the Group Policy there is a Group Policy Client service. It’s this client that queries AD for the information above and based on the results knows which GPO settings it needs to apply. Each setting will fall under one of the Client Side Extensions (CSEs) which are the pieces of code that actually do the work on the client and makes the settings take effect.

Summary

  1. So the Site, Domain or OUs know which GPOs are linked to them via the gPLink attribute. The gPLink attribute points to the DN path of the GPO
  2. The GPO uses the gPCFileSysPath to know where the GPO settings are stored in Sysvol.
  3. The Group Policy Client service queries the above to figure out what it needs to process
  4. The Client Side Extensions (CSE) on the client computer (or server) then do the actual processing.

Check out my video on Pluralsight

If you want to see this in more detail then check out my Group Policy: Troubleshooting video on Pluralsight where I go into more detail on the Group Policy Mechanics.

Leave a Reply

Your email address will not be published. Required fields are marked *