Today, when a service principal is an owner of a group, certain functionality using the MS Graph works with no addtional grants, such as add/remove member and get a group's specific detail. However it is not possible to list members of the group that they own or get a list of groups that they own, without granting permissions such as Group.Read.All/GroupMember.Read.All/Group.ReadWrite.All/GroupMember.ReadWrite.All.
These hidden behaviours are undocumented, and all MS Graph docs suggest that the relevant "...All" permissions should be granted by default.
This conflicts with least privilege principals, as by granting the relevant "...All" permission, the service principal is now able to read/write all groups in the tenant, not just the ones it is an owner for.
Is it possible to get a "Group.ReadWrite.OwnedBy" and "GroupMember.ReadWrite.OwnedBy" permission that would explicitly allow service principals to list group membership etc... without granting wider "....All" permissions. A similar permissions exist today for "Application.ReadWrite.OwnedBy", so it seems achievable?
1 Comment
I was also searching for an added permission "Group.ReadWrite.OwnedBy".
However, in line with the existing Application.ReadWrite.OwnedBy, it should specifically also enable the holder to create a new Group while immediately becoming Owner.
I think that aspect of automatically becoming Owner is the core of that permission. It enables delegation of creation AND management of Groups, without handing out the extremely sensitive permission to modify or remove all Groups in the tenant.
I would say this is a highly coveted permission, it would be great if it could be added. An added bonus would be if it could be split into Security Group and M365 Group creation. That is however more a practical consideration than a security or governance one.
