Hello, We did the Premier Microsoft AD Security review recently and got dinged on having too many users in the Group Policy Creator Owners group; we have a lot of OU administrators at our organization and they need to have the ability to create, manage and link group policy to their respective OUs. The PFE said that AGPM would allow us to remediate this, and I’m almost certain he said that we’d be able to delegate GPO creation to a group for an OU (or he implied as such). I’ve been going through the documentation and all I see are instructions for delegating permissions to manage specific GPO objects. Is it possible with AGPM (or GPMC) to delegate creation of GPOs to a group for an OU? TL;DR: Large Group Policy Creator Owners membership = bad. AGPM fixes by allowing (among other things) delegating create GPO to group for OU. CJD
Can AGPM Delegate Create GPO Permissions to an OU?
- 247 Views
- Last Post 15 November 2018
Do a search for read and write gplink. Those are the permissions you need to delegate to a group per OU for them to be able to link a GPO.
Smita Carneiro GCWN, CISSP
Consultant – Active Directory
Eli Lilly and Company
Carneiro_smita@xxxxxxxxxxxxxxxx|Web : http://www.lilly.com
Why is it a security issue if they don’t have the ability to link the GPO to more impactful locations like the domain root? Put differently, if they can create 1000 GPOs but only link them to their OU, then what’s the big deal?
Seems like a bogus ticky/tacky issue to me.
I could make an argument that there’s a DDoS risk since someone who can create a GPO can write to Sysvol and they could fill the drive hosting it up, which most of the time
hosts the DIT, which would cause a service outage.
That aside it’s a governance issue IMO.
Thanks Smita, but I’m looking for the ability to delegate the
creation of GPOs to an OU.
I believe it was initially flagged because Group Policy Creator Owners is a “sensitive” group, security-wise.
I didn’t record the session so I don’t have what was said verbatim but “interesting attack vectors using GPOs” was mentioned as a reason to restrict membership
in that group.
I’m guessing that a) delegating Create GPOs to a group for an OU is not possible and b) membership in Group Policy Creator Owners isn’t an issue provided said
members can only create and link GPOs in their own OUs; would that be a fair assumption?
GPOs are stored centrally so there’s no construct of delegating create GPO for an OU. You can however delegate who can link GPOs to an OU. That’s the gpLink and gpOptions
attributes mentioned down the thread.
If you can create/manage GPOs in an OU with users/machines in it, it’s fair to assume that you can own those accounts and go from there. I don’t think that’s an issue for
you if you have appropriate privileged access processes in place, though.
Brian’s right, there’s no easy way to delegate who can create GPOs based on an OU. You can of course, modify the schema defaultSecurityDescriptor attribute on the groupPolicyContainer class to add/remove principals who can create GPOs in
the domain, so if you had a group that you could reliably control as a proxy for OU management, then you could add that group the defaultSecurityDescriptor, and those folks could create GPOs in the domain (again, the whole domain), and then you can manage
the linking using write perms on GPLink. But it’s imperfect to what you’re after.
Within AD, there’s no good way to give the ability to create GPOs without Group Policy Creator Owners. I looked deeply into that back in 2008 … and I vaguely recall a MS article (probably a KB) which suggested a specific way to do that,
but when I tried that possible solution, it didn’t work. I don’t recall all the details, but I might have notes on it somewhere.
I’ve pulled up an identical topical thread from the windows-hied mailing list from April 2011. Here is a summary of points brought up on that thread:
-Worries that GPOs created by GPCOs would inherit edit perms for all members of GPCOs. Those worries are unfounded—the defaultSecurityDescriptor on the AD GP object does not include GPCO and the owner is the specific user who created the
-Worries about Sysvol filling and creating a DDoS. Someone said they used quotas on sysvol to prevent this from happening. I haven’t done this myself, but if one was worried about this issue, then there’s a solution.
-Someone noted there used to be a significant security problem with GPCO—with Windows 2000 & 2003, members could edit the default domain & default domain controller GPOs.
Here you go..
Thanks Pawan…not quite what I was looking for but I’ll keep those links in mind.
Thanks for pulling all of this together Brian; I’ll add this to the ADS report generated by the Premier engagement and forward it to our TAM.
IMHO, if you’re starting to worry about issues at this level of granularity, you need a proper PAM solution (both a preventative control that records who is requesting access, and a detective control
– your SIEM – that’s recording changes). Trying to configure this solely within AD via ACLs is really hard (if not impossible) if only because you’ll be perpetually chasing your tail around the next permission (at the directory or OS level) that allows someone
to subvert all your controls.
Hi,I have always worked with highly delegated (multi-tennant) active-directories and there is a rather simple solution to this issue.Have a domain admin (or central GPCO) pre-provision GPO objects for each “customer” and preconfigure their security correct at creation time. In the early days, before the GPMC, it was considered a good practice to create a reference GPO OU, that contains nothing but that links to each GPO, mostly to not lose track of your existing GPOS, but also show them in a single location (as the GPMC does now). In later iterations, you can create multi-leveled GPO OUs and create the illusion of inherited permissions. So you put a GPO OU in each customers OU, provision 50 empty GPOs on it with correct security, delegated to the customers admin and you are done.If they are about to run out, log a ticket and ask for more. Your worry that a malevolent admin would fill up your sysvol share volume is valid, but if someone wants to do this, they don’t need GPCO for that.GPO object permissions are applied on the GPOs folder in the sysvol share to allow you to eidt .pol files and put powershell scripts etc in the GPO folder, so if you have a single policy delegated to you, you can dump 50 GB of files into that policy folder. Structurally, you can handle this by monitoring disk usage on the volumes on the servers, which should already be in place, and if you really are worried about this, you can indeed put the sysvol on a separate volume or put some kind of quotas in place. I wouldn’t consider this “chasing after your tail”. If you really understand the technology and what it does, put on your evil hat, then your idiot hat and then your admin hat, rinse and repeat. Decide which risks are worth the effort and which are not and you are done. What you shouldn’t do is put all your faith in an off-the-shelf tool that will take the all the delegation out of your hands and manipulate AD with generic credentials on your behalf, but that’s just my opinion :-) Best regards,DavyP
To be clear, I’m not discounting what can be done natively.
However, to do that effectively, you need to build a system specific threat model, weigh countermeasures, and then continually refine that (what you call “the evil hat, idiot hat, admin hat” – what
I call “continuously chasing your tail”). IMHO There is something to be said for having an overlay of independent tools that provide preventative/detective controls that are threat agnostic, so that even if you miss a specific threat or configuration, you
still have some kind of security control in place (PAM doesn’t necessarily mean “generic credentials” – many PAM tools offer enforced session recording – so you have a way of tracing all actions).
If your entire environment runs off AD, then you can probably invest the money to have the right AD people running it. If you’re in the typical enterprise I’ve been in, then you have a multitude
of “run time access control systems” and you simply can’t always have the right people running every single thing. Even “pre creating GPOs with the right security context” means being continually aware of all relevant organisational changes within the org,
so that you know what the “right security context is”. That’s almost impossible in every large environment I’ve worked in.
Not including domain admins, we have 343 users across 154 delegated OUs with Group Policy Creator Owner. The numbers have steadily grown from 2008. As I’ve mentioned previously on this thread, the ability to create a GPO doesn’t mean you
can link it anywhere—that’s a separate permission.
We have documentation that spells out expectations about naming, not linking to someone else’s GPO, and delegating GPOs you create to your OU’s _gpadmins group.
We’ve never seen a DDoS on SysVol. Frankly, for DDoS, I’m more worried about delegated group management (stick a DC in enough groups -> token bloat for that DC).
We rarely need to intervene on administration of GPOs. Across 10 years, the cases have been:
-MS14-025: We actively identified any GPO which was storing passwords and required mitigation
-ReACLing for occasional cases of “I can’t administrate GPO X because Joe left and he was the only one with permissions”
-Renaming a few errantly named GPOs and reminding the offenders to follow the expectations (which is easily accomplished by reviewing the creator owner)
-I inherited my OU (they never tell us this) and don’t understand why:
+X can log into my computers (IOW, they don’t understand basic Windows user rights)
+GPO Y or setting Z in GPO Y isn’t applying (IOW, they don’t understand GPO settings/inheritance)
We backup GPOs, but no one has ever asked us to restore one.
Different organizations have different levels of trust & risk management and consequently will be at different points in a spectrum of possible approaches to this problem. What works for us may not fly for you, but it most certainly does