Just how critical is Group Policy?

Well, what might happen if your lockout policy got changed and hackers were allowed unlimited attempts to guess a user’s password? What if the predefined bookmarks on all your users’ machines were redirected to malicious sites? What if malware got pushed out onto all your domain controllers?

All it would take to make these nightmares come real is a single bad setting in your Group Policy. Truly, it is not hyperbole to say that one improper change to one setting — intentional or accidental — could easily lead to a data breach, with all the attendant expenses, bad PR, compliance fines and lasting damage to your organization’s reputation.

Even though effective Group Policy management is critical to strong Active Directory security, it is sorely overlooked at many organizations. If that’s true at your company, check out this four-step plan for getting things under control.

Quick review of the power of Group Policy

Group Policy enables centralized management of users and computers in any Microsoft Active Directory environment. Each group of related settings is called a Group Policy object (GPO). Here are just a few examples of the literally thousands of useful things you can do with them:

  • Prevent users from choosing overly simple passwords.
  • Lock an account after a certain number of incorrect passwords are entered.
  • Block unidentified users on remote computers from connecting to a network share.
  • Give all business users a standard set of bookmarks so they can easily reach your helpdesk or access other important resources.
  • Restrict access to certain folders.
  • Install the same software on all of your domain controllers (DCs).
  • Disable the command prompt on users’ machines.
  • Ensure Windows updates are applied promptly.

It doesn’t take a great deal of imagination to see how Group Policy objects can be abused to circumvent security controls and gain access to sensitive data. All you need to do is think of the reverse of each of these policies, as I did in my examples at the top of this blog post. Given the way GPOs propagate changes within minutes (or even seconds), reversing the damage is a lot like unbreaking a teacup.

Clearly, it’s critical to keep Group Policy management and your GPOs under tight control. Here are the four steps involved.

Step 1: Review all GPO settings.

The first step is to get a clear understanding of your current position. Taking stock of your GPOs can be a challenge, though; some midsize and large organizations have hundreds and sometimes thousands of them deployed across widely distributed environments. Still, it’s essential to understand the intent and effect of each GPO — what is it allowing or not allowing to happen in your IT ecosystem? GPO settings can control password policies, startup and shutdown scripts, installing software, file and registry permissions, and a lot more.

As a best practice, GPOs should be purpose driven. They should be strictly segregated into “Computer Settings GPOs” and “User Settings GPOs.” Care should be taken to avoid having GPOs that apply user settings only to users on certain computers. By establishing a clear and well-structured Group Policy, you reduce both your attack surface and the likelihood of errors.

Step 2: Review delegation of GPO permissions.

Next, you need to understand who has the ability to create, modify and delete GPOs in your environment. For starters, that includes all Domain Admins and Enterprise Admins. But most organizations delegate GPO permissions to many other admins as well. For example, it can make sense to enable your server team to manage certain GPOs and your desktop team to control others.

However, delegation brings risk. Any admin could make improper changes to the GPOs they have permissions to modify, either deliberately or accidentally. And an attacker who compromises the account of one of those admins could create backdoors, run malicious code, or add the domain account to an RDP group — just to name a few of their options.

To stay in control of which accounts can modify your Group Policy, you need to implement regular attestation of GPO permissions delegation.

In addition, it’s important to limit permissions to the two built-in GPOs, Default Domain Policy and Default Domain Controllers Policy. They are often targeted by attackers because they are, by default, in every AD domain using the exact same GUID and they impact EVERYTHING — user rights, local security settings, password policy, account lockout policy, network access and security, and more. Because there are many rights assigned within these GPOs, an attacker doesn’t need to try to link a malicious GPO; they can just use one of these two existing GPOs. That’s why it’s a best practice to layer stricter GPOs on top of these default GPOs, so you can limit escalation paths for admins such as Server Operators, Backup Operators and Print Operators.

Step 3: Review GPO linking.

A GPO has no effect until it is linked to an Active Directory container, such as a site, domain or organizational unit (OU). Determining exactly where a GPO is essential to understanding the impact of the policy. For example, if a hacker compromises the account of a GPO creator for a GPO linked to a DC, then that attacker now owns that DC and can create and modify GPOs to allow the installation of malware.

By regularly reviewing GPO linking, you can reduce your attack surface. Best practices recommend linking as close to the intended target as possible. This approach reduces complexity in Group Policy management, limits the impact of accidental or malicious changes, and it reduces latency by removing the need for each client to filter through a bunch of GPOs to determine which ones apply.

Step 4: Implement approval-based change control.

Native GPO changes take effect as soon as the window closes — there isn’t even an “Apply” button. This is a security risk and also leaves organizations vulnerable to simple administrative mistakes that can have devastating impact. Therefore, it’s critical to implement an approval-based change control process.

Specifically, you need to set up an automated approval workflow that allows for segregation of duties — the person who actually edits a GPO setting should be different from the person who approves the deployment of the GPO change into the production environment. It may seem obvious, but it is something that needs to be formally addressed and implemented.

Further insight 

Getting GPOs and Group Policy management right is critical. To help, Microsoft offers the Group Policy Management Console (GPMC), a free Group Policy editor that assists with a variety of tasks, as well as a set of GPMC interfaces for programmatic access to many operations. However, these native tools have their limitations. A third-party solution like Quest GPOADmin can make Group Policy management much easier and more effective.

If you want to go back to the basics, reference our earlier post What is Group Policy and How Do GPOs Work. More specifics on Group Policy management can be found in this Microsoft TechNet article. For further detail, read this post about sneaky Group Policy persistence from Microsoft Certified Master Sean Metcalf, or watch Randy Franklin Smith’s keynote from The Experts Conference in which he share his expertise on protecting Active Directory.

Related Content