If you get Group Policy management WRONG – even for just one Windows system with a seemingly innocuous setting, then you can inflict massive detrimental effects to the security posture of thousands of systems in your network within minutes.

With that cold opener, let me say “Welcome Back!” to my National Cyber Security Awareness Month series focusing on Active Directory security guiding principles. Below is the entirety of my series with links to those already published:

Let’s explore.

What are Group Policy Objects?

Active Directory (AD) Group Policy plays a major role in establishing a secure and compliant networking environment because, at its very basic definition, it controls the configuration of computers and what users can and cannot do on them.

Group Policy provides the centralized management and configuration of operating systems, applications and users’ settings in a Microsoft Active Directory environment. A Policy applies its configuration at the most trusted security level in the Windows operating system – even having administrative control over Domain Controllers (DC). Here’s just a short list of what Group Policy does:

  • Enforces a password complexity system that prevents users from choosing an overly simple password
  • Prevents or allows unidentified users from remote computers to connect to a network share
  • Restricts access to certain folders.
  • Installs software
  • Adds accounts to the local administrator groups
  • So much more…

Each set of such configurations is called a Group Policy Object (GPO).

Although GPOs are designed to streamline IT operations and provide centralized security policies across the Active Directory environment, like any other powerful system, they can be abused or infiltrated to circumvent security controls and gain access to sensitive data. Some midsize and large organizations have hundreds and sometimes thousands of GPOs deployed across widely distributed environments, creating not only a huge insider threat, but also a large surface attack area if the proper compensating security controls are not in place. And given the way GPOs propagate changes within minutes (or seconds), reversing the damage is a lot like unbreaking a teacup.

Step 1: Review GPO settings

It’s first important to understand what the GPO’s purpose is: what is the GPO allowing or not allowing to happen on the AD hierarchy to which it is linked. Settings can mandate password policies, startup and shutdown scripts, installing software, setting file and registry permissions (and a lot more).

In order to simplify and create clearer GPOs, each Group Policy should be purpose driven. GPOs should be strictly segregated into “Computer Settings GPOs” and “User Settings GPOs.” Care should be taken to limit enabling “loopback GPOs” which apply user settings but only to users on a certain computer. Limiting the action of the GPO will reduce your attack surface by reducing complexity and the likelihood of errors.

Step 2: Review GPO permission delegation

Permission delegation settings within GPOs is one part of locking down and regularly reviewing your Group Policy Management. An attacker who compromises the account of a user with edit rights to important GPOs could create opportunities for persistence with backdoors, run code, or add the domain account to an RDP group – just to name a few.

The two built-in GPOs – Default Domain Policy and Default Domain Controllers Policy – are often targeted by attackers because they are, by default, in every AD domain with the same GUID and impact EVERYTHING (such as User Rights Assignments, Local Policies/Security Options, Password Policy, Account Lockout Policy, Network Access and Security, etc.). And because there are many rights assigned within these GPOs that have escalation paths to AD admin, an attacker doesn’t need to try and link a malicious GPO when they can just use one of these two defaults!

Regular attestation of GPO permission delegation needs to occur, as well as layering stricter GPOs on top of the defaults to restrict User Rights Assignments and escalation paths for Server Operators, Backup Operators and Print Operators.

Step 3: Review GPO linking

GPOs can be linked within the AD hierarchy such as to the DC, OU, or a site. Determining where a GPO is linked along with understanding that GPO’s permissions will help you understand 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.

Again, regular review of GPO linking is important to reducing your attack surface. GPO best practices recommend linking as close to the intended target as possibly. This approach reduces complexity in 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 controls

Native GPO changes take effect as soon as the window closes – there isn’t even an “apply” button. This is both a security risk and it opens the organization up to simple administrative mistakes that can have devastating impact. Given how important GPOs are to establishing good management and security of your network, you can see start to see the need to monitor and alert on changes to GPOs as well as implement approval-based change controls.

As a best practice, you need to set up an automated process that allows for segregation of duties using approval workflows so that the person who edits a GPO setting is different from the person who approves the deployment of the GPO change into the production environment. It may seem obvious, but it is still something that needs to be formally addressed and implemented. At a minimum, you need to establish and ITIL flow (or an administrative process) coupled with the tools necessary to implement it (such as Quest GPOADmin).

Next steps

Getting GPOs right is critical. If you want to go back to the basics, check out this Microsoft TechNet article, and then check out Microsoft Certified Master, Sean Metcalf’s article on sneaky Group Policy persistence. Also, take a look at Randy Franklin Smith’s keynote at The Experts Conference share his experiences on protecting your AD. 

And if you think no one is really trying to hack into your AD, or you know they are and you’re trying to understand why, then attend the October 30 webcast that explores WHY your role in securing your organization is indeed a matter of national security.

Sources:

  • Photo by Rahul from Pexels.com
  • https://blogs.technet.microsoft.com/musings_of_a_technical_tam/2012/02/13/group-policy-basics-part-1-understanding-the-structure-of-a-group-policy-object/
  • https://adsecurity.org/?p=2716
  • https://www.quest.com/video/protecting-your-ad-with-randy-franklin-smith8140479/

Blog Post CTA Image

Anonymous
Related Content