Restricting Guest User Access in Azure Active Directory
Clamping Down on Guests
After several years’ usage, most Office 365 tenants are accustomed to guest users and the way that the Microsoft 365 groups membership model allows guests access to group resources such as plans, sites, and teams. For most, the model works well, and the only issue is how to best manage the guest user objects created in Azure AD. However, some organizations want to allow more restricted access to guests, specifically to clamp down on the ability of guests to navigate the directory in a host tenant. Microsoft’s answer is a preview of a new capability to restrict guest user access in Azure AD.
According to Microsoft, “when guest access is restricted, guests can view only their own user profile. Permission to view other users isn’t allowed even if the guest is searching by User Principal Name or objectId. Restricted access also restricts guest users from seeing the membership of groups they’re in.”
Setting the Azure AD Guest User Access Restrictions Policy
The Azure AD Guest user access restrictions policy (Figure 1) in the External collaboration settings blade in the Azure AD portal allows three options for guest access:
- Guests have the same access as members (most inclusive) setting means guests have the same access to directory data as regular users in your directory.
- Guests have limited access to properties and membership of directory objects settings. Guests don’t have permissions for certain directory tasks, such as enumerating users, groups, or other directory resources. This is the default setting.
- Guests are restricted to properties and memberships of their own directory objects (most restrictive). This is the new restricted access.
Image 1 Expand
It takes about 15 minutes before changes made to the policy are active and affect guest user access.
Control Policy Settings with PowerShell
The Azure AD Guest user access restriction policy can also be managed using PowerShell with cmdlets in the Azure AD Preview module (version 2.0.2.85 and above). To find the current policy, run the Get-AzureADMSAuthorizationPolicy cmdlet:
PowerShell
| 12345 | Get-AzureADMSAuthorizationPolicy | Format-Table DisplayName, GuestUserRoleId DisplayName GuestUserRoleId———– —————Authorization Policy 2af84b1e-32c8-42b7-82bc-daa82404023b |
The value of the GuestUserRoleId property contains the identifier (GUID) for the chosen template policy. The values of the identifier are:
- a0b1b346-4d3e-4e8b-98f8-753987be4970: Same access as Tenant members
- 10dae51f-b6af-4016-8d66-8c2a99b929b3: Limited access (default)
- 2af84b1e-32c8-42b7-82bc-daa82404023b: Most Restrictive
The Set-AzureADMSAuthorizationPolicy cmdlet updates the policy. For example, here’s how to set policy back to the default limited access:
PowerShell
| 1 | Set-AzureADMSAuthorizationPolicy -GuestUserRoleId 10dae51f-b6af-4016-8d66-8c2a99b929b3 |
Impact on Office 365 Applications
Knowing that you can restrict guest users is one thing. Knowing what guests can do when restricted is another. Guests access tenant resources through applications, so the focus shifts to what effect restricted access has when guests work with resources in applications.
The documentation for the preview feature lists three Office 365 applications which support restriction of guest access: Teams, OWA, and SharePoint. The documentation clarifies that: “By supported we mean that the experience is as expected; specifically, that it is same as current guest experience.” In other words, Teams, OWA, and SharePoint ensure that guest users have the same access to information in those applications when the most restrictive access is enabled by AAD as they have with the default level of access. While not exciting those (like me) who imagined that restricted guest access would automatically turn up in applications, this approach ensures that guests can continue to collaborate with tenant accounts as before.
Other applications have not yet done the necessary work. Known issues in the preview include an inability for guests to access plans through Planner or Teams when the most restricted access level is chosen. These problems are likely to be addressed before the preview is made generally available.
What’s the Point of Restricted Azure AD Access?
Given that guests can continue working as before with most Office 365 applications, what’s the point of applying restricted access to guests? Well, for now it stops people writing Graph API code to harvest directory information from tenants where they have guest accounts. I’m unsure that this happens often, but restricted access closes a hole that might allow sensitive information to leak, so that’s a good thing.
What’s more probable is that Microsoft will find ways to implement restricted access in applications to allow guests to continue working with a more limited view of directory information. For example, when a guest user is part of a team, they can view the full team membership and details of each member (Figure 2). If restricted access was in place, Teams might show the guest the name of members but not their phone numbers, email addresses, and address information.Image 2 Expand
The trick here will be to balance restriction with usefulness. In an application like Teams, which is all about fostering collaboration, guests are invited to interact and work with other people, so it doesn’t make sense to clamp down too severely on them. The same is true for Planner and Yammer. SharePoint Online and OneDrive for Business are different environments. A guest invited to share a single document or folder doesn’t need any information outside those contexts, so restricted access might be very restricted.
