Teams Real Simple with Pictures: Governing Guest Access via Azure AD Roles and PIM

This blog is part of a series on Teams. For more articles, check back often

Written: 16/01/2022 | Updated: N/A

Last week, after I wrote the previous article on B2B Management Policy I had a nagging feeling that I wanted to write something more. It was in the back of my brain I just couldn’t articulate it. Then during this week when I was teaching SC-900 and doing labs with Azure AD I remembered. Then, me being me I forgot it again. It’s been that kind of week. But sitting in the restaurant today at Wagamama whilst eating a load of teriyaki soba it all came flooding back: it was a complimentary piece to B2B management on how we can restrict adding guests based upon external identities and leveraging Azure AD roles. Last week, we saw how you could out and out block specific domains, which meant that guests from those specific domains cannot be added. This week, we are going to see how you can stop Teams owners from adding guests unless they have a specific Azure AD role assigned called Guest Inviter. This has two real benefits. The first is that it stops Teams owners backdooring guests when you have implemented Entitlement Management because setting up EM doesn’t suddenly strip Team owners of adding guests directly in the team itself via manage users. Secondly, because Team owners no longer have standing access to invite guests and you are basing that functionality upon assignment of an Azure AD role, you can now run it through PIM and this would go well with an access review. Now it would certainly be what you could call an EM light approach. The upside would be you no longer have to deal with catalogues or packages which removes a layer of complexity. The downside is that with EM you can package multiple Teams/Microsoft 365 groups/SharePoint site at a time: what follows wouldn’t be able to do that. Still, it gives us another tool in the kitbag should we want. It also works from the perspective of not having to purely rely on having to use sensitivity labels to block guest access to specific teams, since Team owners won’t be able to do that unless they have the assigned role – and then they could be used anyway. So in short, this facilitates EM through to its full conclusion or an alternative approach which isn’t so rigid as EM, but still puts controls on users adding guests carte blanche.

All good? Let’s go.

This blog will cover

  • Restricting who can add guests in Azure AD
  • Administering Guest Inviter Azure AD Role with a Security Group
  • The impact to Team Owners in Teams
  • Using PIM with the Guest Inviter Role

Note this blog may have some abridged steps which will assume some experience with a Microsoft 365 environment and Azure AD


  • Microsoft 365 Licences which includes Teams
  • Global Administrator role
  • Azure AD P2 (for users who use PIM)


1.) Login to

2.) From the waffle, or from the left app rail, select Admin

3.) In the Microsoft 365 admin centre, from the left navigation, select Show All and then Azure Active Directory

4.) From the left nav, select Azure Active Directory

5.) Select External Identities

6.) Select External Collaboration Settings

7.) Under Guest Invite Settings select Only users assigned to specific admin roles can invite guest users and then Save

Adding guests is now only possible to using the following roles:

  • Global Administrator
  • User Administrator
  • Guest Inviter

The Guest Inviter role is the key which we will use to control who can invite guests


1.) Return to Azure Active Directory and select Groups

2.) Select New Group

3.) Create the group as follows

  • Group Type: Security
  • Group Name: Something specific like ‘Guest Inviter’
  • Group Description: As required
  • Azure AD roles can be assigned to the group: Yes
  • Owners: as required
  • Members: as required. Here 1 member Vesku Nopanen has been added
  • Role: Guest Inviter

4.) Accept the terms and check back into groups to see that it has been created with the correct members. If you already have Privileged Identity Management in play, then under Assigned Roles you will see that the Guest Inviter role has been assigned as a permanent role initially

At this point, only users within the organisation who have the Global Admin, User Admins and Guest Inviters can now invite guests. The Azure AD role that we will leverage to give Team Owners – Guest Inviter – has been added to a Security Group. In other words, only users who are Team Admins and who have the Guest Inviter Role assigned can now invite Guests into Teams

Let’s go see this in action


1.) Log into Teams and select a Team which has multiple owners, or where there are different owners as defined by the Azure AD Security Group created. In this example we see here that there are three admins to the Team

2.) Vesku, who had been added to the Azure AD Security Group with the Guest Inviter Role can invite guests without issue

3.) However, Adam who wasn’t added to the Azure AD Security Group, cannot invite guests: the experience in Teams for someone without the role is that they simply cannot find guests who they invite outside of their tenant

Guest access and invitation are now controlled by the Guest Inviter Azure AD Role assigned to the team owner and where the specific team owner has been specifically added to a security group: this stops Team owners simply adding guests carte blanche into any team, but must seek permission from their IT department and organisation before given the functionality.

This in itself also ‘completes’ Entitlement Management. If this is added after Entitlement Management and access packages have been set up, then guest access is only controlled through access packages where admins will not be able to back door guests through Adding Members to a Team.


So having now controlled who exactly in the organisation can added guests, and given we control it with an Azure AD Role, we can also go one step further and use PIM. Privileged Identity Management (PIM) removes standing access to the role itself, which means that only the people within the security group will not always have the role – they will be eligible for it, and will need to apply to use it within a specific period of time. The benefits from a security perspective include PIM’s controlling of when somebody can add a guest and the fact it needs an approval.

1.) As the global administrator who set up, log back into Azure AD and go to groups

2.) Select the group created for Guest Inviters

3.) Select Assigned Roles

4.) The Guest Inviter role is currently configured as a permanent role. On the role, select Change

5.) Change the assignment type to Eligible, you have the option to untick permanent eligible and set a time limit on how long the user can apply for the role. This example will set 1 year. Once done select Save

6.) The role is now eligible so users within the Azure AD Group will now need to apply for it

7.) The last thing we need to do to configure PIM is apply an approval process to the role which means amending the Guest Inviter Role in PIM itself. Within the PIM service in Azure AD under Identity Governance navigate to Assignments and then select Settings

8.) Search for an select the Guest Inviter Role

9.) Select Edit to edit the role

10.) Set the time the user has with the role (here shown as 2 hours) and set both a business justification and an approver. Run through the wizard and update the settings to how you want the experience to be.

Let’s test this out

Vesku, who is part of the Azure AD Security Group, logs in and goes to his eligible Azure AD roles within Identity Governance

Before he gets the role approved and assigned he cannot add guests

He selects Activate in Azure AD and applies for the role. He requests a 2 hour window to add 4 guests to his team. The role is pending for Approval

The approver (Chris Hoard) Approves in Azure AD

Now with the active Guest Inviter role Vesku can add the guests to his team