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.

Defining collaboration restrictions for Azure AD
Figure 1: Defining collaboration restrictions for Azure AD

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).

Create a new conditional access policy to control guest access from a template
Figure 2: Create a new conditional access policy to control guest access from a template

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.

Setting a sensitivity label to block guest access
Figure 3: Setting a sensitivity label to block guest aceess

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.

Guest settings in the Teams admin center
Figure 4: Guest settings in the Teams admin center

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.

About the Author

Tony Redmond

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He is the lead author for the Office 365 for IT Pros eBook, the only book covering Office 365 that is updated monthly to keep pace with change in the cloud. Apart from contributing to Practical365.com, Tony also writes at Office365itpros.com to support the development of the eBook. He has been a Microsoft MVP since 2004.

Comments

  1. Jakke

    It seeems to me that there extra license needs when adding guest accounts….

  2. Angelo Cassano

    Excellent blog Tony. Thank you for the ideas on how to contain guest sprawl.

  3. Anil Kumar

    Thanks for the explanation. A quick question regarding cleanup, We tried to use Azure AD Sign in logs to cleanup inactive accounts and as they only store 30 days of activity we couldn’t rely on them as it’s a short span. Do you have any other parameters on how to find the inactive accounts

Leave a Reply