Sensitivity labels from Microsoft 365 (M365) Information Protection stack can also be used on containers like SharePoint (SP) Sites and M365 Groups. In this blog we will walk through the steps to configure an existing label to include Groups and Sites, thus making it available for use when provisioning a new SP Site or M365 Group.
For steps to create and publish a new label please follow my Sensitivity Labelling blog.
Note: Please be aware when editing an existing label, the changes can take up to 24 hours to take effect whereas with a new label there is a 15-minute waiting period.
Applying a sensitivity label to a container provides the following controls:
- Override the sharing setting inherited from tenancy level SP sharing setting. It makes sense to enable this control only if the sharing setting must be overridden from the tenancy level default
- Set the privacy settings of Teams and M365 Groups
- Allow M365 Group Owners the ability to add external guest users as members of the M365 Group
- Manage the level of access a user has from an unmanaged device, this uses Azure AD (AAD) Conditional access (CA) policies
To be able to use the AAD CA protection feature, the “Unmanaged devices” access control policy in the SP tenancy must be configured with “Allow limited, web-only access” or “Block access”. When one of these options are chosen, M365 automatically configures two CA policies in AAD. These are pre-fixed as “[SharePoint admin center]”. Without these policies the AAD CA protection option for sensitivity label does not work. It is easier to have tenancy level configuration in SP set to “Allow limited, web-only access”, which is less restrictive, and then use “Block access”, which is more restrictive, within the protection settings of the sensitivity label to make it more effective. Alternatively, do not select the AAD CA protection feature for the sensitivity label and just rely on the default AAD CA policies.
THE BENEFITS
The benefits of applying a sensitivity label include:
- Uniform external sharing experience for the end users across any site which has the label applied
- Flexibility in configuring external sharing settings for various SP sites. Certain sites may host data which requires stricter access and external sharing capabilities
- Delegation management of sharing and access control to the site and group owners
CONTAINER LABELLING IN ACTION
Content does not inherit the label from the container, giving users flexibility to label the content with a higher or lower priority, or they can choose to not apply a label. For this example, we will begin by editing an existing label called “Confidential”.
1. Provide a meaningful description which helps both end-users and administrators
2. Tick Groups and sites as we want to be able to use the “Confidential” label on M365 Groups and SharePoint sites
Note: This label was previously configured to protect files and emails by marking the content. We are not changing this protection configuration.
We are not configuring auto-labelling
Since Groups and sites was used, we are presented with options to choose which protection settings to configure next. For this example we will focus on External sharing and Conditional Access settings.
3. For external sharing, we want the sites with “Confidential” label to be more restrictive than the tenancy level setting of “New and existing guests”. For AAD CA we will leave the setting configured at “Allow limited, web-only access” which is also the default tenancy level setting in SP
We are not configuring the auto-labelling feature
4. Review the settings before committing
5. Before publishing the label, create an M365 group called “CONFIDENTIAL Users” to group users who will be allowed to use the label. However, please be aware Security Group is not available for publishing the label to, it must be a M365 Group.
Also please do not confuse publishing a label with assigning a label to an M365 Group.
6. Select “Confidential” label for publishing
Only M365 Groups are listed. Security Groups cannot be used for publishing
When a user removes or replaces this label, we ask for a justification text
Since this is the only label selected in this publishing policy, we are not setting a default label to use. Ideally it would make sense to have a default label which is lower in priority and then let the user change it to a higher priority one. Alternatively, the auto-labelling feature can be configured to suggest an appropriate label based on the content being generated by the user.
7. Set an appropriate name description for the publishing policy
Once a new policy is created it can take up to an hour for the publishing to take effect
8. Since we have a label configured and published, create a SP site using the label. Observe how SP tenancy level sharing setting is set to “New and existing guests”
9. Now create a new SharePoint site and assign the “CONFIDENTIAL” sensitivity label
It can take up to 15 minutes for the site to be created with all the settings applied and ready for use. We must wait and not make any further configuration changes until all the settings have been applied by M365. In this example I have made Alex Wilber the owner of the site.
Once the site has been created, we would expect the External sharing setting to be lowered to “Existing guests” from the tenancy default of “New and existing guests”. However, as I mentioned earlier the change does not take effect for 24 hours as demonstrated in the screen shot below:
After 24 hours of waiting, the site’s External sharing setting changed automatically to “Existing guests” as per the screen shot below:
10. Now, let’s provide users from the “CONFIDENTIAL Users” M365 Group, with members permission on the site. Thus, allowing the users to add, edit and share content in the site
This is a side-track from the purpose of this blog, however it is important to highlight the most efficient method for configuring site access.
There are multiple ways to achieve the site access configuration. An Azure AD admin can add individual users as members of the “Trade Secrets” M365 Group created when the site is provisioned. With this method, the administrator will have to refer to the “CONFIDENTIAL Users” M365 Group members list.
The owner of the site can bulk add users from “CONFIDENTIAL Users” as members of “Trade Secrets” M365 Group, thus giving all the individual users edit permission on the site. This can be done from Outlook by selecting the invitation email, where you will be able to see the “Group” menu bar. This exposes the functionality to add members to the site’s M365 Group. Through this method all the members from the source group are automatically added and the owner can then choose to remove specific users or elevate their permissions if needed.
Observe how all members from source “CONFIDENTIAL Users” M365 Group have been added and the owner has the ability to drop a user or provide owner permissions.
11. The final option is to add the “CONFIDENTIAL Users” group to the site’s SharePoint group. This is the recommended way of assigning permissions in SP as the permissions are evaluated for the group and not individual users which makes it more efficient. When a user is removed from the group in Azure AD, they automatically lose access to the site and its content
Observe how the site has been labelled as “CONFIDENTIAL”
12. Now the setup is in place; we test external sharing as a member of the site by inviting:
- An external user who does not exist in AAD
- An external user who exists in AAD
Observe how AAD CA protection has kicked in and made the user aware of the limited capabilities.
Observe the difference in features available on the content when accessing from an unmanaged device
The user is unable to share content with an external user who does not exist in AAD
The user is allowed to share content with an external user who already exists in AAD
The user is unable to share the site with external user who does not exist in AAD
The user is allowed to share the site with external user who already exists in AAD
As you can see, by applying a label at the container level, additional protection features can be easily invoked to protect the container and its content.
Additional background on Information Protection through Identity is available in this blog by Lee Foster, Global Head of Advisory at Insentra.
