Unable to set edsvaSecondaryOwnersCanUpdateMembershipList attribute on a group object using PowerShell

The setting of this attribute performs a write-through of native permissions to Active Directory (the same occurs for the Primary Owner).  Does your ActiveRoles service or override account have rights to modify object security in AD?

In the ARS and AD console I can modify the "Manager can update membership list" for the primary owner.

In the ARS console, I can modify this for both the primary and the secondary owners.

In the AD console, this option does not exist for the secondary owner.

When I modify this for the secondary owner in the ARS console and do a get-qadobject on the object it shows that the value of edsvaSecondaryOwnersCanUpdateMembershipList changed from null to true which was set with the same account that I am running this command from in PS so it seems like it wouldn't be a rights issue.

I also just tried this:

Set-QADGroup -Identity domain\groupobject -SecondaryOwnersCanUpdateMembershipList $True

And receive the same error message as the command.

After some more research, changing edsaManagerCanUpdateMembershipList as well as edsvaSecondaryOwnersCanUpdateMembershipList change other values in the object which are "links." I also noticed that if I ave both of these enabled in the console, and disable only edsvaSecondaryOwnersCanUpdateMembershipList, it also disables edsaManagerCanUpdateMembershipList. I'm not sure if this should impact trying to set a value to true but it is almost like when I try to change the value of edsvaSecondaryOwnersCanUpdateMembershipList, it cannot find the attribute in the object to change it.

Attributes that also change when changing edsaManagerCanUpdateMembershipList and / or edsvaSecondaryOwnersCanUpdateMembershipList  to true or false:

edsaHasATLinks  

edsvaATLinksEffective

edsaHasNotPredefinedATLinks 

I am stumped, anyone insight as to what is going on would be much appreciated.

Thank you.

Do you actually have some SecondaryOwners set on the object in question?

Yes, I have 2 users currently set as secondary owners.

I am curious, if you look at the native AD permissions tab in the AR console for the group in question, do you see any individual users in there?  If the permissions from this setting are being passed through to AD correctly (via the AR MMC that is), you should see ACEs for the individual group owners & secondary owners.

Jacob R said:

"Manager can update membership list" for the primary owner.

is a native AD permission to be used via Exchange MSFT Outlook for Primary Owner o manage DLs (legacy functionality). ARS used to incorporate it in internal Workflow.

#2. edsaManagerCanUpdateMembershipList is ARS internal functionality for Secondary Owners (formatted "DA\jsmith;AD\joedoe") to be used internally in ARS workflow (legacy for ARS SSM 6.7). It is legacy functionality fro 6.7, and might be decommissioned today.

I would recommend to implement #2 differently. Create MU "GroupsSecodayOwners" - permissioned AT "Group Member Modify" - Trustee BUILT-IN\Secondary Owner (Well Known SID)

(please refer to Quest / One Identity PSO to generate the AD management workflow you need)

Alright, so if I understand this correctly. The best way to accomplish this would be to create a new membership group with the secondary owner permissions and add that to the DL? Also can you please link me to the PSO for reference?

As always, much appreciated.

My colleague Aidar's statement concerning the nature of SecondaryOwner membership update permissions is not 100% correct.  I just did a test in my lab where I applied an individual user as a secondary owner and checked the box "...secondary owners can update membership list".

Two things occurred:

1) A new AR access template link was placed on the group.  It cited my user at the trustee and granted this trustee the builtin Access template Groups - Read/Write Members.

2) Looking at the Native AD permissions, a new ACE for my user was added with Group Read/Write Members native permissions.

So creating a Managed Unit and granting rights to secondary owners via an Access Templates is only going to accomplish the equivalent to Item 1.

I go back to my original question to Jacob - when you check the "secondary owners can manage" box and inspect the native permissions in AD, do your secondary owners have permission there?

If yes, then there is clearly something odd about the way the cmdlets handle this.  My guess would be that you have to set the secondary owner and "check the box" simultaneously in the same request.