Using Office 365 Sensitivity Labels with Teams, Groups, and Sites
Sensitivity Labels Replace Older Text-Only Classifications
Microsoft announced the preview of support for Office 365 sensitivity labels in Teams, Groups, and (SharePoint Online) sites at the Microsoft Ignite 2019 conference. Sensitivity labels have been around since 2018. In that time, Microsoft has gradually increased their usefulness in terms of applying visual markings to sensitive information and, if necessary, protecting that information with rights-management based encryption. Following private tests, the preview is now public and available to any tenant that wants to participate.
Update June 19: Microsoft announced that container support for sensitivity labels is now generally available with roll-out due to complete in early July.
Not all group-enabled Office 365 applications support sensitivity labels yet. The big ones that do are Teams, OWA, and SharePoint Online. You can also assign labels to groups in the SharePoint admin center and Azure Active Directory portal.
Containers and Labels
What’s new is that you can use the same sensitivity labels defined to mark or protect individual files to mark “containers,” literally a team, group, or SharePoint site. This capability replaces the previous markings by text-only visual classifications defined in the Azure Active Directory policy for Groups. Labels serve the same purpose as classifications (which are not being deprecated at this point) in that users see a visual marker (like “Secret” or “Confidential”) to remind them of the importance or sensitivity of the information stored in a container. In addition, sensitivity labels have the extra benefit of being able to impose access controls on the containers. You can, for instance, assign a label to a team to stop the team owner being able to invite guests from outside the tenant to join the team membership.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
It’s important to realize that sensitivity labels applied to the container level do not affect the individual messages, conversations, and files stored in these containers. You can certainly assign sensitivity labels to individual files stored in document libraries, but these assignments are independent of anything applied to the container.
Updating Sensitivity Labels for Groups
Before we assign sensitivity labels to containers, we should make sure that the labels have the necessary settings. You can apply a label that doesn’t have group settings to a container, but it won’t do anything except be a visual indicator of the container’s sensitivity (which is what you might want).
Go to the Security and Compliance Center and edit each of the set of labels you want to use with containers. As you can see in Figure 1, the settings are:
- Privacy: Controls if the group is public (anyone can join) or private (members must be invited to join).
- External user access: Controls if the group membership can include guest users. If you block guest users for the group, it assigns an Azure Active Directory policy to the group and sets the value of AllowedToAddGuests to $False. Blocking external access does not remove existing guests from the group membership: it only blocks the addition of new guests.
- Unmanaged devices: Controls access members have to content in the SharePoint site belonging to the group when they connect from unmanaged devices.
Before you can use labels with container, you must identify the labels that you want to use with containers and update them with the container settings. Typically, an organization will have relatively few labels to update, so this shouldn’t take long.
Checking that Sensitivity Labels Work with Groups
Once you’re happy that suitable sensitivity labels are published and available within SharePoint Online, Exchange Online, and Teams, you can check that their settings work as expected with Groups, Teams, and SharePoint sites.
In Figure 2, we’re using OWA to edit the settings for an Office 365 group and have selected the Confidential label. The label settings controlling the privacy (private) and access to guest members (none) are active. If I try to edit the membership and add a guest, Outlook will decline the addition. To change the privacy and access, we need to assign a label that allows a group to be public and welcome guest members.
When you create or edit containers in a supported app and apply a sensitivity label, the app respects the settings inherited by the labels. Background synchronization between Office 365 workloads ensures that a label applied in one app is picked up and respected by the other apps.In Figure 3 we see the SharePoint settings for the same group as seen through the SharePoint admin center. The same sensitivity label is present.
Filtered and Default Labels
It’s likely that some of the sensitivity labels defined in an organization are inappropriate for containers. This is natural because up to now, the purpose of the labels has been to mark documents. In Figure 3, the Secret label is appropriate for both documents and containers, but another label specifically designed to mark email might not be.
To stop labels being displayed for container labeling, make sure that the Site and Group slider for the label is off. Once this is on, the label is available for containers. In addition, you should update the label description and tooltip to make it clear to users how you expect the label to be used.
Another potential issue is that there’s no way to enforce mandatory labeling for containers or to assign a default label to containers. Again, this is an area that Microsoft will probably change in the future. For now, you can use PowerShell to search for non-labelled groups and assign a default label. The Set-UnifiedGroup and Set-SPOSite cmdlets both support assigning labels today, and the Set-Team cmdlet should do so in the future.
Gotchas with Guests
When you create a new Office 365 Group with OWA, you can choose a label to apply to the group. However, if you select a label that blocks guest access, you can still add guests to the membership of the new group. This is because OWA does not respect the label settings until after the new group is created. If you add guests to the membership, their presence is synchronized to SharePoint Online and Teams.
Teams takes a different approach. When you create a new team, you select the sensitivity label and Teams applies the settings immediately so you cannot then add guests to the new team if prohibited by the label. SharePoint Online doesn’t allow you to add guest members via the browser interface. A label assigned to a team also applies to any private channels belonging to the team and the SharePoint sites associated with those channels. Currently, you can’t assign a sensitivity label to a team using the Graph API or when you create a new team from a template.
In all cases, assigning new label settings to a team or group does not affect the existing membership. Guests are not summarily ejected when a label barring guest membership is applied to a group.
Extending the reach of sensitivity labels over containers makes these labels more powerful and useful. Where before you might look at sensitivity labels as a solution for protecting confidential documents with rights-management based encryption, now they become a management tool to enforce policy over Groups, Teams, and SharePoint Online. That’s a pretty big deal when you think about it.