Well, I have to admit that it’s been a while since I have found something interesting to blog about related to Group Policy. Despite the fact that the technology is still widely used, how much new can you say about something that’s 21+ years old? Well, as many of you know who follow this blog, security is on my mind a lot these days. You only have to follow the tech news casually to know that there are new holes in Windows and AD every month that you can drive a truck through. Many of these, especially around AD, are not necessarily vulnerabilities as new ways to exploit tried and true technology, such as NTLM, Kerberos, etc. Of course Group Policy is no exception to this and I firmly believe that the only reason it’s not exploited more often, is that attackers don’t necessarily understand how it works in all cases. “Security through Obscurity” for the WIN! That said, I do believe there is more that IT shops can do to help protect against the worst that attackers have to offer. The problem with Group Policy is that it is so powerful, that once compromised, you can pretty well kiss your environment good bye. That said, there are some tried and true principles around securing AD that I’ve long thought apply equally well to securing Group Policy. And the first of these is Administrative Tiering.

Admin Tiering Explained

Microsoft first introduced the concept of admin tiering for their platform with a series of whitepapers starting back in 2014 with their “Trustworthy Computing Mitigating Pass-the-Hash and Other Credential Theft, version 2” whitepaper. This document outlined an approach to prevent credential theft by segregating your AD resources into Tiers as follows:

1. Tier 0: Domain Controllers
2. Tier 1: Servers
3. Tier 2: Workstations

The idea was to then restrict which administrative accounts had access to which tiers–who could log in or access remotely, resources in a given tier. The diagram looked like this:

This enforcement was actually done using Group Policy–where user rights assignments were set such that users/groups within a particular Tier did not have rights to access or log into–locally or remotely–machines from different tiers. This original tiering model has recently been replaced by Microsoft with a new model based on Azure security services. And while this new model reflects the modern, hybrid world in which we live, it also adds complexity to what was a relatively easy-to-understand approach. I wrote about this in a blog post on the Semperis website last year.

That said, I think the original tiering model still has value for many AD shops, and, can be applied to controlling access to Group Policy as well.

Delegation of Group Policy

I’ve written extensively on this blog about the various ways that Group Policy can be abused. Frankly, many of these attack paths come down to weak or missing delegation of Group Policy and its management, rather than outright vulnerabilities. We can address those weaknesses by applying the same admin tiering principles to the management of Group Policy. Within Group Policy, there’s two areas that we need to focus on:

• Who can edit GPOs
• Who can link GPOs

The former involves managing the delegation on the GPO itself, as seen here in GPMC, and the latter involves controlling who can make GPOs “live”:

Group Policy provides for a fixed set of permissions that can be delegated onto a GPO. It’s important to keep in mind that these are somewhat artificial permissions, in that under the covers, they get translated into AD object permissions on the AD part of the GPO (GPC or Group Policy Container) and file system permissions on the SYSVOL part of the GPO (GPT or Group Policy Template). This is why, when settings permissions on a GPO, you can’t just set the permissions on the GPC or GPT independently. It has to be done on both, together, in an organized way, using something like GPMC.

That said, in GPMC you can set two different permissions for editing a GPO, including:

• “Edit Settings”
• “Edit Settings, Delete, Modify Security”

The former allows a user to edit the settings on a GPO within GP Editor. The latter is the equivalent of “Full Control” on a GPO and allows a user to edit settings, delete the GPO or modify the delegation on the GPO.

The second interesting Group Policy delegation is linking, or controlling who can link and unlink GPOs. After all, it doesn’t matter who can edit a GPO, if that GPO can’t be linked anywhere. No linking, no processing! Linking delegation is performed on containers that can hold GPO links. This includes the domain object, Organizational Units (OUs) or AD site objects. Linking delegation can also be set via GPMC, but in this case, GPMC is just setting native permissions on AD, specifically the ability to link and unlink a GPO, or set properties on the link such as whether it’s enabled or enforced. This is controlled by granting write permission to an attribute called gplink on these container objects. As I said, you can control linking delegation from AD Users an Computers or via GPMC, as shown here:

Now that we understand the basics of what *can* be controlled in Group Policy, let’s talk about applying admin tiering to Group Policy management.

Admin Tiering of GP Management

