Did you know: My Groups and guest access restrictions

We often say, jokingly or not, that different teams within Microsoft rarely talk to each other. There are plenty examples that we can use as “evidence” for this claim, and today, I want to talk to you about one of them. Specifically, the fact My Groups portal does not enforce Microsoft 365 Group’s guest access settings in the same manner that other endpoints do. Let’s dig in.

First, a quick reminder how guest access is controlled for Microsoft 365 Groups. We can either enforce control on the tenant level or on a per-group basis. In both cases, a “settings” object is configured, either on the tenant (“directory”) level or on the group level. We covered how to use the cmdlets from the Graph SDK for PowerShell module to manage group settings in a recent article, should you need a more detailed refresher.

Configuring restrictions on admin side of things is only a part of the equation, the other one being how the various apps and workloads enforce said restrictions. “Client” endpoints, such as Outlook or Teams, will prevent even users with admin roles from adding a guest user to a Microsoft 365 Group with the AllowToAddGuests flag toggled to False. “Admin” endpoints on the other hand will allow a user with sufficient permissions to add guest users even for “restricted” groups.

It turns out, My Groups portal behaves like an “admin” endpoint in this regard, as it does not check for or enforce the setting for guest access. Instead, it defers the decision to the backend, which in turn means that admin users (with appropriate role) can add a guest user to a Microsoft 365 Group, regardless of the AllowToAddGuests value. On the other hand, My Groups behaves much like a “client” endpoint for other group-related operations, i.e. even an admin user cannot use it to change the membership or other settings for groups they are not an owner for.

To illustrate this difference in behavior, let’s take my own user account (a Global admin) and compare the experience against a user with no admin role. To keep things simple, we will only compare the behavior in OWA and My Groups. When a group is configured to restrict guest access, OWA will display an infotip (see screenshot below) and prevent you from adding guest users, regardless of any role you hold for the Group or within the directory. If you take a look at the network trace, a request is made to the https://graph.microsoft.com/v1.0/groups/{id}/settings endpoint when you hit the Add members button, ensuring that any restrictions configured on the group will be respected.

In contrast, no such request is made when performing the same operation via the My Groups portal. Any owner can thus hit the Add button and type in the identifier for a guest user. No infotip or warning of any kind will be displayed, and you can proceed with confirming the changes, only to be greeted with “Something went wrong” tooltip. A tooltip that is automatically dismissed I might add, so you can end up confirming the operation, yet seeing no changes in the group’s membership.

The network trace shows that a Graph API request is made to add the guest user to the group, resulting in an 403 Forbidden error being generated (Authorization_RequestDenied). The error message does tell you that the change was blocked due to the settings configured on the group (see screenshot below). However, this or analogous text is not exposed anywhere in the UI, so users are left guessing as to why the guest user addition operation failed.

"error": {
    "code": "Authorization_RequestDenied",
    "message": "Guests users are not allowed to join this Unified Group due to policy setting. paramName: Members, paramValue: , objectType: Microsoft.Online.DirectoryServices.Group",
}

So, we now know that the Graph API will enforce the guest access restrictions even if the “frontend” fails to do so, and this is a good thing. The other part of the story however is what happens when a user with admin role executes a similar operation via My Groups. The exact same request is made to the backend, but this time around the guest user is added successfully. We can question whether this is the expected behavior, but as in this case the access token will contain a valid admin role claim as well as the required Group.ReadWrite.All scope, the Graph is doing what it is supposed to do and treating this as an “admin” requests.

Replacing the aforementioned Group.ReadWrite.All scope with something that only allows you to perform operations on groups you are an owner of should be sufficient to address this inconsistency in behavior, but alas, the Graph is know for its lack of scoped permissions. An alternative “solution” to the misbehavior we described above is to implement some checks on the front end, much like OWA does. Though, this approach is not without its own implementation issues, as we shall see in a future article, once Microsoft confirms my findings and addresses any potential exploits!

So in summary, the while the My Groups portal does respect Microsoft 365 Group’s guest access restriction settings, it does so in a manner more suitable to “admin” endpoints. This contrasts not only to the guest access restriction implementation in other endpoints, such as OWA, but also with the Group management experience within the My Groups portal itself, where a user cannot make changes to group objects they are not an owner for, even if they have a suitable admin role assigned. Not a huge issue, but certainly something to be aware of!