Keeping Confidential Information Secret
Many SharePoint Online sites belonging to Microsoft 365 Groups and Teams hold confidential information that you might not want to share with guest users. When Microsoft first supported guest users for Office 365 Groups (now Microsoft 365 Groups) through Azure B2B Collaboration, the focus was on allowing guests to collaborate with tenant users through email and shared documents. Over time, apps like Teams and Planner included support for Azure B2B Collaboration and increased the amount of data available to guests. The issue often encountered now is how to keep organizational secrets when using collaborative applications.
Controlling Guest Access
In the early days of Office 365 Groups, there wasn’t much that group members could do to protect confidential information from guests. The Groups membership model is very simple. All members enjoy equal access to group content. This led to the creation of many additional groups to segregate information which needed to stay internal with that which could be shared externally.
As time went by, Microsoft introduced functionality to help. A range of options now exist:
- Groups and Teams blocked against guest access. By restricting membership to tenant users, you create conditions for unfettered internal discussions and sharing. The block is imposed by updating the properties of the group in Azure AD to prevent group owners adding guest members. An administrator can update the group properties manually or the group can inherit the block when a group owner or administrator assigns a sensitivity label with the appropriate restriction to the group.
- Inside a group with guest members, sensitivity labels with encryption can stop specific members (guests and perhaps some internal users) accessing sensitive documents in the group’s document library. Access rights defined in the label control who can interact with documents, and if guests aren’t assigned rights in a label, they cannot open any document assigned that label. This method is an effective block, but it does go against the general philosophy that members share equal access to group resources. Remember that document metadata is not encrypted by sensitivity labels, so guests will be able to see document titles and authors.
- Private Teams channels avoid the need to create a new group by establishing barriers to sharing within teams. Private channels are restricted to a subset of team members, such as only tenant users. Anything shared in a private channel is only available to the members of the channel, including documents stored in the SharePoint Online team site for the channel.
- Shared Teams channels aren’t yet available. These channels don’t use Azure B2B collaboration, so don’t depend on guest accounts to control external access. Instead, tenants will agree to federate to allow users to work together in shared channels, including access to the SharePoint Online team sites used by the channels (just like private channels, each shared channel has its own site). When shared channels become generally available, we will know how to control access to sensitive information stored in these channels.
With these options in mind, the best approach might be to stop guest users getting into sensitive groups in the first place. As noted above, this is possible by blocking the ability of owners to add guests to their groups and teams at a group level. Administrators can always add guests if needed.
Controlling Group Policy Settings
The Azure Active Directory policy for Groups holds settings for how Microsoft 365 Groups behave in a tenant. One of those settings is AllowToAddGuests, which is True if the tenant allows guests to be members of groups, and False if you want to block guests. This policy covers all groups and is managed through PowerShell. If the tenant policy allows guests users, the properties of individual groups can be amended to block access to those groups.
Today, sensitivity labels are the best method to controlling guest access. A sensitivity label can hold several container management settings, including guest access and the external sharing capability for SharePoint. Applying the label to a group forces the inheritance of the container settings, and if the settings dictate a block for guest access, the group’s AllowAddGuests property is set to #False. Sensitivity labels are available in the Office 365 E3 and E5 plans.
Using Classifications to Block Guest Access
If you choose not to use sensitivity labels, you can use group classifications to mark confidential groups and update the properties of those groups to block guest access. A classification is a text value defined in the ClassificationList setting of the Groups policy. Classifications are visual markers intended to convey to users what kind of information a group holds. They do not affect how a group or team works, nor does a classification protect content or place any restriction on how that content is used. Adding or updating a new classification or removing a classification from the list does not affect classifications placed on existing groups.
Let’s assume that you define a “Secret” classification to mark confidential groups (or teams). After classifying the secret groups (using PowerShell or client UIs), we can use PowerShell to scan for and block guest access for those groups.
The first step in the example code creates a set of groups classified as “Secret.” The code then loops through each group to discover whether group-specific policy settings are in place. If so, the code updates the settings to block guest access. Groups that don’t have a policy setting are controlled by the tenant policy, so the first step is to create policy settings for the group. We can then update the setting to block guest access.
$GroupTemplate = (Get-AzureADDirectorySettingTemplate | ? {$_.DisplayName -eq "Group.Unified.Guest"})
$Groups = (Get-UnifiedGroup -ResultSize Unlimited | Where {$_.Classification -eq "Secret"})
ForEach ($Group in $Groups) {
$GroupSettings = Get-AzureADObjectSetting -TargetType Groups -TargetObjectId $Group.ExternalDirectoryObjectId
if($GroupSettings) {
# Policy settings already exist for the group - so update them
$GroupSettings["AllowToAddGuests"] = $False
Set-AzureADObjectSetting -Id $GroupSettings.Id -DirectorySetting $GroupSettings -TargetObjectId $Group.ExternalDirectoryObjectId -TargetType Groups
Write-Host "External Guest accounts prohibited for" $Group.DisplayName
}
Else
{
# Settings do not exist for the group - so create a new settings object and update
$Settings = $GroupTemplate.CreateDirectorySetting()
$Settings["AllowToAddGuests"] = $False
New-AzureADObjectSetting -DirectorySetting $Settings -TargetObjectId $Group.ExternalDirectoryObjectId -TargetType Groups
Write-Host "External Guest accounts blocked for"$Group.DisplayName
}
}
To check that the block for guest access is in place, we can create a list of the groups blocked from having guest members. To do this, run the Get-UnifiedGroup cmdlet to check the AllowAddGuests property, which is $False if the group is blocked. For example, this command reports the display names and classification for all blocked groups. Remember that the block works for all clients that populate group membership, including Teams.
Get-UnifiedGroup -ResultSize Unlimited | ? {$_.AllowAddGuests -eq $False } | Format-Table DisplayName, Classification
It’s critical to realize that applying a block on guests to a group does nothing to remove existing guests. If you want to eject existing guests, you need to do that separately.
Multiple Secret-Keeping Techniques
Multiple approaches are available to block guests from accessing content shared in Teams and Groups. The most fundamental is to block guest access completely, but if guests are already present, consider using Private channels in Teams or limit access to confidential documents with sensitivity labels and encryption.