The concept of admin tiering of Group Policy management is reasonably straightforward. From my perspective, there are the same three tiers that exist in GP management as in AD/Windows management:

1. Tier 0: GPOs that apply to Domain Controllers
2. Tier 1: GPOs that apply to servers
3. Tier 2: GPOs that apply to workstations

This sounds pretty simple, but there’s some nuances that I need to clarify here. First, let’s talk about Tier 0.

Tier 0

When I talk about GPOs that apply to Domain Controllers, I not only mean the GPOs themselves, but the linking of GPOs to containers that can apply to DCs. It’s all well and good if an attacker can’t edit the Default Domain Controllers policy, but if that same attacker can link an arbitrary GPO that they do have control over, to a container that is processed by DCs, you are in no better shape than had you given the attacker a Domain Admin account. And to be clear, all things being equal (i.e. no security filters or WMI filters in use) Domain Controllers will process GPOs linked at the following levels:

1. At the domain level (which applies to all users and computers in the domain)
2. At the Domain Controllers OU level 
3. At any AD site that contains a DC

What this comes down to are the following rules:

• Only Tier 0 admins should be able to write to the gplink attribute on any of these containers listed above
• Only Tier 0 admins should edit GPOs linked to any of these containers above
• If any new GPO is linked to Tier 0 containers, it’s delegation should be changed such that only Tier 0 Admins can edit it

Let’s take the domain object as an example. Delegating linking to Tier 0 would look like the following in AD Users and Computers:

For GPOs it would be similar–just using GPMC delegation to allow edit permissions on a GPO linked to the domain (e.g. the Default Domain Policy):

Now I realize that you may be reading this and thinking, “But Darren, do you KNOW how many GPOs we have linked at the domain level that are processed by all workstations or users?”. To which I would answer…WHY? But seriously, let’s take the worst case scenario. You have a GPO that is delivering some seemingly benign Admin Template setting to every machine in your domain. So you naturally link it to the domain and call it a day. But as it happens, that GPO is editable by one of your server admins, or worse yet, by a group of server admins. These admins normally have no special rights in the domain above the ability to manage servers. And let’s say one of the members of that group gets compromised by an attacker. The attacker is now Domain Admin, or will be as soon as she realizes that she can write settings into a GPO that is processed by your DCs. I’ve shown this elsewhere but if I control a GPO that is processed by a DC, I can make myself Domain Admin in about 10 seconds. Neat 🙂

Hopefully you can see that regardless of whether it’s controlling linking on containers that are processed by a DC, or controlling GPOs that are linked to those containers, if anyone outside of Tier 0 has this ability, you may as well write a check to your favorite attacker right now.

Tier 1 & Tier 2

Moving up the chain, Tier 1 GPOs and containers are any GPOs and containers that are processed by Windows servers and Tier 2 are containers and GPOs processed by workstations. This starts to get more difficult, because many shops have servers and workstations scattered around their AD structure. In the worst case, they have servers AND workstations in the same OU, and deliver settings to both from a single GPO. This makes tiering of these GPOs and containers very difficult. What I would say here is to try to do your best. In an ideal world, Tier 1 admins are the only ones that can link GPOs to OUs that contain servers, and they are the only ones who can edit those GPOs linked to those containers. Likewise Tier 2 admins are responsible for GPO and container linking for containers that have workstations. There are plenty of ways that attackers can abuse Tier 1 or Tier 2 GPOs or container linking to gain privileged access on these workstation or server resources, and use that to move laterally and escalate privileges across the environment, especially if you are not also using some kind of Admin Tiering for Windows administration. But you have to choose your battles, and for sure, Tier 0 is the first place you should start.

Getting Ahead of the Game

I realize that upon reading this, you might be thinking, “I’m not going to do all of that with my Group Policy environment.” I understand this. Complexity breeds its own problems. This is why I suggest starting with Tier 0 GPO delegation first, and working from there. But believe me, it’s already sickeningly easy for attackers to compromise AD and Windows environments–due in large part to inconsistencies and errors in configuration of these environments. And given the power that GPO gives over a Windows domain–nearly limitless privileged access to all domain resources—you owe it to your sanity to try to stay a little bit ahead of the bad guys and make it a little harder for them to completely pwn your environment. I hope this helps with that!

Darren