Teams Invitation Processes - A comparison
Hi,
in this blog article, I deal with Microsoft Teams and Guest User handling. If you’ve read my latest articles here you might have recognized that I’ve talked a lot about Identity Governance and its relevance for Teams.
Now I want to share a short comparison about the different methods to invite guests to Teams which also cares about the costs that will come up while using the different approaches
Let’s say a company plans to use Teams to collaborate with external users. The external Users should be able to communicate in Teams Conversation with Members of the organization and access Files which that were shared in the Teams SharePoint Site. Other Applications used within Teams should be available for external users too.
There are different ways available how external users can gain access. I will describe the common scenarios here:
1. Non managed native Teams Guest Invitation
The native and default way to invite guests to a team is to allow Team Owners to invite their members as they want. The Owners can use the Teams build-in Feature to add guests. If they use an external E-Mail address to identify the external user here, in the background an AAD Guest Object will be generated, and an invitation is sent out to the targeted external user. The user can accept the invitation and will receive a mail that contains a link that allows him to navigate to the shared team.
The guest is a member of the Team until a team owner or an admin removes him from the underlying Microsoft 365 Group, or until an admin removes his guest account from the Azure AD. The guest User AD object will persist in the Azure AD until an admin will delete it.
2. Managed native Teams Guest Invitations
A variant of the first option is to allow Team owners to invite only external Users which already exist in the AAD. So, the general Guest Onboarding is decoupled from the native Teams experience. In this case, the guest user must be created administratively in the AAD before a Teams Owner can invite him in any Team. When the Guest object exists and the Teams owner uses the native Teams member add function, the guest user receives a mail that contains a link that allows him to navigate to the shared team.
The guest is a member of the Team until a team owner or admin removes him from the underlying Microsoft 365 Group, or until A admin removes his guest account from the Azure AD. The guest User AD object will persist in the Azure AD until an admin will delete it.
3. Access Packages
An access Package can be used to assign Team Memberships. The assignment can be an administrative task, but it also allows Self Service. Team Owners and other users that are aware of the link can send out an Access Package Link to allow external users to request their Team membership. The membership request is managed by policies that were defined primarily. The policy can contain e.g. an approval process with multiple stages to verify and justify the team membership of every single guest. The policy also contains an expiry process for assignments that allows authorized or defined persons and access package requestors to recertificate their team membership in intervals.
An approved Access Package Requests will generate an Azure AD Guest object for the approved external identity.
Using this option, the Team Owner cannot/should not use the native Teams way to invite guests. He must use the link to invite new guests.
The guest is now a member of the Team until an authorized user/admin removes the access package assignment, or until a user/reviewer does not recertify his membership when the Access Package expires, or an active review is started. The Azure AD Guest Object can be deleted automatically if it loses all Access Packages assignment to support the AAD hygiene.
Decision Making
An organization can decide which option should be used. The options 1. & 3., or 2. & 3. can be combined. Options 1. and 2. are an “either-or” decision.
It depends on requirements or your Business, your IT Dept, and maybe regulatory requirements, which option fits best.
If costs are a factor for a decision, you can use the following information to include it into your decision making:
Option 1 & 2 is included in the smaller Microsoft 365 Licenses, no additional Licenses are needed
Option 3 requires an AAD P2 License for every involved person. An (eligible) internal Requestor, an approver, a reviewer needs to have an AAD P2 License assigned. For external Users, every Guest that has been assigned an Access Package is relevant for licensing. (You can read here the official Licensing requirements)
You don’t need to assign AAD P2 Licenses to Guest Users. Right now, there are two different methods guilty to count the external identities usage of the AAD B2B Features:
1:5 Ratio: For every AAD P2 License which was assigned to an internal member, five guests user are allowed to use the same features
50.000 Guests flat rate: The first 50.000 Guests users are free to use AAD P1+P2 Features. After that, every additional external identity will generate costs (0.002741 € per monthly active user).
Option 1 is rarely used in enterprise organizations because of the missing management capabilities. The potential spillage and danger of potential data loss of this option lead in most cases to higher costs afterward.
Option 2 is a common way to manage external identities in larger organizations. The potential spillage and danger of potential data loss are moderate. Costs in the AAD operation Team and Service Desk will be generated for the onboarding of external identities, and the AAD hygiene.
Option 3 is an enterprise solution to manage access to resources. The potential spillage and danger of potential data loss is low (Read the Blog Article ‘Use more Access Packages!’ if you need to know more about Access Packages and their possibilities). Costs will be generated in the Service Desk / User Admin Team to support the handling of access packages. These costs can be reduced with adequate user training.
It is a strong recommendation to include Option 3 in a Teams deployment process to automate the creation of access packages for teams. This generates initial costs but reduces the operation costs throughout the lifetime.
Option 3 can be used for internal access management also, but because of the licensing requirement, it often starts with the management of external access.
Other Considerations:
The following considerations can also impact a decision for one or another option.
Azure AD Guests are not synced with the OnPrem AD DS and can only be Managed via AAD DS, so you can’t use well-tried onprem solutions to manage Guests.
If you use SMS / Phone-Based MFA for External Identities, there will be additional costs per authentication attempt using the new external identities billing model.
You can configure on M365 Group base which Teams should be enabled for external usage at all. You can define and solve this by a specific setting per Team or assigning a Sensitivity Label.
Access Packages can not only be used for Teams, but you can also manage the access to SharePoint Online Sites and Azure Applications.