SOLVED

Office 365 Groups

Iron Contributor

Hey Guys, Simple question, is there a way to make it so a user who has Service Administrator permissions in Office 365 and (Recipients Role, Distribution Groups Role) in Exchange Online RBAC can modify group membership for Office 365 Groups? 

 

Here is the error the user is getting when trying to modify an Office 365 Group: 

 

 

 

Is there anyway to allow a user to modify group membership for Office 365 groups without granting user management role? 

 

Thanks, 

 

Robert

14 Replies
Well, according to the error you are getting, you need to be at least EXO Administrator + User Administrator so I guess that User Role is not enough
Right. If i add the user administrator role it works as expected. I just need to know if there is a way to make it so a non-admin (who has all the exchange role group permissions) can edit Office 365 Group membership.
best response confirmed by Robert Bollinger (Iron Contributor)
Solution

The problem is Groups are not Exchange objects, they are AAD objects. While you can certainly govern some settings via the ExO cmdlets, AAD remains the source of authority, thus the portal requires you to have the necessary permissions to run the corresponding AAD cmdlets/API calls.

 

That said, if you are OK with using the EAC or PowerShell, you can certainly use an Exchange admin (or non-admin with the relevant permissions) to manage them. All you need is to have the Mail Recipients role assigned.

another issue is that the Groups cmdlets do not support RBAC...

 

Still another is that the Groups membership model only differentiates between owners (who can add new members) and members (who cannot). Tenant admins override this restriction, but that doesn't help.

Thanks for the clarification Tony. That's what I was looking for.
Thanks for the clarification Vasil. That's what I was looking for.

@Tony Redmond nearly 2 years on, is that right O365 groups CMDlets still don't support RBAC? 

 

I have a Management Scope for allowing local site admins to update group membership for groups they are not owners of. Works like a dream for everything other than the O365 Groups. Sure is irritating... 

@Joshua Bines Yep. The Groups cmdlets seem to work well for tenant admins and the other admin roles that support groups, like the new Groups admin role. But they don't do scoping.

@Joshua Bines I played with this a little but it didn't work as I expected.

 

1. Created AU

2. Added several accounts to AU

3. Created new Microsoft 365 group with those accounts as members and added it to AU.

4. Assigned one of the users as a Groups administrator for the AU.

5. Logged onto Azure AD portal for that user. They could update some group properties like the description and sensitivity label assignment, but they couldn't update group membership, which is what I think you're after.

 

Maybe this is a timing thing and I should wait to see if the permissions sort themselves out...  but I note that the documentation https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-administrative-... mentions membership management, so it should work.

User management

USER MANAGEMENT
Permissions MS Graph/PowerShell Azure AD portal Microsoft 365 admin center
administrative unit-scoped management of user properties, passwords, licenses Supported Supported Supported
administrative unit-scoped blocking and unblocking of user sign-ins Supported Supported Supported
administrative unit-scoped management of user MFA credentials Supported Supported Not supported

Group management

GROUP MANAGEMENT
Permissions MS Graph/PowerShell Azure AD portal Microsoft 365 admin center
administrative unit-scoped management of group properties and members Supported Supported Not supported
administrative unit-scoped management of group licensing Supported Supported Not supported

To bring everyone up to speed, I reported the problem I experienced to the Azure AD team and they found an issue that's now resolved. Group management via delegated admins works as expected. I'll document this and publish an article on Petri.com to report what I found.

Thank you Tony for the update and the investigation! I was wondering why this wasn't working in my tenant.
1 best response

Accepted Solutions
best response confirmed by Robert Bollinger (Iron Contributor)
Solution

The problem is Groups are not Exchange objects, they are AAD objects. While you can certainly govern some settings via the ExO cmdlets, AAD remains the source of authority, thus the portal requires you to have the necessary permissions to run the corresponding AAD cmdlets/API calls.

 

That said, if you are OK with using the EAC or PowerShell, you can certainly use an Exchange admin (or non-admin with the relevant permissions) to manage them. All you need is to have the Mail Recipients role assigned.

View solution in original post