Forum Discussion
PowerShell doesn't follow configured policies for Groups creation
We have the requirement to restrict creation of Office 365 Groups to only a number of people, and we have implemented for described in this article to achieve that:
Manage who can create Office 365 Groups
Within OWA/Outlook we can see the configured policies are correctly followed: a user that is member of the allowed security group can create a new O365 Group, independently from its role.
This means that if a Global Admin user isn't part of the security group, it won't be allowed to create new Groups via UI.
When loading a EXO PowerShell session these policies aren't respected: only users with Global Admin role will get, and be able to execute, the cmdlet New-UnifiedGroup.
A user that is member of the security group allowed to create new Groups, won't get the New-UnifiedGroup command available, despite that user is allowed to perform the operation.
We find this inconvenient, and this won't let us to design and implement a Groups provisioning and governance solution as we expected, following 'least privileges' principle.
We'd like to know if this incorrect behavior is known to Microsoft, and if it'll be addressed in the upcoming future.
Regards,
Massimo
The policy applies to "client" endpoints, PowerShell is not such. You can however create/assign a custom role to any users you want to be able to create Groups via PowerShell. For example, the "Mail Recipients" role already has the New-UnifiedGroup cmdlet.
The policy applies to "client" endpoints, PowerShell is not such. You can however create/assign a custom role to any users you want to be able to create Groups via PowerShell. For example, the "Mail Recipients" role already has the New-UnifiedGroup cmdlet.
Thanks for your answer. Unfortunately this still won't let us achieving our requirement to control by applying it to a security group.
Add-AzureADDirectoryRoleMember : Error occurred while executing AddDirectoryRoleMember Code: Request_BadRequest Message: Role membership changes can only contain objects of the following types: 'ServicePrincipal,User'.
So we'll have to create an Application (service principal) and delegate the operations to it, or assign the permissions per-user.
Those are the Exchange roles, not the Azure AD ones. You will find them under O365 Admin portal -> Exchange -> Permissions.
