One of the most difficult concepts to understand within Teams is guest access. This is because guest access requires that you make changes not only in Teams, but also within Azure AD, Office 365 Groups, and SharePoint. No need to worry though, I’m here to walk you through all the in’s and out’s of guest access, requirements for guest access, and how you can start using guest access today within your organization. Then in the next blog, we’ll go through a step by step process on how you can configure guest access in your tenant!
What is Guest Access?
Before we can begin implementing guest access we need to understand how it works, not only within Teams but across all Office 365 services. Guest access will allow you to add individuals from outside your organization to your teams and channels within Microsoft Teams so you can collaborate with one another. Guest access will allow you to chat, call, meet and collaborate on organizational files (stored in OneDrive for Business or SharePoint) with individuals from outside of your organization who access teams, documents in channels, resources, chats, and applications.
Now that we know what guest access is, how does Microsoft define a ‘guest’? Microsoft’s definition of a guest is a user type in Microsoft Teams that are included with all Office 365. This includes all Business Premium, Office 365 Enterprise, Office 365 Business Essentials, and Office 365 Education subscriptions. No additional Office 365 license is necessary. This ‘guest’ is not an employee, student, or member of your organization. Instead, they are anyone with a business account (Azure AD account) or a consumer email account (Outlook.com, Gmail.com, etc.). They can participate as a guest in Teams with full access to the teams and channels.
However, just because the guest has full access to the team and channel to which they were invited, this doesn’t mean that they will be given all of the same capabilities that Teams users in your organization will have. Below you’ll see a table that lays out which capabilities are available to users within your organization vs guest users.
You’ll actually notice that the guest capabilities are quite limited compared to Teams users within your organization and this is for a good reason. Microsoft gives guests just enough access so they can collaborate effectively while also restricting access to certain capabilities which could potentially cause a breach of data. For example, creating teams, sharing chat files, joining public teams, inviting users outside of Office 365 tenant’s domain, etc.
Limitations
With the way that guest access is designed you will quickly notice that there will be some limitations that you’ll need to take into account before implementing it within your organization. Knowing the guest experience is pivotal to your organization so your admins aren’t spending hours on end trying to fix something for a guest that doesn’t have access to that capability by design. With that being said consider the following limitations to guests in Microsoft Teams:
- Guests do not have access to OneDrive for Business
- Cannot use the people search functionality outside of Teams
- Guests will not have access to the calendar, scheduled meetings, or meeting details
- They will not have the ability to use PSTN calling
- No access to view users organizational charts
- Guests cannot create or revise a team
- They cannot browse for teams
- Guests cannot upload files in a person-to-person chat
- All guests can search and find users outside of their team. But only if they know the user’s full email ID. However, IT admins can use patterns like scoped directory searches that have the ability to restrict guests to their own virtual GAL.
- Teams only supports State 1 and State 2 types of guest users
- State 1 – Homed in an external instance of Azure AD and represented as a guest user in the inviting organization. In this case, the B2B user signs in by using an Azure AD account that belongs to the invited tenant. If the partner organization doesn’t use Azure AD, the guest user in Azure AD is still created. The requirements are that they redeem their invitation and Azure AD verifies their email address. This arrangement is also called a just-in-time (JIT) tenancy or a “viral” tenancy.
- State 2 – Homed in a Microsoft or other account and represented as a guest user in the host organization. In this case, the guest user signs in with a Microsoft account or a social account (google.com or similar). The invited user’s identity is created as a Microsoft account in the inviting organization’s directory during offer redemption.
- State 3 (NOT SUPPORTED) – Homed in the host organization’s on-premises Active Directory and synced with the host organization’s Azure AD. You can use Azure AD Connect to sync the partner accounts to the cloud as Azure AD B2B users with UserType = Guest.
- State 4 (NOT SUPPORTED) – Homed in the host organization’s Azure AD with UserType = Guest and credentials that the host organization manages.
Note: State 1 and State 2 accounts are the results of inviting guest users to collaborate by using the guest users’ own credentials. When the invitation is initially sent to the guest user, an account is created in your directory. This account doesn’t have any credentials associated with it because authentication is performed by the guest user’s identity provider. The Source property for the guest user account in your directory is set to the Invited user.
This wraps up today’s blog about Guest Access. But check out my next blog where we’ll show you how to configure guest access across the different Office 365 services and what your experience will be like if guest access isn’t properly configured in each area.
