There are a lot of of settings available in a Microsoft 365 Tenant which were responsible for guest access. To manage guest Access in Teams you have to adjust different settings. At least the Azure AD external Collaboration Settings, the SharePoint Sharing Policies & Settings and the Teams Guest Access Settings are relevant. If you’re reading this blog I’m sure you know this switches.

The next level you might be aware, are the Microsoft 365 Group settings and sensitivity labels. With the Microsoft 365 Group Settings – which you can manage via Exchange & AAD PowerShell or the Graph API – you can e.g. disable guest invitations for a single Team . With Sensitivity Labels for Groups – one of the features I’m most excited about – you can also define, among other things, that no external users can participate on a Team.

The previously named options only allow to enable / disable guest access to a single Team or for the whole Tenant. With the Azure AD external collaboration settings you have minimal options to steer which Guests are allowed by adding their domains to a whitelist.

For some customers these options doesn’t fulfill their requirements for access management in Teams. In this blog I will explain a possibility to allow only authorized users to add guests from approved domains. We will use the Azure AD Identity Governance Feature, which allows us to implement an approval for new guests. Furthermore it will allow Access Expiry and Reviews.

So, lets start to add some more granularity and controls to the Teams guest management.

Create a Connected Organization

First you navigate to the AAD Portal for Identity Governance. Here you can add the domains you plan to collaborate with. Just add the Partner here add the domains they use.

Be aware that you can not use domains here, that you have blocked via the Azure AD External Collaboration Settings.

You can add a M365 Tenant partner domain or any other „type“. The assistant will check itself if it’s an Azure AD counterpart. If the partner organization is also using an Azure AD you can use more functions in the future, but for our scenario every kind of partner domain is fine.

In the next step you can add internal and external sponsors. You can make use of them in approval scenarios later. Users to add here, are mostly partner managers or other responsible persons in your and the related partner organization. The external sponsor must have an existing guest account in you domain, so you have to invite him before.

Create a Catalog

After finishing the connected organization assistant, the next step is to add catalogs. A catalog contains the resources to which you want to grant access. In our case we will add a Team or a Group of Teams here to the catalog. We will enable the catalog for external usage. After creating the catalog we can add the resource (the Team) to the catalog.

Create an Access Package

The next step is to create an Access Package which regulates via policies which connected organizations can access the resources we’ve added to a catalog.

On the „Requests“ tab we define the connected organizations which are allowed to participate in the Team. Choose every connected organization here which should be able to participate as a guest in the Team. Furthermore you can implement an approval here. In most cases, a single sage approval where the Team owners are assigned as approvers is enough. But you can also add a second stage and e.g. involve the external Sponsor which we’ve defined in the connected organization before.

On the „Requestor information“ tab you can add questions which guests have to answer to request access. It can be used to gather further information about the requestor and his justification to participate in the Team.

The tab „Lifecycle“ defines an expiration of the Guest Access requests and allows you to define a regulatory review of guests which have access to the package resources. You can insert static reviewers like the Team owners, or allow a self review. In our case we decide to insert the Team owners. They will receive an report on a regularly base which contains the external guests who have access to the Team and recommended actions to extend or quit the guest access.

With the finalization of the access package you will receive a link which can be used to invite the guests. Pass it over to the Team owners, to enable them to invite guests from the connected organization via sharing the link.

Result

What we’ve done now is that we implemented an approval Process for Teams Guests. Only guest from connected Organizations which were authorized via policy to the access package, are able to access request. The Team Owner is able to invite Guests very simply by sending them a link. The Team owners will receive a Access Review were they can check which Guests are in the Team, if they were still active, and can initiate related actions.

Every Guest will stay in the Team for 180 days before he get’s an notification to decide if he want to participate longer or not. If the Guest decides to continue a new approval is started.

Now we just have to care about the native guest invitations in Teams. Because we want guests to be invited via the access package, we could not use the regular process any longer. Unfortunately Teams doesn’t respect the Guest Inviter Role. So every owner will be able to add guests, as long as Guest Invitations are allowed in the Tenant and Team. The trick here is to disable the Guest Invitation Feature „AllowToAddGuests“ in the underlying Office 365 Group

To get this done you have to configure the Group Settings. You might know it from defining Group Creation Limitations, AAD Naming Conventions and so on.

(If you not already have enabled the Template Based Settings you can read how to get it done in general here: Configure group settings using PowerShell – Azure AD | Microsoft Docs. )

To disable the Guest Invitation Feature per Team you can use the AAD PowerShell or use the Microsoft Graph API:

You will recognize that Team Owners are not able to add guests to the Team on the native way anymore. The possibility to add guests to the access package will continue to work.

The following GIF shows a exemplary Guest Invitation Process:

This is pretty much stuff to configure to implement the guest access management. If you decide to build an Access Package per Team and let organization A,B and C participate in the Team, it will be hard to configure this manually every time. But because all these configurations could be done via Graph API you can easily implement it in an automated Teams Deployment Process.

If you need an example how to get this done, and allow the management of the connected organizations in a self service approach, you can read my blog article Another Microsoft Teams Governance Approach – Using Azure AD Identity Governance – thinformatics blog (Yeah, you will need some time to read it, but it’s a step-by-step description to implement Identity Governance into your Teams Deployment Process).