Group Policy is a critical element of any Microsoft Active Directory (AD) environment. But exactly what is it and how does it work? How can attackers compromise it, and how can you defend yourself? Here are all the essential things you need to know.
Group Policy overview
Group Policy is an integral feature built into Microsoft Active Directory. Its core purpose is to enable IT administrators to centrally manage users and computers across an AD domain. This includes both business users and privileged users like IT admins, and workstations, servers, domain controllers (DCs) and other machines.
Here are just a few examples of the many useful things you can do with it:
- Establish and enforce password policies, such as password length and complexity requirements, to help thwart password-guessing attacks.
- Prevent the use of removable media drives, which are a vector for both malware infections and data theft.
- Restrict access to the command prompt, so users can’t run unauthorized code that could compromise the integrity or stability of their machines or infect your network.
- Deploy operating systems and other software to all Windows Server machines and other computers to ensure a standard environment across the domain.
- Block users from installing new software on their systems to avoid security, productivity and licensing issues.
- Add frequently used or recommended sites to users’ browsers, enhancing productivity and helping to ensure they work with accurate information.
- Disable NTLM authentication, which is weaker than the more modern Kerberos authentication.
- Prevent Windows from storing LM password hashes, which are fairly easy to hack.
- Keep users from creating PST files, which can be a backup, compliance and e-discovery nightmare.
- Run certain scripts on computer startup or shutdown or user login or logout, such as a script that performs cleanup before computer shutdown or launches an essential business application at user login.
As you can see, Group Policy is incredibly powerful and can deliver enormous value. In particular, it enables organizations to strengthen security, enhance IT efficiency and business productivity, and reduce downtime and costs. However, as we’ll see in a moment, it can also be a giant vulnerability if it’s not managed properly.
Diving into the details: GPOs
Now let’s explore how Group Policy actually works. It is comprised of a set of policies, called Group Policy objects (GPOs). The examples listed above are just some of the most common GPOs you can set up to support IT best practices. Microsoft offers literally thousands of policies and settings you can use, which are detailed in its Reference Spreadsheet.
Two GPOs are created automatically when an AD domain is created:
- Default Domain Policy — Establishes baseline settings for all users and computers in a domain in three key areas: password policy, account lockout policy and Kerberos policy.
- Default Domain Controllers Policy — Establishes baseline security and auditing settings for all domain controllers in a domain.
To take effect, a GPO needs to be applied (linked) to one or more Active Directory containers, such as a site, domain or organizational unit (OU). For instance, you can use Group Policy to require all users in your Chicago domain to use more complex passwords, or to disallow the use of removable media on all computers in just the Finance OU of the Chicago domain.
Even though most organizations use only a small subset of the policies that Microsoft provides, they can easily end up with hundreds or thousands of GPOs implemented over the years to granularly control various aspects of their IT environment.
GPO processing (TL;DR: Things can get complicated quickly)
A GPO has no effect until it is linked to an Active Directory container, such as a site, domain or OU. Linking GPOs to containers enables you to apply settings to a broad or narrow portion of the IT environment.
However, it’s not a simple one-to-one pairing. Any given GPO can be linked to multiple containers, and, conversely, any given container can have multiple GPOs linked to it. Plus, containers inherit GPOs — for example, a GPO that is linked to an OU applies to all users and computers in its child OUs. Similarly, a GPO applied to an OU applies not just to all users and computers in that OU, but by inheritance, to all users and computers in child OUs as well. What’s more, you can even link a site, domain or OU to a GPO in another trusted domain. (This is not recommended, but it is possible!)
If that’s not confusing enough, the settings of various GPOs can overlap or even conflict. By default, GPOs are processed in the following order, with later ones overriding the settings of earlier ones:
- Local (individual computer)
- Site
- Domain
- Organizational unit
However, you can step in and manage how GPOs are applied to a specific domain, site or OU by doing any of the following:
- Changing the link order — The GPO with the lowest link order is processed last and therefore has the highest precedence, overwriting settings in the earlier GPOs if there are conflicts.
- Blocking inheritance — By default, child OUs inherit all GPOs from the parent, but you can block this inheritance.
- Enforcing a GPO link — By default, the settings for parent OUs are overwritten by any conflicting settings in GPOs linked to child OUs, but you override this behavior by setting a GPO link to Enforced.
- Disabling a GPO link — By default, processing is enabled for all GPO links. But you can prevent the application of a GPO for a particular container by disabling the GPO link for that container.
With all this complexity, it can be extremely difficult to understand what policies are actually being applied to a particular user or computer, which is known as the Resultant Set of Policy (RSoP). Microsoft offers a command-line tool called GPResult that will generate a RSoP report. (Note that the older rsop.msc tool is deprecated.)
Group Policy management and delegation
For Group Policy management, Microsoft provides the Group Policy Management Console (GPMC). Using this free Group Policy editor, IT admins can create, copy, import, back up and restore, and report on GPOs. Microsoft also offers a whole set of GPMC interfaces that can be used to programmatically access many of the operations supported by the console.
By default, any member of the Administrators group for a domain can create and control GPOs. In addition, there’s a global group called Group Policy Creator Owners; its members can create GPOs, but they can modify only the policies they have created unless they are specifically granted permissions to edit other GPOs.
In addition, you can delegate permissions for various tasks, such as creating, editing and linking specific GPOs, to additional IT admins. Delegation is a valuable tool; for example, it probably makes perfect sense to empower the team responsible for managing your Microsoft Office applications to edit the GPOs used to manage Office settings on the desktop.
However, delegation often gets out of hand quickly; before you realize it, you’ve got dozens and dozens of people with various GPO management rights. Plus, those rights are often delegated at the domain level, so the person can monkey with not just one or two GPOs but all GPOs for the domain — even those that apply to your domain controllers (the heart and brains of the domain) or to the entire domain (everything).
Big power, big risk
The value of Group Policy comes from its power. At a stroke, you can enforce policies across a domain or an OU that dramatically strengthen security or improve business productivity.
But that power can also be misused, either deliberately or accidentally. Indeed, a single improper change to a GPO could lead to downtime or a security breach. Remember all the examples I gave earlier of the great things you can do with GPOs? It’s easy to turn them around to see how they could be co-opted by an attacker. For instance, a hacker or malicious admin could modify a GPO to:
- Allow unlimited attempts to guess an account password.
- Enable the use of removable media drives for easy data theft.
- Deploy malware to all machines across the domain.
- Replace the sites listed in users’ browsers with malicious URLs.
- Run a malicious script on computer startup or shutdown.
Moreover, hackers don’t even need a lot of skill to compromise your GPOs. All they need to do is take over an account that has the requisite permissions to the desired GPO — and there’s an open-source tool called BloodHound that will hand them a list of those accounts. A few spear phishing attacks, and the hacker is in control of the GPO. (The two GPOs I mentioned earlier, Default Domain Policy and Default Domain Controllers Policy, are popular targets because they are created automatically for every domain and they control important settings.)
Why native tools fall short
Unfortunately, native tools don’t make it easy to keep Group Policy safe and under control. For one thing, changes made to GPOs natively take effect as soon as the window closes — there isn’t even an “Apply” button that gives admins a chance to pause and catch mistakes before the organization suffers a devastating impact.
Reduce your AD attack surface.
Moreover, because of the way security permissions are designed around GPOs, any domain admin can modify any GPO security setting — even the settings that are supposed to prevent that person from doing certain tasks. For example, an admin could disable the GPO that prevents them from logging on to a particular server that hosts sensitive data and copy some or all of that valuable content to their own machine.
What’s worse, GPO setting changes are not tracked in native security logs, let alone alerted on, so it’s not possible to monitor for such violations, even if you are using a security information and event management (SIEM) solution.
Keys to defending your Group Policy
The best way to minimize the risk of your GPOs being improperly handled in the first place while maximizing your ability to spot malicious behavior promptly, is to build a layered security framework that supplements the native tools. Specifically, to protect your Group Policy, you need proven solutions that enable you to:
- Understand exactly who has what access to which GPOs
- Implement approval-based workflows with appropriate segregation of duties to control changes to GPOs
- Track, monitor and alert on changes to GPOs
- Prevent changes to your most important GPO settings
- Quickly revert unwanted changes to GPOs
In addition to these essential layers, consider eliminating native delegation entirely and register your GPOs in a proxy-based administration tool. You’ll no longer have dozens of admins with the ability to deliberately or accidentally make improper changes to your GPOs — and any hacker who manages to steal an admin’s credentials still won’t be able to alter your Group Policy.
