Five Practical Actions to Control Guest Accounts for Microsoft Teams

After five years or so of adding guest accounts to Microsoft Teams, your Azure AD might just be a tad cluttered. And like any maintenance, it’s easier when things are set up right from the start. With that thought in mind, I want to cover five recommendations I make to tenant administrators when I talk about the challenge of managing guests.

Define Where Guests Can Come From

Azure AD won’t allow applications to invite external people to become guests in the tenant if their domain is blocked. The external identities blade of the Azure AD admin center includes a section called External collaboration settings. Under Collaboration restrictions, administrators can define settings for the tenant Azure B2B Collaboration policy. Basically, a tenant can:

• Allow guests to come from any domain.
• Allow guests to come from selected domains (a whitelist).
• Block guests from selected domains (a blacklist).

You can’t have a mixture of blocks and allows. The policy is either open, a blacklist, or a whitelist. In Figure 1, I’m configuring a blacklist which denies access to consumer email accounts. In other words, in this tenant, we only allow guests with corporate email accounts. You might also want to include the domains of direct competitors in your blacklist.

Azure AD applies the block when applications attempt to add guest accounts. However, the Azure B2B Collaboration policy is not retrospective. It will block new invitations to guests from the blacklisted domains, but it will not remove existing guests from those domains. If you want to remove those guests, you can write some PowerShell to scan Azure AD for guests from the offending domains and remove the accounts. For instance:

$BadAccounts = [System.Collections.Generic.List[Object]]::new()
[array]$Guests = (Get-AzureADUser -Filter "UserType eq 'Guest'" -All $True| Select Displayname, UserPrincipalName, Mail, ObjectId | Sort DisplayName)
ForEach ($Guest in $Guests) {
    If (($Guest.Mail.Split("@")[1]) -eq "Gmail.com") { 
       $BadAccounts.Add($Guest.UserPrincipalName) }
} #End Foreach
If ($BadAccounts) { Write-Host ("Removing {0} bad accounts" -f $BadAccounts.count) }
ForEach ($BadAccount in $BadAccounts) { Remove-AzureADUser -ObjectId $BadAccount }

Impose Multi-Factor Authentication

Before any guest account accesses your tenant, you can use a conditional access policy to enforce multi-factor authentication (MFA) for guest users. Remember, guests might have access to confidential information in Teams chats and channel conversations or documents in SharePoint and OneDrive for Business (or even Microsoft loop components). Your tenant gets to decide if MFA applies, even if the guest can sign into their home tenant using a simple username and password.

My experience of having a guest account in other tenants is that MFA is necessary in roughly 50% of the cases, including Microsoft’s tenant. If this restriction is good enough for Microsoft, it should be good enough for you. It’s straightforward to create a conditional access policy to require guests to use MFA, and Microsoft has made it easier by including a suitable template in the set of prototype conditional access policies available now in preview (Figure 2).

Block Sensitive Teams

Some teams should never admit guest members. The easiest way to stop guests joining these teams is to block guest access with a sensitivity label. Apart from being able to encrypt content, sensitivity labels can apply management settings to containers like teams. One of those settings blocks guest access. If you configure a sensitivity label so that group (team) owners cannot add people outside the organization (Figure 3), Teams won’t let anyone invite a guest to join the group.

Assigning a sensitivity label which blocks guests to a team won’t remove any existing guests, so you might need to write some PowerShell to scan for teams with a specific label to check their membership and remove guests.

Another thing to remember is that a team owner can change a sensitivity label and by doing so, could allow guest members back into the team. Once again, PowerShell can help by monitoring changes to sensitivity labels and reverting to the original label if necessary. You should check that the proper sensitivity labels are in place periodically.

If your tenant doesn’t support sensitivity labels, you can still block guest access by updating properties of the underlying Microsoft 365 group. For instance, let’s assume you want to block guest access to a team called Practical 365 Editorial. We could this with the following PowerShell commands:

$ObjectId = (Get-UnifiedGroup -Identity “Practical 365 Editorial”).ExternalDirectoryObjectId
$Template = Get-AzureADDirectorySettingTemplate | ? {$_.DisplayName -eq "Group.Unified.Guest"}
$Setting = $Template.CreateDirectorySetting()
$Setting["AllowToAddGuests"] = $False
New-AzureADObjectSetting -TargetType Groups -TargetObjectId $Objectid -DirectorySetting $Setting

Assigning a sensitivity label to control guest access updates the group properties in the same manner.

Control What Guests Do

The Guest access section of the Teams admin center includes the ability to turn guest access off for all teams. But if the tenant permits guest access for some teams, you might want to control what guests can do. Some of the available controls (Figure 4) are relatively unimportant (like allowing guests to use stickers and Gifs in conversations). Others are worth more discussion.

For instance, do you want guests to be able to chat with tenant users or confine them to channel conversations? Will you allow guests to edit their own sent messages (please do!). And can they delete messages and chats (maybe not). There’s no harm in starting off with all controls enabled and throttling back later if you encounter problems.

Remove Inactive Guests

In another article, I cover the need to look for and remove inactive guests. People invite guests to join teams for a myriad of reasons. Some memberships are enduring and remain active over long periods. Some members are transitory and cease activity after just a day or so. It all depends on why an external person joined a team and what function they served once a member.

There’s no doubt that tenants that allow guests to join teams accrue guest debris over time. I can see it in my own tenant, and I know it from being a guest in other tenants. People can manage their membership in other tenants through Teams, but it’s unwise to expect anyone to remove their guest account from your tenant. There’s just too much else to do and too little time to do it, and it’s doubtful that anyone (except anal retentives like myself) considers maintenance of their set of guest memberships to be a high-priority activity.

Unused and inactive guest accounts cluttering up Azure AD don’t do any great harm, especially if you secure access with MFA, but they can slow down PowerShell and Graph queries against Azure AD. Anyway, who wants to keep old baggage around. Do the right thing and clean up inactive guest accounts.

Simple Steps

Blocking guests from unwanted sources, insisting that guest connections are secure, stopping guests getting into sensitive teams, controlling what guests can do, and cleaning up guest accounts regularly are all simple steps. Consider what you can and should do in the context of your tenant, and you’ll be well on the way to successful management of guest account activity in your tenant.