Help with AD Delegation

  • Last Post 24 February 2016
jeremy.stump posted this 23 February 2016

Need some help please. We are flattening our Active Directory structure and right now some groups and OUs are delegated with domain groups for delegated ability to write members but were going to move all groups into a single OU and I need to find a way to delegate these domain groups to have the ability to continue to manage those groups but not others. For example if I have 100 domain groups and I need to delegate helpdesk ability to manage 40 of them but operations to manage the other 60 how to write that script? Obviously I am talking about a heck of a lot more than 10 groups and if it were that easy I would manually delegate each of them but I am talking about thousands. The Managedby tab is nice and all but I need additional groups to have access to them all. I know how to delegate a single domain group to have the ability to write members for all groups in a OU without an issue but once I fold all of the other OU’s into this single one those other delegations will go away.   Jeremy Stump | System Admin III | Information Technology | BMHCC - CORPORATE
Phone: (901) 227-8205 | Jeremy.Stump@xxxxxxxxxxxxxxxx
Opinions expressed above are not necessarily those of Baptist.

This message and any files transmitted with it may contain legally privileged, confidential, or proprietary information. If you are not the intended recipient of this message, you are not permitted to use, copy, or forward it, in whole or in part without the express consent of the sender. Please notify the sender of the error by reply email, disregard the foregoing messages, and delete it immediately.

P Please consider the environment before printing this email...

Order By: Standard | Newest | Votes
a-ko posted this 23 February 2016

You can use the ACLs of the object itself. Think of ‘groups’ and ‘users’ like ‘files’ and OUs like ‘folders’. You can just edit the ACLs of the groups you need to let people manage. I don’t have it in front of me atm but just wanted to point you in a direction. As always, be careful with AD permissions J -Mike Cramer 


hcoleman posted this 23 February 2016

Can you create sub-OUs under your new top-level OU? Like





Then delegate at the sub-OU level, rather than on the individual groups.


Or, more broadly, what is the goal that has you flattening the current structure?



barkills posted this 23 February 2016

Yep, that’d work assuming you take into account the full AD permission model. And by that I mean:


See the background section in that blog post, and in particular the ordered list of 6 types of permissions in the order that AD processes them.


A .net code snippet which would point you in the right direction:


That snippet is intended for a slightly different thing, but it has the core stuff you’d need to do to manage explicit ACEs on an AD object.





jeremy.stump posted this 23 February 2016

Lets just say we have 12 casinosEach casino has its own ouCasino1                Groups                Users                WorkstationsCasino2                Groups                Users                Workstations Casino3                Groups                Users                Workstations We’re consolidating all casinos groups ous under 1 ou and eliminating the groups ous at each casino, soon will probably do the same for users, workstations we don’t really care about separating duties on. Need to delegate all groups writeproperty for casino 1 groups to casino 1 IT group Need to delegate all groups writeproperty for casino 2 groups to casino 2 IT groupNeed to delegate all groups writeproperty for casino 3 groups to casino 3 IT group I don’t think the way were structured is a big deal, but Microsoft engineers seem to think so. 


barkills posted this 23 February 2016

OU design should map to how you manage the objects.


If casino 1 needs to manage a set of objects, then it’d be best to have those objects in an OU for casino1 and grant an inherited ACE on casino1. Other organizational approaches are usually not needed, i.e. not

solving a real technical problem but usually a political or uninformed need.


That said, you can manage ACLs at the object layer and throw all your objects into a single container. That’s a lot more work, with more things that can go wrong. But you can do it. I’d avoid it since there is

a compelling cost reason not to, but go for it. J



bdesmond posted this 23 February 2016

> I don’t think the way were structured is a big deal, but Microsoft engineers seem to think so.


Is there a specific objection? Given the info in the thread, what you posted looks about like what I would have sketched out.



Brian Desmond


w – 312.625.1438 | c – 312.731.3132



kebabfest posted this 23 February 2016

Don't move all groups to a single ou even if you have a good naming convention.  In big orgs with 1000s of groups it causes mistake after mistake.
If you are only dealing with a small org then no problem.
For a big org divide the groups into departmental divisions similar to your users.


g4ugm posted this 23 February 2016

AD Basics from day 1 still apply. So:- OUs are used for two purposes: - 1.       To apply group policy2.       To delegate management authority. Expanding on the first, from what I remember Microsoft usually recommend separating Computers and Users and having separate Policies for computers and users. So if you need for different people to manage the separate casinos, or you need to apply separate policies to the users or computers in a particular Casino then you need the structure you had. If you do not need to treat Casinos separately then put everything in a single OU. That way the Policies can be linked in one place, the security can be the same on the top OU.  Having 12 OUs every time you create a new policy, or amend the Management Rights you need to do it 12 times. That’s a lot of work and can create errors…. Dave Wade   


jeremyts posted this 24 February 2016

So you have multiple options. If you’re going to consolidate OU’s but want to keep the delegate management of the group membership, then all you need to do is  use the “managedBy” attribute and select the “manager

can update membership” check box, which actually sets the ACL so that the managedBy group can “Write Members”.


For example. Add the “casino 1 IT” group to the managedby for the “casino 1” groups, select the check box and you’ll find they can manage the group membership.


I did this for a big University where all groups were in one OU, but each Faculty/School were able to manage their own groups.


If you have a consistent naming standard, it’s very easy to script. Or just use a CSV file for mapping and import that into PowerShell.


Examples of PowerShell code that does the trick is…


Using the AD Cmdlet to set the ManagedBy attribute.

Get-ADGroup $GroupName | %{Set-ADGroup $_ -managedby "$ManagedBy" }


Using the Quest Cmdlet to set the ACL, which in turn sets the “manager can update membership” check box.

Get-QADGroup -Identity "$GroupName" | Add-QADPermission -Account "$ManagedBy" -Rights WriteProperty -Property ('member') -ApplyTo ThisObjectOnly | Out-Null


You don’t need to use the Quest cmdlet, but my script is a few years old now!


Now I guess you don’t have to use the managedBy attribute, but it gives you a process to manage workflow. In the case of my example the University wanted to have a process for expiring groups when

they are no longer needed, so needed a group “owner” as part of that on-going workflow.


Test it out, but it should give you what you want as long as you don’t have any other delegated permissions that would deny this.






jeremy.stump posted this 24 February 2016

I am so glad to hear you say that I have always lived by this model and it seems people like to throw in their thoughts on the matter.  


SmitaCarneiro posted this 24 February 2016

We’re doing something similar here and are using the Dell/Quest ARS tool.


The old/current AD has an OU for each department number. Each OU then has




Non University Employees


We have a lot of department numbers and a number of groups to manage them.


I have revamped the new AD to have just one OU for users and another for groups. There are separate OUs for other objects.

The users have the department attribute populated and groups  have their name begin with the department number.


A scheduled task runs every day and populates ‘ Managed Units’ which are similar to OUs with the appropriate users and groups. Permissions are the granted to appropriate groups to manage their own Managed Unit.


This helps groups have all their users and groups together using Managed Units, and our inhouse provisioning system has to just populate 2 OUs with users and groups. Also when a user changes departments, since

the department gets changed  in an automated fashion, the user gets moved automatically to the correct MU and the right group can manage her/him.




Smita Carneiro





Techman06 posted this 24 February 2016

This is great stuff Brian.  Thank you for sharing.
Gary G. Gray

-------- Original Message --------
Subject: RE: [ActiveDir] Help with AD Delegation