A long time ago when computers were only 1’s and 0’s and had physical footprints the size of large rooms, we only had code. You really had to know what you were doing and you couldn’t google your way out of information you were missing. Then one day the GUI was born and made our lives so much easier. For some tasks, this was a game changer and made us more efficient. But for other tasks it was a burden to have to click 55 boxes to do the same thing you used to do with a one-liner. Thankfully, now days we are usually provided with both options. Mabye this isn’t you, but for me as a lazy admin, I want to automate every task I have to do more than once. What’s frustrating is doing 95% of what you want to do in either method but not being able to do that one last thing. One of these areas that has really gotten my knickers in a wad is that pesky little “Manager can update membership list” on an on-premise distribution group in AD.
You can see this little checkbox by:
- Opening up Active Directory Users and Computers (ADUC)
- Navigating to the group you want to edit
- Right-clicking on the group and choosing “Properties”
- On the “Managed By” Tab, there’s a little checkbox under the Manager that says “Allow Manager to Update Membership”

\\\Mic Check 1 2
Checking the box in this GUI is easy peasy. It’s so easy a caveman could do it. But what if you had to create or edit 100+ groups? The caveman would go extinct before checking the last checkbox. The thought of doing this manually in the GUI gives my wrists carpal tunnel nightmares. So where do we normally turn when there are a billion of the same monotonous tasks to accomplish? No, not your junior subordinate. That’s just cruel. We turn to PowerShell of course!
But would you believe that this checkbox of a setting is nowhere to be found in the Set-ADGroup
or New-ADGroup
cmdlets? Even in the Exchange PowerShell module, the Set-DistributionGroup
and New-DistributionGroup
are missing it as well. There isn’t a simple way to control the “Manager can update membership list” checkbox from PS, but there is a way…
\\\Torn ACLs
You probably know all about ACLs from playing Madden and having your star WR out for the season with a torn ACL, but there are also some other ACLs that are useful. We also have another cmdlet in our arsenal to control ACLs in AD. This one probably doesn’t get used quite as much, but it is the Set-Acl
/New-Acl
cmdlets.
When I said there was a way, this one is somewhat hairy and may require you to stand on one foot or hold out your tongue while running it…so before we dive into the nitty and the gritty, let’s look at an overview of the process:
- Get the current AD Group
- Get the current ACL of that Group and store as object
- Get the user who will be the Manager
- Define our Rights, Control, and GUID of the ACL we’re wanting to change
- Create a new ACL using the SID, Rights, Control, and GUID
- Add the new ACL to the exiting ACL object we pulled from the group
- Set the ACL to the group
- Take a nap
I know this probably seems crazier than that one time you put that dying hard drive into the freezer hoping to bring it back to life, but it will make sense after you read through this post. Probably. Maybe. Hopefully?
\\\GET IT GET IT
Let’s start out by just gettin’ stuff. Let’s get the group:
$Group = Get-ADGroup JediKnights
The current ACL of the group:
$GroupACL = Get-Acl AD:\$Group
And the Manager:
$ManagedBy_ADUser = Get-ADUser ObiWan
\\\Build It Build It
$ManagedBy_ADUser
and create a new SID Object. Then we’ll need to set the control type and the AD permission. Lastly, we’ll need to specify the System ID GUID of the Member attribute. The AD schema has a System ID expressed as a GUID for each attribute. We want this ACL to apply to this specific attribute (Member). This block of code is allowing the manager to update the Member Attribute:#Build New ACL using the manager's SID
$UserSid = New-Object System.Security.Principal.SecurityIdentifier ($ManagedBy_ADUser.SID.Value)
$Rights = [System.DirectoryServices.ActiveDirectoryRights]::WriteProperty
$Control = [System.Security.AccessControl.AccessControlType]::Allow
$Guid = [guid]"bf9679c0-0de6-11d0-a285-00aa003049e2"
Now we use all of these variables we’ve defined to build the new rule:
$Rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule ($UserSid, $Rights, $Control, $Guid)
\\\Do It Do It
What??? We’re still not done? Almost! Don’t lose hope! The end is near and it’s less apocolyptic than you might think.
The last part of this process is to add our new rule to the existing rule we pulled from the group sxity and fourscore years ago:
$GroupACL.AddAccessRule($Rule)
Set-Acl
to apply our new ACL to the Group.Set-Acl -AclObject $GroupACL -path AD:\$Group
That’s it. You won! Now you can control the “Manager can update membership list” setting via PowerShell!
This is awesome, but the $Rule line faults..
New-Object : Cannot find an overload for “ActiveDirectoryAccessRule” and the argument count: “4”.
Working on figuring out the overflows ..
Hey N G,
First, thanks for dropping a comment! Did you run the lines above this to get the $ManagedBy_ADUser before building the $Rule? If that looks good, cycle back through the individual variables ($UserSID, $Rights, $Control, and $GUID) to make sure they all have values. Let me know if you’re still running into issues.