Make Sure You Have the Right Information Protection Licenses

According to Microsoft 365 message center notification MC736438 (13 March 2024), Microsoft plans to take a more robust attitude to requiring administrators and users to have premium licenses to apply sensitivity labels automatically via policies or by defining a default sensitivity label for SharePoint Online document libraries. Until now, Microsoft has had a published license requirement that administrators should have complied with. In early April 2024, software checks will ensure that the right license is in place before automatic labeling works.

Microsoft says that they’re issuing the notification “as a reminder to ensure your admins and users who use Information Protection sensitivity labels have the required licenses.” In other words, it’s time to make sure that people have the right licenses before code stops them doing something that they’ve been doing for some time.

Manual Versus Automatic Labeling

The basic difference between manual labelling and automatic labeling comes down to licensing. Manual labeling means that a user chooses and assigns a sensitivity label to a document without any assistance. Automatic labeling means that code decides when to apply a sensitivity label. Manual labeling always takes precedence as a user can decide to assign a different label to a document that receives a sensitivity label through policy.

The basic rule is that to use manual labeling, a user account must have an Office 365 E3 or above license. To use automatic labeling, they need Office 365 E5 or above. Variations exist, so it’s wise to check the current documentation setting out license requirements for sensitivity labels.

Information Protection License Enforcement

Microsoft implemented the license requirement for new tenants in January 2024. They’ve allowed older tenants an extra three months’ grace period to sort their licenses out. Of course, it’s human nature to ignore anything unpleasant until it’s absolutely necessary to deal with it. That point is fast approaching as the existing functionality will continue working until early April 2024 and terminate thereafter.

Microsoft says that if administrator accounts that manage sensitivity labels do not have the required licenses, they will be unable to manage sensitivity labels and policies. I think this overstates the case. An Office 365 E3 license allows an administrator to create, update, and publish sensitivity labels. It does not allow them to publish labels in an auto-labeling policy, and that’s a totally different scenario to what you might term regular sensitivity label management. In addition, existing auto-labeling policies will continue to run. They just can’t be updated by administrators without the necessary licenses.

Microsoft goes on to say that if end users do not have the required licenses “they will no longer be able to apply labels.” Again, this statement appears to be misleading. Users with Office 365 E3 licenses have the right to manually apply sensitivity labels to files stored in SharePoint Online and OneDrive for Business and to Exchange Online messages. What they will lose is the ability to assign a sensitivity label automatically to new content when a document library has a defined default sensitivity label. Although I haven’t seen the new behavior in action, I imagine that SharePoint Online will ignore the default label and leave it to the user to assign a label.

The Point of Licensing

Quibbling about what will happen is all very well. What’s obvious is that Microsoft is implementing software checks to restrict Purview functionality to those who have the preordained licenses. There’s nothing to complain about here. Microsoft sets the licensing rules and you either pay up for premium functionality or use whatever’s covered by the licenses held by the tenant.

Make sure that you’re not surprised about changes that appear inside Microsoft 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Sensitivity Label PDF Support Increases Coverage for Protection

In my review of sensitivity labels for 2023, I noted that the only way to apply a sensitivity label direct to a PDF was with:

• The paid-for versions of Adobe Acrobat.
• Generating PDFs from Office documents (subscription apps only).
• Applying a label through the unified labeling client.

Unlike retention labels, it wasn’t possible to apply a sensitivity label to a PDF using the SharePoint Online browser client. Now it is, and it’s an important update given the widespread use of PDFs within Microsoft 365. Between Office documents and PDFs, sensitivity labels can now protect over 90% (my estimate) of all files stored in SharePoint Online and OneDrive for Business. It’s another step to making PDFs a fully functional format within the Microsoft Information Protection ecosystem.

What Sensitivity Label PDF Support Means for SharePoint Online

In an update announced by principal program manager Sanjoyan Mustafi on LinkedIn, the preview of SharePoint Online support for PDFs is available to all commercial tenants worldwide. Support extends to sensitivity labels with predefined permissions. Labels with user-defined permissions or those that use Double Key Encryption (DKE) are unsupported.

Supporting sensitivity labels for PDFs means that people can use SharePoint Online and OneDrive for Business to:

• Apply sensitivity labels to PDFs through the browser interface (Figure 1) and amend or remove the label afterwards, including forcing the user to provide justification if required by policy. This includes applying the default sensitivity label defined for a document library to PDFs as users load them into the library (requires the SharePoint-Syntex advanced management license).
• Apply sensitivity labels to PDFs stored in SharePoint Online and OneDrive for Business through auto-label policies. This feature is covered in message center MC644060 (14 July, 2023).
• Apply sensitivity labels to PDFs using the assignSensitivityLabel Graph API (if your app has permission to do so).
• Display the names of sensitivity labels for protected PDFs in document libraries.
• Index the content of PDFs protected by sensitivity labels. This supports Microsoft Purview solutions like Data Loss Prevention, content searches, and eDiscovery.

Like Office documents protected by a sensitivity label with encryption, SharePoint Online can’t display a thumbnail of a protected PDF (Figure 2). I believe that this has something to do with the inability to fetch the necessary use license to decrypt the file. Thumbnails are shown for PDFs assigned a sensitivity label with no encryption. To open a document, use the Edge browser (which supports reading protected files) or download the file and use an app that understands how to open protected PDFs (like Acrobat).

I hear that Microsoft is working on the viewing issue and expects to have a fix by the end of 2023.

Enabling Sensitivity Label PDF Support for SharePoint Online

By default, SharePoint Online support for PDFs is disabled. To enable support, load the SharePoint Online administration PowerShell module and run the Set-SPOTenant cmdlet. You’ll need a recent version of the module (use this script to update your Microsoft 365 modules to the latest version):

Set-SPOTenant -EnableSensitivityLabelforPDF $True

To revert, run the command to update the setting to $False.

Set-SPOTenant -EnableSensitivityLabelforPDF $False

Disabling SharePoint support for PDFs has no effect on PDFs with sensitivity labels. It will stop users being able to assign or update labels through the SharePoint Online and OneDrive for Business browser interfaces and SharePoint Online will cease indexing protected PDF content.

If you don’t want to use PowerShell, check the Information protection section of the Purview compliance portal, and go to Auto-labeling. You might see a message inviting you to turn on support for PDFs. If you do, select Turn on now and the job is done.

More information about PDF support for sensitivity labels in SharePoint Online is available in Microsoft documentation.

Sensitivity Label PDF Support is an Important Step Forward

I don’t think it is an exaggeration to say that some organizations have been waiting years for PDF support to arrive in SharePoint Online. Given the widespread use of PDFs in many organizations, this is an important step forward for those wishing to protect their most sensitive information stored in SharePoint Online and OneDrive for Business.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Sensitivity Bar Informs Users About the Labeling Status of Office Documents

I guess I was surprised when I saw message center notification MC515530 appear on February 15 all about the new sensitivity bar (or sensitivity labeling bar) for the Microsoft 365 apps for enterprise (the subscription version of the Office desktop apps). The surprise didn’t come from not knowing about the bar, because I’ve been using it for months as it’s in the Current Channel Preview release. It’s more that it seems to have taken forever to get a relatively simple (and good) change to general release. The update is Microsoft 365 roadmap item 88517 and will appear in the standard release of Word, PowerPoint, and Excel in March 2023. The Microsoft 365 Insider blog (September 20, 2022) explains how the sensitivity bar works.

It makes sense to show users details of the sensitivity label applied to a document. Office apps show the information shown in Figure 1 when a user clicks on the file name in the application window. You can update the file name, choose a different sensitivity label, save the file to a different location, or see the version history. This functionality is available even if you choose to hide the sensitivity bar (see below). What we’re concerned about here is the addition of the sensitivity label name and the colored shield in what’s displayed.

The display of the sensitivity label name in the sensitivity bar now means that Office apps display sensitivity labels in three separate places in the UI: the bar, the sensitivity button, and in the information bar at the bottom of the screen. The lock icons shown in the sensitivity and information bars are visual indicators that the sensitivity label protects the document with rights management.

Eliminating the Unified Labeling Client

Introducing the sensitivity bar is part of Microsoft’s ongoing effort to eliminate the unified labeling client (also known as the Azure Information Protection client). This add-on client was the original software installed to allow users to label Office documents and it included an information bar to display label properties.

The Office apps include native labeling capabilities, meaning that they include the necessary Microsoft Information Protection code to interact with labels, apply rights management encryption, and so on. Native protection means that there’s no need for an add-on client, but before it’s possible to transition all customers off the unified labeling client, Microsoft needs to provide equivalent functionality in the Office apps. Microsoft has been working to give the Office desktop apps equivalent functionality to that gained by installing the unified labeling client since at least 2018. A big step forward happened in 2019 when the Office apps gained native protection support. Now we’re in the final stages of the process when tweaks to the UI like this one and the introduction of colors for sensitivity labels apply the final fit-and-finish.

Hiding the Sensitivity Bar

If you don’t want the Office apps to display sensitivity label names, you can amend the label policy that publishes sensitivity labels to users to add a setting to hide the sensitivity bar. Microsoft’s documentation suggests that this might be appropriate if people use very long file names and want to see that information displayed (they can always see information about labels through the Sensitivity button).

In any case, you can’t disable the sensitivity bar through the Purview compliance center. Instead, run these PowerShell commands to connect to the compliance endpoint, select all label policies, and add the setting:

Connect-ExchangeOnline
Connect-IPPSSesssion
[array]$LabelPolicies = Get-LabelPolicy
ForEach ($Policy in $LabelPolicies) { 
  Set-LabelPolicy -Identity $Policy.Name -AdvancedSettings @{HideBarByDefault="True"}
}

To check the setting, run:

Get-LabelPolicy | Format-List Name, PolicySettingsBlob

You should see the setting shown like this:

<setting key="HideBarByDefault" value="True" />

Figure 2 shows the effect, which is quite subtle. Everything that was there before is still present but the label is now represented by a colored shield (meaning it’s a protected document) instead of the shield and label name.

To reverse the setting, set its value to False. The Office apps pick up changes made to label policies the next time they refresh their label cache, so it might take several hours before apps hide the sensitivity bar.

Useful Change for Those Interested in Sensitivity Labels

For most users, the addition of the sensitivity bar is a minor improvement that I find useful (but maybe only because I label every document). The bar serves a useful purpose in highlighting the presence of a sensitivity label (which might have been applied automatically by a label policy), and might help to raise awareness about the need to exercise care when handling confidential information. On the other hand, the sensitivity bar might fade into the background like many other elements of the Office GUI that people only access when they really need to. Of course, if your organization doesn’t use sensitivity labels, you don’t need to worry about the sensitivity bar.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Privacy and Protection Might Not be Enough

MVP Ingo Gegenwarth’s post about Outlook and private items is a good example of the problems which arise when user assumptions running into software limitations. The assumption is that if you mark an item as private, only you can see its contents. The limitation is that it depends on clients containing code to respect private items. Some do, and some don’t, much to the chagrin of users when they find out.

Delegate Access to Protected Email

Similar confusion exists around protected email which arrives in a user mailbox and is read by a delegate. Email protected by a sensitivity label uses rights management to know what a user can do with the content. If they don’t have the right to view the encrypted content, the mail client shouldn’t open the message. But if someone has delegate access to a user or shared mailbox, they might be able to read protected messages. It all depends on the client used and the rights assigned in the sensitivity label.

For instance, here’s an example where a protected message arrives in a mailbox. The delegate (full mailbox access) can read the protected message with OWA (left), but not with Outlook desktop (right). They can also read the message with Outlook mobile if they add their delegate account there.

Change Coming for Some Outlook Clients

In their FAQ for protected email, Microsoft says:

“Is delegated access supported with opening encrypted messages? Even if a delegate has full access to another user’s mailbox?

Delegated access of encrypted mail is supported in Outlook on the web, Outlook for Mac, Outlook for iOS, and Outlook for Android. Outlook for Windows does not support delegated access.”

A change described in Microsoft 365 roadmap item 88888 appears as if it will help. The item says:

“Outlook will provide consistent access control on protected emails for delegates and shared mailbox members. For delegates or shared mailbox members, when they have full access of the owner’s mailbox but are not allowed to read encrypted email, Outlook will have a new setting to block the owner’s protected email access which covers ad-hoc encrypted email as well as email with protected MIP sensitivity labels.”

According to the roadmap, we will see this change in April 2022. However, it only applies to OWA, Mac, iOS, and Android. Outlook for Windows remains an outlier. And that’s the problem because Outlook for Windows is often the client of choice for administrative assistants who process email on behalf of others.

Protecting Confidentiality

Is there anything that can be done in the situation where the organization uses sensitivity labels to protect confidential email and documents and want to be sure that delegates cannot access this material? Well, you could remove OWA and Outlook Mobile access from delegate accounts to force them to use Outlook desktop, but that’s probably not realistic.

Instead, an old technique from on-premises Exchange might be useful. For executives who need the assurance that delegates cannot access protected email, you could create two accounts with mailboxes. Let’s take the example of the CEO. They would have:

• A primary mailbox accessed by the delegate to manage inbound email and the calendar. The mailbox appears in the GAL and is accessible to anyone in the organization (or maybe not, as the case demands).
• A hidden mailbox which only the owner can access. This mailbox is not listed in the GAL and is limited so that only certain people can send email to it. This mailbox is used for protected or other confidential email, so the rights assigned in sensitivity labels grant access to the hidden mailbox instead of the primary mailbox.

A certain amount of configuration to make sure that the two accounts work as planned. However, if protected email is sent to the hidden mailbox and only the owner of that mailbox accesses the email, there’s no chance that the delegate can see confidential material.

Yes, this is a pain. Delegate access to protected email should work better with Outlook for Windows. Let’s hope that Microsoft moves on this point soon. Perhaps it’ll be an example of their One Outlook strategy of bringing OWA features to Outlook desktop.

Two Notifications Mark a Special Update

A feature so good that it requires two identical message center notifications must be worthwhile. Such is the case for the ability of sensitivity labels container management to control the external sharing capability of SharePoint Online team sites, as announced in MC244217 and MC244216 on March 12. Both point to Roadmap item 70735.

Information Protection and Container Management

Sensitivity labels can include settings for information protection and container management. Information protection usually means that the assignment of a label to an Office document, Azure Purview data (preview), Power BI objects, or other files will encrypt the target content using Microsoft Information Protection (rights management). Container management means that labels impose settings on a Microsoft 365 group, including the team or SharePoint team site belonging to the group. A single label can include both information protection and container management settings and is therefore applicable to both files and containers, or the scope of the label can be one or the other use. I favor a restricted label scope because I think it makes labels easier to manage.

Container Management Settings

When Microsoft first introduced the ability of sensitivity labels to control container settings, a limited number of controls were available. You can configure a label to:

• Control access to the container to Azure B2B Collaboration guest accounts. Previously, this control over containers could only be set by updating the properties of the group with PowerShell. The options are to allow or block guest access.
• Set the access to be public or private. If a label is not present, the group owner can decide whether the group is public (available to any tenant user) or private (restricted to the group membership).
• Limit access to documents in a SharePoint when using unmanaged devices.

The set of available controls is useful and sensitivity labels are much better than the alternative (like text-based classifications), but Microsoft’s intention always was to expand the number of controls to make sensitivity labels a much more powerful policy-driven management method for containers. Adding control over the sharing capability for SharePoint sites is further evidence of their intent.

Controlling External Access to SharePoint Online Sites

Organizations often store confidential or sensitive documents in SharePoint sites. SharePoint Online supports four values for site sharing capability to control the degree of external sharing permitted for documents in a site:

• Disabled – allow no external sharing outside the organization.
• ExistingExternalUserSharingOnly – allow sharing only with the guest users already in your organization’s directory.
• ExternalUserSharingOnly – allow users to share documents with new external users, who must accept the sharing invitations and go through an authentication process to create a guest account.
• ExternalUserAndGuestSharing – allow sharing with all external users, and by using anonymous access links (Anyone links).

SharePoint Online administrators and site owners can set the sharing capability through:

• The SharePoint Online admin center.
• PowerShell, using the Set-SPOSite cmdlet to update the SharingCapability setting.
• And now, by assigning a sensitivity label which has the external sharing control configured.

Remember that SharePoint Online won’t allow you to assign a less restrictive access to a site than allowed by the tenant sharing setting. In other words, if the tenant explicitly blocks anyone access for all sites, assigning anyone access through a label will have no effect.

Setting External Sharing Capability in a Sensitivity Label

When editing a sensitivity label, administrators can define what sharing capability is set when an owner or administrator assigns the label to a site (Figure 1).

The Site Owner View

Not every site owner knows about admin tools, and a major benefit of controlling sharing capability with sensitivity labels is that it makes it easier for site owners to assign the appropriate level of sharing based on their knowledge of the content within the site. At least, that’s the theory, and a lot depends on the clarity of the names chosen for sensitivity labels. Ideally, the names should convey how sensitive the information stored in the site is (Figure 2).

Applying a sensitivity label to a group or team also applies it to the site and selecting a new sensitivity label for a site also applies it to the associated group and team.

PowerShell Support for Container Management

The PowerShell cmdlets to interact with sensitivity labels are available after connecting a session to the compliance endpoint. The easiest way to do this is to run the Connect-IPPSSession cmdlet from the Exchange Online management module.

Once connected, we can use the Get-Label cmdlet to find details of sensitivity labels and the Set-Label cmdlet to update their settings. For example, not all sensitivity labels are configured for container management, so to find the set of labels scoped for container management, run this code:

Connect-IPPSSession
$Labels = Get-Label
ForEach ($Label in $Labels) {
   If ($Label.ContentType -match "Site, UnifiedGroup") {
   Write-Host "Label" $Label.DisplayName "has container actions" }
}

Label Non-business use has container actions
Label General Access has container actions
Label Guest Access has container actions
Label Limited Access has container actions
Label Confidential Access has container actions

As an example of how to use Set-Label, here are two examples of updating labels to set different sharing capabilities.

Set-Label -Identity Confidential -AdvancedSettings @{sharingcapability="ExistingExternalUserSharingOnly"}
Set-Label -Identity Secret -AdvancedSettings @{sharingcapability="Disabled"}

After applying a label with a sharing capability setting configured to a site, SharePoint updates its sharing capability. You can check that the settings have changed with the Get-SPOSite cmdlet:

Get-SPOSite -Identity "https://office365itpros.sharepoint.com/sites/BlogsAndProjects/" | Select SharingCapability, SensitivityLabel

SharingCapability SensitivityLabel
----------------- ----------------
         Disabled 27451a5b-5823-4853-bcd4-2204d03ab477

Checking that Everything Works

Of course, it’s a good idea to check that the sharing capability set in a sensitivity label works after assigning the label to a site. Let’s assume that you assign a label which disables external sharing. The easy test is to see if sharing works. As Figure 3 shows, it is not allowed and you see one of SharePoint’s famous OSE errors.

Being able to control external sharing for SharePoint sites is just the latest control for sensitivity labels. Microsoft plans more in the future. With this in mind, if you haven’t already started using sensitivity labels, perhaps now is a good time to make a start?

Read Protected PDF with Edge is Useful Feature

In December 2018, Adobe and Microsoft announced support in Adobe Acrobat Reader for PDF files protected with Microsoft Information Protection. An older format for protected PDFs (ppdf) was replaced by one based on V1.7 of the ISO specification for PDF, which allows for rights-management based protection of the kind used by Microsoft Information Protection (MIP) sensitivity labels.

Applying Sensitivity Labels to PDFs

You can’t apply sensitivity labels to PDFs inside an Office 365 app (you can using the paid-for versions of Adobe Acrobat). Instead, you apply labels through the Classify and protect option that’s added to Windows File Explorer when the Unified labeling client is installed on a workstation. Explorer launches the client to apply a label to the PDF (Figure 1).

You can also apply a label with PowerShell using the Set-AIPFileLabel cmdlet, which is installed with the unified labeling client. You can find the GUID for a sensitivity label with the Get-Label cmdlet.

Set-AIPFileLabel -Path "c:\temp\July 9 - Protected.pdf" -LabelId 81955691-b8e8-4a81-b7b4-ab32b130bff5

FileName                        Status Comment
--------                        ------ -------
c:\temp\July 9 - Protected.pdf Success

Finally, you will soon be able to apply sensitivity labels to PDFs by defining a default sensitivity label for SharePoint Online document libraries. This feature already supports Office documents and requires Office 365 E5 or Microsoft 365 E5 compliance licenses.

Reading Protected PDFs

All of this is good, but there’s no point in protecting PDFs if they can’t be read. To read a protected PDF, you need a reader which understands how protection works. Microsoft posts a list of supported readers online, the most common being Adobe Acrobat (Figure 2).

Reading PDFs in Edge Chromium

It’s nice to have a supported reader; it’s even better when the browser supports access to protected PDFs. The latest version of the Chromium-based Edge browser can read protected PDFs (I base this article on Version 83.0.478.61). Reading protected PDFs doesn’t work with private browser sessions, probably because some dependency exists on having a signed-in account.

Browser support for reading protected PDFs means that you can open protected PDFs from the SharePoint Online or OneDrive for Business browser clients or OWA. In this case of SharePoint Online, the protection can stop people taking screen captures. If you try to grab a capture (I tried with Snagit), you end up with a capture that’s all black. As Figure 3 shows, I was forced to take a photo of the screen to illustrate the point.

Some get very worried when applications don’t prevent users copying information from protected content. As demonstrated with SharePoint Online, the application can take the steps necessary to block access, but inventive people will find a way to share the information.

You can’t apply, change, or remove sensitivity labels from PDFs stored in SharePoint Online or OneDrive for Business. Instead, you must download the file and process it with the unified labeling client, and then upload it again.

Reading Protected PDFs with OWA

To test how OWA deals with protected PDFs, I attached the same file to an email and sent it. As you can see in Figure 4, OWA doesn’t stop screen captures even though the same permissions are assigned to the reader. The upside is that you can see the permissions and visual markings used to highlight the protected nature of the content to users.

Reading PDFs in Other Browsers

To show what happens when you try to access a protected PDF with another browser, I opened a SharePoint session with Brave. Figure 5 shows what results when I chose to open the file in the browser. The same is true in Chrome or Internet Explorer. To read the file, I had to download it and open the PDF with Acrobat Reader.

Good Feature to Have as Sensitivity Labels Become More Common

Some might consider building the ability to read protected PDFs into Edge a small and unimportant feature. It might not be the killer feature to convince people to move from Chrome or another browser, but I think the capability will be more appreciated over time, especially as the usage of protected content grows within Office 365 and more protected files are stored in SharePoint Online and Exchange Online.

Need more information about Office 365 sensitivity labels? Look no further than Chapter 24 of the Office 365 for IT Pros eBook. Its 60 pages will inform and delight you about how to use rights management to protect content in Office 365.

Exploit Sensitivity Labels to Protect Confidential Material Stored in SharePoint Online

If you assign sensitivity labels to critical documents stored in SharePoint Online or OneDrive for Business, you probably don’t want users to share those documents with external parties. It’s possible to restrict sharing at the level of a SharePoint site or tenant to stop documents being shared externally, but that will stop all sharing. Being able to pinpoint and block specific documents is better, especially when someone has made a judgment that a document needs to be protected by a certain sensitivity label. Of course, if the sensitivity label invokes encryption, the recipient might not have the rights to access the content, but it’s better when the block is imposed by the service and the intended recipient doesn’t get a chance to inspect document metadata (title, etc.), which might reveal something of its content.

Last July, Microsoft introduced the initial support in DLP policies for sensitivity labels using checks against the managed property defined in the SharePoint Online schema used to hold the GUID of a sensitivity label. The property is called InformationProtectionLabelId and the check is performed against a document property in the form InformationProtectionLabelId:Guid. For example:

InformationProtectionLabelId:9ec4cb17-1374-4016-a356-25a7de5e411d

In an announcement posted on November 10, Microsoft confirmed full support for sensitivity labels in DLP policies. This means that instead of using a document property, you can specify that the content contains a sensitivity label in the same way as the policy can check for the presence of a sensitive data type (like a credit card number) or retention label.

Simple DLP Policy

A simple DLP policy illustrates the point. The policy needs one rule with two conditions and an action:

• Condition 1: Content contains a retention label, sensitive data type, or sensitivity label. Select sensitivity label and then select the sensitivity label to check (Figure 2).
• Condition 2: Content is shared with someone outside the organization.
• Action: Block access to people outside the organization.

You can decide to apply the policy to selected sites or all sites in the tenant. I elected to use all sites because it means that documents marked as Ultra Confidential cannot be shared externally from any site, including new sites added after the policy becomes active.

The Block in Effect

After the DLP policy is published to SharePoint Online, any attempt to share a document with the Ultra Confidential label will proceed as follows:

• User will be able to create and send a sharing link to an external recipient as normal.
• DLP will detect that a link has been generated and block sharing (no further external sharing is possible). The sharer will receive notification that sharing is blocked (Figure 3). At this point, the sharer should probably tell the external person that the sharing link won’t work because…
• If the external person tries to access the document, they’ll be informed that they can’t.

Using Auto-Label Policies To Find and Label Documents

Another way of approaching the problem is to use an auto-label policy to search for documents with a specific characteristic and apply a label to protect the document. This works well, providing that you’re willing to pay for Office 365 E5 licenses to use auto-labeling policies. The technique described above works with Office 365 E3.

Another point to remember is that the most important and critical information in a company often cannot be easily found by auto-labeling. Some human intervention is needed to decide just how confidential a document is and what the appropriate level of protection should be. And when someone applies a highly confidential label to a document, it’s nice that you can then stop external sharing with such a simple DLP policy.

DLP policies are covered in Chapter 22 of the Office 365 for IT Pros eBook. We cover sensitivity labels in Chapter 24. Lots of information to learn from!

Sensitivity Labels Spreading Across Office 365

Sensitivity labels are rapidly spreading across Office 365 workloads. They are now supported by:

• Office desktop applications.
• Office online applications.
• Office mobile applications (Outlook mobile can read protected messages but can’t yet apply a sensitivity label to new messages).
• SharePoint Online and OneDrive for Business.
• Container management for Microsoft 365 Groups, Teams, and SharePoint Online sites (the data inside the container isn’t protected, but settings for the containers are).

New features, like the Content Explorer in the Microsoft 365 Compliance Center, help compliance administrators understand the effectiveness of their labeling strategy. Overall, the signs are that the ecosystem surrounding sensitivity labels is gradually building out.

Gaps still exist. You can’t use sensitivity labels to protect Teams messages (the files stored in SharePoint Online and OneDrive for Business for Teams can be). Nor can you use sensitivity labels with Planner, Stream, or Yammer.

Power BI Support for with Sensitivity Labels

An integration announced at Ignite 2019, and now generally available, supports the application of sensitivity labels to Power BI objects. I suspect that this won’t affect many Office 365 users, but it is the closing of another small gap.

Labels are Visual Labels Inside Power BI

Some points to remember about using sensitivity labels with Power BI include:

• The integration must be enabled for the tenant (Figure 1). You can enable support for all users or just selected groups.
• Users must have Power BI Pro licenses to apply sensitivity labels. Power BI Pro is included in Office 365 E5.
• Labels can be applied to reports, dashboards, datasets, and dataflows by editing item settings (Figure 2). They can’t be applied to template apps.
• Power BI doesn’t support sensitivity labels in the government or sovereign clouds.
• The Do Not Forward label isn’t supported nor are labels with user-defined permissions or those depending on HYOK. In other words, your tenant must use a Microsoft-managed key.
• Sensitivity labels are visible in dashboards and when viewing Power BI objects. However, sensitivity labels with encryption do not encrypt Power BI data. Instead, the encryption applies when Power BI objects are exported as Excel, PowerPoint, or PDF files.

In effect, within Power BI, sensitivity labels are used as visual markers of the sensitive nature of some data. The ability of labels to apply encryption and markings to information only occurs when data moves out of Power BI.

Exports Gets Protection

As mentioned above, protection through rights management-based encryption is applied when Power BI exports an object. Figure 3 shows a report exported from Power BI to PowerPoint. The label is present. The big difference is what the user who exported the object from Power BI can do with the document.

Normally, when someone applies a sensitivity label to an Office document, they are the owner and have full access to the document. For instance, they can decide to change the label and apply a more sensitive or less sensitive label depending on the document’s content. When someone exports a file from Power BI, they can still edit the content, but they cannot change the assigned label because they are not regarded as the document’s owner.

The underlying logic is that Power BI manages permissions and access to the information. If a label is applied in Power BI, it should be managed inside Power BI and if the label should be changed, it can be changed there. It’s an example of how the rights management aspects of sensitivity labels adapts to the needs of an application.

So many changes, so many updates, and all happening all the time within Office 365. Which is why you should subscribe to the Office 365 for IT Pros eBook to make sure that you know when things change.

Old Approach Should be Replaced by Sensitivity Labels

With support for Office 365 sensitivity labels is available in SharePoint Online and the Office Online apps (in preview, expected to be generally available very soon), it’s a good opportunity to consider how you should protect SharePoint Online content in the future. The choice is to continue by applying Information Rights Management (IRM)-based protection to document libraries so that documents are encrypted when downloaded or to go all in with sensitivity labels.

IRM-based protection requires a tenant to enable rights management for SharePoint Online before libraries can be protected. Once this is done, you can go to the Information Rights Management section of library settings and configure protection (Figure 1).

After IRM is enabled for a library, any PDF or Office document file will be encrypted when downloaded. The encryption uses rights management to ensure that only people with access to the library can open the downloaded files.

Only One Go-Forward Option

Office 365 sensitivity labels are the preferred way to protect content stored in SharePoint Online and OneDrive for Business. They are more flexible and powerful than the traditional approach of protecting SharePoint libraries with IRM. The advantages of sensitivity labels include:

• Support for labels in a wide range of clients including desktop, browser, and mobile apps. Figure 2 shows how to apply a sensitivity label to a document through Word Online.
• Labels can apply visual markings to content in addition to protection.
• Because rights management underpins labels, granular control is available to determine who can do what with a file.
• Labels become part of the metadata of files and messages and protection travels with content as it moves between libraries or in and out of Office 365.
• Labels can be applied to email and documents automatically (by label policy, Data Loss Prevention policies or transport rules) or manually (by users).
• Labels can be used to assign classifications to Office 365 Groups, Teams, and SharePoint containers.
• Documents protected by sensitivity labels support advanced features like co-authoring (with Office online apps).
• SharePoint Online populates a sensitivity column to show the label applied to files (the column is not available in OneDrive for Business).
• Documents and messages protected by sensitivity labels are indexed by Office 365. This means that protected content can be found by Office 365 content searches and eDiscovery.

Some of these features are still in preview, like the support in SharePoint Online, but they are coming and will be generally available very soon.

The benefit of traditional SharePoint “protection on download” is that encryption is automatically applied when files are downloaded from a library, meaning that users don’t have to think about applying a label to documents. Only people with access to the library can access the files.

The long-term strategy for any Office 365 tenant should be to phase out the traditional SharePoint IRM-based protection and replace it with Office 365 sensitivity labels as soon as business requirements and user training allows.

Confused about encryption and rights management in Office 365? Look no further than Chapter 24 of the Office 365 for IT Pros eBook. It’s all explained there.

Protected Content, Information Barriers, and More

Following up on yesterday’s report that Office 365 Groups will soon support sensitivity labels, more details emerged at Microsoft Ignite about how this support will flow through to group-enabled SharePoint Online sites. This is part of a big set of new features coming to improve the capabilities of SharePoint Online in the compliance space.

SharePoint Embraces Protection

From a SharePoint perspective, the big news is that SharePoint will soon be able to deal with encrypted content more elegantly than is possible today. After applying sensitivity labels with an Office app (desktop, mobile, or online – see Figure 1), SharePoint Online can index document content protected with a sensitivity label that invokes encryption (through rights management). Support for sensitivity labels in the Office Online apps also co-authoring of protected content.

Being able to index protected content is a big change. Up to now, SharePoint could only index the document metadata (like the subject or topic fields) of protected documents and the content remained inaccessible. Now, administrators will be able to search protected documents using Office 365 content searches (just like they can search protected email today). Naturally, users will also be able to search sites for protected content, but only content they have permission to access.

Protected documents downloaded from SharePoint sites retain their protection because the protection settings are part of the document metadata that apps respect inside or outside Office 365.

DLP and Protected Content

Along with search, Office 365 Data Loss Prevention policies will be able to examine protected content and apply policies to content found to violate policies because of the presence of sensitive data such as credit card or social security numbers.

Sensitivity Labels and Document Properties

One thing you won’t be able to do (for now) is apply a sensitivity label by editing document properties in the same way you can apply a retention label today. SharePoint’s new functionality concentrates on the storage and management of content marked with sensitivity labels instead of the direct application of the labels. However, you can expose a new Sensitivity column in document views to highlight protected documents (Figure 2).

SharePoint Online and Information Barriers

Most of what’s described above will be in public preview from November 20. Private previews are spinning up for more advanced functionality, like the ability to auto-apply sensitivity labels to documents based on their content. Also in private preview is SharePoint Online support for Office 365 Information Barriers. In this implementation, SharePoint will block sharing of documents with people inside the organization if mandated by an information barrier policy.

Expiring External Access

Finally, SharePoint is introducing new controls to allow organizations to set expiration periods for external access to content. You’ll be able to define how long a sharing link should last for external people. Once the period elapses, they lose access to the shared content. Lots of good stuff!

Stay up-to-date with developments in compliance across Office 365 with the Office 365 for IT Pros eBook.

Bit by Bit, Office 365 Sensitivity Labels Reaching Applications

On September 24, I published an article about the support of Office 365 Sensitivity Labels in the Office ProPlus for Windows desktop apps. At the time, I noted that Microsoft still had work to do to add support for sensitivity labels to the Office online apps, including OWA. Microsoft had published Office 365 notification MC191074 to say that Office 365 tenants now with worldwide roll-out complete by the end of October. Well, OWA “manual” support for Office 365 Sensitivity Labels has turned up in my tenant to satisfy roadmap item 44921.

Manual Labeling

Manual support for Office 365 Sensitivity Labels means that OWA users must decide what messages to label and the labels to assign to messages. Automatic labeling is what happens today with Office 365 retention labels when conditions in a policy control what items labels are applied to by a background process. Similar facilities are likely for sensitivity labels in the future.

Apply Sensitivity Labels in the OWA New Message Window

Because OWA runs in online mode, it always uses the current set of sensitivity labels published for a user. This doesn’t mean that a new or updated label is available to OWA immediately a change is made. The Security and Compliance Center must publish the change to all Office 365 workloads and clients. It can therefore take some time before a change is available to OWA.

The Sensitivity button is available as an option in the OWA new message window. After a label is applied to a message, its name is shown in the banner above the message recipients. In Figure 1 we can see that the selected label invokes encryption because of the padlock icon beside the label name. A label that only applies marking or does nothing but act as a visual indicator uses a plain label icon.

OWA also displays these icons for labelled items in the read message window. Like Outlook, the protection applied to a message also applies to any of its attachments

Labeling Replies

Sensitivity labels can also be applied to replies to messages that aren’t previously labelled. In this case, the Sensitivity option to apply a label is in the […] menu of the reply message window (Figure 2).

When you assign a sensitivity label to a reply, it does not apply to the previous messages in the thread. However, Exchange automatically assigns the same label to future messages in the thread.

Encrypt-Only and Do Not Forward

The default Office 365 Message Encryption Encrypt-Only and Do Not Forward templates can also be used to protect messages with OWA. Click the […] menu and you’ll find Encrypt in the list of menu choices. Using these templates for protection does not assign a sensitivity label to the protected messages.

Still Work to Do

Now that OWA supports Office 365 Sensitivity Labels, it’s reasonable to expect that the other Office online apps will offer support soon. After that, eyes will turn to the SharePoint Online and OneDrive for Business browser interfaces to see how Microsoft will introduce sensitivity label support there.

For more information about Office 365 Sensitivity Labels and the underlying Azure Information Protection technology, read Chapter 24 of the Office 365 for IT Pros eBook.

Automation Through Policy Ensures Protection is Applied

Microsoft Cloud App Security (MCAS – now renamed Microsoft Defender for Cloud Apps) is a cloud access security broker (CASB) that can ingest and act upon Office 365 audit information. The current set of supported apps include:

• SharePoint Online.
• OneDrive for Business.
• Exchange Online.
• Teams.
• Dynamics 365.

MCAS is designed to give administrators insight into security-related events for a tenant. Given the number of events that even a small Office 365 tenant can generate, automation through policies that act when specific criteria are matched is the best way to manage common conditions. For example, what action should happen when someone shares a file outside the tenant or creates a new document in a confidential site.

If Azure Information Protection is integrated with MCAS, MCAS retrieves the list of available labels from Azure (or Office 365 sensitivity labels if you use them) in the tenant hourly and adding a protection label to Office documents and PDF files is a supported action. Using this capability means that you can automatically apply protection to files matching policy criteria as users interact with them in Office 365. On the basis that it should not override a decision made by a user, MCAS only applies a label if protection doesn’t already exist on a file.

Depends on Office 365 Audit Events

MCAS protection isn’t applied immediately files are added to Office 365. Instead, as MCAS ingests events from the Office 365 audit log, it looks for events (like document creation or modification) matching the criteria set in its policies and applies labels as necessary. The elapsed time between something happening in Office 365 and a response occurring in MCAS depends on the ingestion of audit events from Office 365 and the processing of those events in MCAS queues. Depending on the load on the service, the exact time will vary. For example, it might take between ten and twenty minutes before MCAS applies a label to a new file created in a SharePoint document library.

Viewing Protected Files

The actions taken by MCAS to label files are visible in the Investigate section of its dashboard. In Figure 1 you can see the label icon alongside many file names together with an exclamation icon to show that the file was processed by a policy. If you find that an important file hasn’t been protected, you can add the protection from the MCAS dashboard by selecting Apply classification label from the […] menu.

At the top of the MCAS dashboard, you can see filters to build queries to identify activity for specific applications, users, data ranges, and so on.

Extra Cost for Extra Value

It’s unusual to find valuable capabilities offered for free in the cloud and MCAS is no different. You need to license MCAS before it will ingest information from Office 365 and you need to license Azure Information Protection before you can connect labels (even if they are managed in the Office 365 Security and Compliance Center) to MCAS. However, the cost of licensing MCAS might be insignificant for organizations who need the assurance that highly confidential information is protected. We can assume that users will remember to apply sensitivity labels to their documents, but computers are much more reliable when it comes to mundane tasks like labeling. If you’re concerned about securing Office 365 content, especially Office documents and PDFs stored in SharePoint Online and OneDrive for Business, the combination of Office 365 Sensitivity Labels and MCAS is hard to ignore.

Need to know more about how rights management works in Azure Information Protection and Office 365 Sensitivity Labels? Look no further than Chapter 24 of the Office 365 for IT Pros eBook.

Use the AIPService Module Instead

On July 31, Microsoft announced the deprecation of the AADRM PowerShell module and its replacement by the AipService module. AADRM stands for “Azure Active Directory Rights Management” while AIP is the Azure Information Protection service. The two modules connect to the same back-end service to manage the configuration of the protection service, including the rights management templates to protect content inside and outside Office 365, including Office 365 sensitivity labels configured to protect documents and email with encryption. Protection templates can also be applied by Exchange Online mail flow rules to protect selected messages as they pass through the transport pipeline.

File-Level Cmdlets Unaffected

The set of cmdlets in the AzureInformationProtection module used to apply (or remove) protection to files (outside Office 365) are unaffected. These cmdlets are available when you install the Azure Information Protection client on a workstation. Either version of the client (classic or unified labeling) installs the cmdlets. In passing, a recent Microsoft blog post explains the current state of the transition to the unified labeling client.

One example of using these cmdlets is to decrypt protected documents found in an GDPR Data Subject Request search (DSR). A DSR is a special form of Office 365 content search that returns all the information about an individual held within Office 365 repositories.

Script Updates Needed

The deprecation takes effect on July 2020. Before then, you should review any scripts with calls to the AADRM cmdlets and replace them with the equivalents in the AIP module. Microsoft supports aliases for the AADRM cmdlets in the new module, but it’s best to replace the cmdlet names as you don’t know for how long Microsoft will continue support for the aliases. Fortunately, editing to update scripts s is simple as it’s a matter of replacing the module prefix with the new name. For example:

Old module: Get-AadrmSuperUser
New module: Get-AipServiceSuperUser

Naturally, you should test scripts thoroughly after updating the cmdlets to make sure that they still work as expected.

A listing of the cmdlets in the AipService module is available online.

For more information about Azure Information Protection, including using PowerShell to manage the service and files, read Chapter 24 of the Office 365 for IT Pros eBook.

Gradual Roll-Out of Office 365 Sensitivity Labels

Azure Information Protection (AIP) labels have been available for several years. Office 365 Sensitivity Labels are gradually replacing AIP labels for the protection of Office 365 content. The process takes time because it involves encryption, so careful planning is necessary. I expect that Office 365 sensitivity labels will become a lot more popular when the Office applications support native protection. In other words, you won’t need to deploy the Azure Information Protection client to workstations if all you need to do is protect content stored inside Office 365 locations (SharePoint Online, OneDrive for Business, Teams, and Exchange).

Two versions of the AIP client are currently available. You need to use the unified labeling version with Office 365 sensitivity labels.

Publication Makes Labels Visible

When Sensitivity Labels are defined in a tenant, they are published to clients through label policies. Applications that understand how to apply protection check for and download policy updates regularly (every four hours in the case of the Office applications). Once a label policy is available, clients can unpack it to discover what labels are available to the signed-in user. Those labels can then be applied using the Sensitivity button in the toolbar. The current version of the AIP client also adds a protection infobar. In Figure 1, you can see the Sensitivity button and the infobar, which tell us that the Extraordinary label is applied to the document.

Removing a Label

Creating and publishing sensitivity labels is easy. But what happens if you make a mistake and want to remove a label? You could delete the label from Office 365. The deletion removes the label from label policies and clients won’t know that the label exists. This is an acceptable action when the label has not been applied to protect documents, but it’s problematic for protected content. The metadata for the label remains in the document. You know this because if you set another label, you might be asked to provide a justification if the new label has a lower priority. However, because the published policies hold no trace of the label, applications don’t know how to handle the label and the protection on the file reverts to “Not Set” (Figure 2).

Remove from Publishing Policies

By comparison, if you remove the label from policies, Office 365 still includes the label information in the policies and clients will still be able to resolve the label. However, users won’t see the label in the list of labels they can apply. This is a much better situation to be in because you can always restore the label to full use if you want or keep it in a visible but disabled state through non-publication.

For more information about Office 365 Sensitivity Labels, read Chapter 24 of the Office 365 for IT Pros eBook.

Reduced Confusion as Everyone Waits for Native Support in Office Clients

As is the nature of the Microsoft cloud, the preview version of the Azure Information Protection client (unified labeling edition) has been replaced by the generally available version, now available for download and deployment. Microsoft’s April 16 announcement on the topic was upbeat but I still find considerable confusion in the field about labels, Azure Information Protection, Office, encryption, and rights management. Let’s see if we can clarify the situation.

Rights Management

Rights management is the technology that allows content owners (authors) to protect documents and files by stamping them with a template. The template defines the rights given to recipients to interact with the content such as the ability to edit or print. Rights management is automatically enabled for all Office 365 E3 and E5 tenants.

Azure Information Protection

Azure Information Protection (AIP) is a suite of technology built by Microsoft to control and help secure email, documents, and files. Reflecting their original name of “classification labels,” AIP labels are used to classify material inside or outside Office 365 with different degrees of sensitivity to reflect the confidentiality of the content. Labels are associated with rights management templates but also include other features like content marking. Labels used for the most sensitive information are likely to invoke encryption to protect the information against unauthorized access. AIP labels and templates are managed in the Azure Information Protection blade of the Azure portal. An AIP license is needed to assign AIP labels to files.

Office 365 Sensitivity Labels

Sensitivity Labels are like AIP labels except that they are managed through the Security and Compliance Center. Both sets of labels share a common base in rights management and if a tenant started with AIP labels, they can migrate the set of AIP labels to become sensitivity labels and thereafter continue managing the labels through the Security and Compliance Center.

Sensitivity Labels are designed to protect content like email and documents stored inside Microsoft 365. Office 365 E3 and E5 plans include the licenses to use sensitivity labels, including the ability to encrypt email and documents. Figure 1 shows an Outlook message protected by a sensitivity label. You can also see the protection bar, which shows the current label applied to an item, and the sensitivity button, to expose the set of labels available to the user.

Although Exchange Online, SharePoint Online, and OneDrive for Business support sensitivity labels today, it will take some time before sensitivity label support is picked up in other workloads, like Teams.

AIP Client (s)

Two versions of the AIP clients are available. The standard version reads its policy and label information from the Azure portal. The unified labeling version reads equivalent information from the Security and Compliance Center. Both versions integrate with the Office desktop applications. You should use the AIP unified labeling client with Office 365, making sure to use the latest version whenever possible.

If you see a Protect button in the Office desktop apps, you know you’ve installed the older version of the AIP client. The unified labeling client installs a Sensitivity button (as shown in Figure 1).

Although the unified labeling version of the AIP client is not quite as functional as the older client. Microsoft expects it to reach close to feature parity with its older counterpart by the end of 2019. Microsoft’s blog post also makes the important point that “going forward new features will be included in the Azure Information Protection unified labeling client whereas we’re not planning to add new features to the Azure Information Protection client”. In other words, future development efforts are focused on the unified labeling version, so tenants starting deployment projects today are strongly advised to use this version.

Encryption

One of the big features of rights management templates is the ability to protect content through encryption. The keys used for the encryption can be tenant-provided (BYOK or HYOK) or Microsoft-managed (MMK). In either case, the AIP client is responsible for encrypting content after an AIP or sensitivity label is applied to a message, document, or file. This is why you need to deploy AIP clients to workstations.

Native Support

It’s obviously inconvenient to have to deploy yet another client to user workstations. To make things easier, Microsoft is building native support for sensitivity labels (and encryption) into the Office ProPlus (click-to-run) desktop apps and the Office Online apps. Office mobile apps (Word, PowerPoint, Excel) also support the application of sensitivity labels today. Outlook Mobile can read protected content and will be able to apply sensitivity labels to new messages soon.

When the Office apps include native support for sensitivity labels, you won’t need to deploy the AIP client to get this functionality unless you intend applying labels to content stored outside Office 365, in which case you need an AIP license (available in P1 and P2 plans and as part of the Enterprise Mobility + Security suite or Microsoft 365 Enterprise plans).

Summing Up

Most organizations have a mixture of content that needs to be protected inside and outside Office 365. The unified labeling version of the AIP client delivers this functionality today. In the future, native support in the Office apps will create a more integrated solution for Office content, but you’ll still need to deploy an AIP client to handle content stored in file servers and other non-Office 365 locations.

Still confused abut AIP, labels, encryption, and Office 365? We suggest you read Chapter 24 of the Office 365 for IT Pros eBook where this topic is covered in detail.

More Progress towards Enabling Sensitivity Labels

Along with announcing its intention to include licenses for Information Protection in Office 365 E3 and E5 plans, Microsoft made further progress to encourage widespread use of Office 365 sensitivity labels by upgrading policies to include some auto-label capabilities and shipping an update for the “unified labeling” preview for the Azure Information Protection (AIP) client.

The biggest barrier for adoption for sensitivity labels today is lack of support in Office apps (desktop, mobile, and online) for the labels. To bridge the gap until General Availability (expected later this year), Microsoft released a different version of the Azure Information Protection client. The “unified labeling” version reads label and policy information from Office 365 (sensitivity labels and policies are found in the Security and Compliance Center) instead of Azure. The unified labeling client has just been updated and can be downloaded here.

Some Work Still to do for Sensitivity Labels

The preview of the unified labeling client (V2.0.747.0 ) only works for Windows workstations. When installed, the unified labeling client adds a Sensitivity button to the Office desktop apps. By comparison, the regular version of the AIP client adds a Protect button. Both buttons serve the same function. They display a list of all the labels available to the user (from all applicable policies) to allow them to select which label to apply to a message or file.

Long term, the Office apps will have native (in-built) support sensitivity labels and you won’t need to deploy any other software to apply labels and have them mark and protect (encrypt) content. The idea is that you should be able to apply labels to Exchange Online messages (with OWA and Outlook) and files stored in SharePoint Online and OneDrive for Business.

I also expect Microsoft to overhaul the the limited (and old) support for rights management in SharePoint Online to make it easier for site owners to apply default labels. Some work also needs to be done to update the SharePoint Online and OneDrive for Business web apps to allow users to apply sensitivity labels, probably in much the same way as they can apply retention labels today.

Once sensitivity labels are fully deployed inside Exchange Online and SharePoint Online, it is reasonable to anticipate that Microsoft to enable support for sensitivity labels to other Office 365 apps.

Because Office 365 sensitivity labels and Azure Information Protection labels share common underpinnings, sensitivity labels can also be applied to files outside Office 365, in which case they act like AIP labels.

Auto-Label Settings for Sensitivity Labels

Office 365 administrators are used to the concept of using auto-label policies to assign retention labels to content discovered by background processes to match conditions set in a policy. Sensitivity labels have their own take on auto-labeling. Briefly:

• Auto-label conditions are set for a label instead of by policy.
• Matching is only possible against Office 365 sensitive data types. Auto-label policies for retention labels can also match against keywords.
• Applications that support sensitivity labels action the label settings when they detect matches. For instance, if you create a Word document and include a credit card number, the match is detected when the document is saved and the (AIP) client executes the auto-label action. In the example below, the action is to apply the label.

This form of auto-labeling has been supported by AIP labels for a couple of years, so its appearance inside Office 365 is evidence of the work going on to create functional equivalence between AIP and sensitivity labels.

Note that auto-label is a premium feature that requires Azure Information Protection P2 licenses. In the world of Office 365, it’s likely that access to this functionality will be controlled by the new Information Protection for Office 365 -Premium licenses in Office 365 E5 or the Advanced Protection and Compliance SKU.

Need more information about Sensitivity Labels and Encryption through rights management in Office 365? Head over to the Office 365 for IT Pros eBook and read Chapter 24!

Email Encryption is Good, but Only Under Tenant Control

In January 2019, Microsoft revealed a plan to create a transport (mail flow) rule in Office 365 tenants to encrypt email containing sensitive data. For many reasons, not least that it’s not a good idea to interfere with the business logic a tenant chooses to apply to outbound email, Microsoft pulled back on the idea. On January 25, after a period of mature reflection, Microsoft decided to publish details of how to create the transport rule and leave it to tenants to decide if they want to use it. Those instructions are now online. This post explores the commands included in Microsoft’s instructions.

PowerShell Commands to Create Rule

The instructions use two PowerShell commands. The first runs the Set-IRMConfiguration cmdlet to update the rights management configuration for Exchange Online in the tenant. The command sets the DecryptAttachmentForEncryptOnly switch to $True to give recipients of messages protected with the default Encrypt-Only template full rights over any attachments. The default value of this setting is $False, which means that attachments remain encrypted.

Unfortunately, the command published in the article is incorrect as it uses DecryptAttachmentsForEncryptOnly instead of
DecryptAttachmentForEncryptOnly.The correct command is:

Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $True

Microsoft’s New Transport Rule

The next command runs the New-TransportRule cmdlet to create the transport rule. The rule applies the Encrypt-Only template to protect any messages that include the following Office 365 sensitive data types:

• ABA Routing Number.
• Credit Card Number.
• Drug Enforcement Agency (DEA) Number.
• U.S. or UK Passport Number.
• U.S. Bank Account Number.
• U.S. Individual Taxpayer Identification Number (ITIN).
• U.S. Social Security Number (SSN).

The Encrypt-Only template is used because it is available to every Office 365 commercial tenant and any Outlook.com user. Any other recipient can go to the Office 365 Message Encryption portal to decrypt the content.

Checking the Rule

The sensitive data types are very U.S.-centric and might need to be adjusted for your tenant to include data types that are more commonly used in your organization. I imagine that Microsoft chose the set for the rule because they are well-known and prove the potential value of the rule rather than deciding that these types make sense for every Office 365 tenant. Remember that you can create your own custom data type and use it if needed.

Unhappily, the PowerShell gods conspired against this command as well because it also has an error. The command as given by Microsoft is:

New-TransportRule -Name "Encrypt outbound sensitive emails (out of box rule)" -SentToScope  NotInOrganization  -ApplyRightsProtectionTemplate "Encrypt" -MessageContainsDataClassifications @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="Drug Enforcement Agency (DEA) Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"}) -SenderNotificationType "NotifyOnly"

The problem is the last parameter where SenderNotificationType should be NotifySender. Change the command and replace the last parameter with NotifySender = “NotifyOnly” and PowerShell will happily create the new rule.

Adjusting for Your Office 365 Tenant

Before running New-TransportRule, remember to adjust the command to include the sensitive data types that you want to check for and any other changes deemed appropriate for your tenant. For instance, you might not want to encrypt email to every other domain and decide that protection should only be applied to specific domains.

If you don’t want to work with transport rules through PowerShell, you can run Microsoft’s command and then edit the transport rule through the Exchange Admin Center GUI. As you can see below, it is often easier to adjust settings through a GUI. In this case I limit the domains that receive protected email. If you choose to limit the rule to selected domains, you must also remove the notification to the sender as this setting conflicts with a domain list (for no apparent reason)

It is important to check that the new rule does not conflict with any other rule that already exists. For instance, you might discover that another rule does something else to messages sent to the selected domains and then exits rules processing, so messages will never be encrypted.

The old advice to never trust and always check code downloaded from the internet holds true, even when you download code written by Microsoft.

We cover rights management and email encryption in Chapter 24 of the Office 365 for IT Pros eBook while transport rules are described in all their glory in Chapter 17.

Encryption for Exchange Online Autosignatures

When I wrote about the effect of encryption on ISV autosignature products, I made the point that the Exchange transport service can apply autosignatures (disclaimer text) to outbound messages with a rule even if the messages are encrypted. This is because Exchange uses rights management super-user permissions to decrypt messages, apply the disclaimer, and then encrypt them again for final delivery.

Questions flowed in to know if it is easy to create a transport rule (aka mail flow rule) to apply an autosignature like those generated by the ISV products. The answer is that you can, but it takes some effort, especially if you want to use nicely formatted HTML text in the autosignature. The UI in the Exchange Admin Center to create and manage transport rules isn’t very accommodating when it comes to inserting complex formatted text. However, with persistence, it’s possible to create nicely formatted autosignatures (see the Exchange documentation for some examples, including how to insert a graphic file like a logo in an autosignature).

Apart from the difficulty of editing the text used in autosignatures applied by transport rules, the most common complaint is that rules stamp all messages, including replies, so you end up with multiple autosignatures in a mail thread. This is true, but it’s easy to build an exception into the rule so that the autosignature is applied once.

Once you’ve built a transport rule to apply an autosignature, you can combine it with other rules to protect messages sent to all or some destinations by applying a rights management template, including the special Encrypt-Only or Do Not Forward templates.

An Example of Encrypted Email

An example is always helpful. The screenshot below shows a protected message received by an Outlook.com user. The message has an autosignature applied by a transport rule. The text of the autosignature is inserted into the message content even though the message is protected. Some Azure Active Directory elements (like the first name, last name, phone number, etc.) are used in the autosignature. The phone number is blank, meaning that it hasn’t been populated for the user (more on this below).

The relevant extracts from the transport rule (using Get-TransportRule) are shown below.

ExceptIfSubjectOrBodyContainsWords            : {This message is the property of Redmond and Associates}
ApplyHtmlDisclaimerLocation                   : Append
ApplyHtmlDisclaimerFallbackAction             : Wrap
ApplyHtmlDisclaimerText                       :

Redmond and Associates

This message is the property of Redmond and Associates If you receive this message in error, please delete it immediately and inform us at +353 1 991 17463 about its delivery.
%%FirstName%% %%LastName%%
Phone: %%PhoneNumber%%
Email: %%Email%%

The exception in ExceptIfSubjectOrBodyContainsWords is important because it stops the autosignature being inserted into replies.

Why Use Third-Party Autosignature Products?

If it’s relatively straightforward to use a transport rule to insert autosignatures, including for protected email, why do people buy and use third-party autosignature products? The biggest reasons are flexibility and ease of use. The third-party products make it much easier to build and deploy attractive autosignatures to targeted sets of users (or the whole company) without having to grapple with the Exchange Admin Centre UI or PowerShell. Much as I like PowerShell, using it to edit HTML is not a rewarding experience.

Organizations that need to change autosignatures frequently (for instance, to advertise events) or deploy a range of different autosignatures to different groups within the company will find it easier to use specialized autosignature products. The downside, as I pointed out in the Petri.com article, is that server-side processing by these products cannot deal with protected messages. A client-side add-in must inject the autosignature into a message before encryption is applied by the client.

Directories

A word on directories… No centrally-managed autosignature will work unless the directory it’s based on holds accurate information. Make sure that your Azure Active Directory is updated with valid information for any of the attributes (like address or phone number) used by autosignatures.

For more information about transport rules, see Chapter 17 of the Office 365 for IT Pros eBook.

Encrypted or protected email is becoming more common inside Office 365 with the advent of the Encrypt-Only feature available in Outlook 2016 (Click to Run) and OWA.

You can include a mixture of internal and external recipients, including those who do not use Office 365, in the recipient list for a protected message and, subject to scoping defined for the template used to protect the message, will be able to open and access the content. You can also send protected messages to other Office 365 destinations, but as explained below, some restrictions apply.

Office 365 Groups

Protected messages (and attachments) sent to an Office 365 group can be read by any member of the group, including guest users, because they authenticate their access through membership of the group. 

Scoped Templates will Stop Access

The exception is when the template used to protect a message is scoped to assign permissions to specific recipients and a member of the Office 365 group is not included. In this case, the group member sees a conversation and who contributed to the conversation, but can’t see the content of the message (see below). if they click the banner telling them that a message can’t be displayed, they see the link to the Office 365 Message Encryption portal. However, this link won’t give them access because their account is not in the permissions list for the message.

Shared Mailboxes

Protected messages sent to a shared mailbox can be opened and read by those with access to the shared mailbox if they use OWA. However, the same people can’t read the messages if they use Outlook. The difference in behavior is explained by the way that OWA fetches use licenses. Microsoft has admitted that they need to make both clients work the same way.

Teams Channels

Protected messages sent to the email address of a Teams channel (for example, 95c133a3.office365itpros.com@emea.teams.ms) are rejected by Exchange Online because the transport service cannot re-encrypt the message for delivery to the phantom mailbox used to route messages to Teams. As shown below, the sender receives a 5.7.1.Delivery Service Notification (DSN). Exchange Online decrypts protected messages as they pass through the transport service to allow transport rules to process the content.

Yammer Groups

The same happens if you try to post a protected message to a Yammer group (with an address like office365QA+office365itpros@yammer.com). Again, Exchange Online can’t re-encrypt the message to deliver it to Yammer, so it issues a 5.7.1. DSN.

Learn all about rights management, templates, and email protection in Chapter 24 of the Office 365 for IT Pros eBook.

The advent of sensitivity labels within Office 365 should lead to more use of rights management to protect email and documents. Rights management uses encryption to enforce the permissions assigned to those who receive information. Microsoft automatically enables rights management for Office 365 E3 and E5 tenants and email can be protected without making any further changes using the Encrypt-Only and Do Not Forward templates.

The downside of using rights management to protect documents stored in SharePoint Online and OneDrive for Business libraries is that indexing cannot process encrypted content. The metadata (properties) of encrypted documents are processed and included in the indexes, but the actual content inside the Word, Excel, PowerPoint, or PDF files are not.

Encryption Blocks Some Office 365 Features

The lack of indexing means that any Office 365 feature which depends on the SharePoint indexes don’t work with encrypted documents. You can’t find documents using SharePoint or Delve searches, and you can’t find them with Office 365 content searches. That is, unless the metadata of the encrypted files contains the keyword you use for the search. If this is the case, the search succeeds because the metadata is included in the index.

The situation is different with Exchange email because Exchange is able to decrypt protected messages and include them in the index.

A Search Example

Take the example where we have:

• A protected email sent to one other recipient in the tenant. The search keyword is in the body of the message.
• A protected Word document with the search keyword in the body of the file.
• A protected Word document with the search keyword in the body of the file and in one of the document properties (like the Title or Comments).

When we search, we should find two copies of the message (from the mailboxes of the sender and the recipient) and the second Word document (based on the metadata). The first Word document remains invisible to search because the information we search for is in the encrypted body. The content search shown below illustrates the point. We can see the two messages and single document.

If you do unearth some encrypted content  in a content search, you can decrypt protected email during the export process, but encrypted documents are exported intact. This means that you must decrypt those files to allow investigators to review their content (I describe how in this Petri.com article).  

Microsoft to Improve Situation?

Microsoft is doing a great deal to make encrypted content easier to generate within Office 365. It will take time for tenants to understand and adopt functionality like sensitivity labels, but it will happen. Hopefully, we’ll see an improvement in the discoverability of protected documents in SharePoint and OneDrive. 

For more information about sensitivity labels, see Chapter 24 of the Office 365 for IT Pros eBook. Content searches are covered in Chapter 20, and Delve is in Chapter 9.

An Insight Into Encryption

If you have deployed the new sensitivity labels into your Office 365 tenant or have trained people how to apply protection through rights management templates such as the default Encrypt-Only and Do Not Forward options available in OWA and Outlook, you might like to get some insight into how much email is being protected.

As announced at Ignite, the Security and Compliance Center includes a Message encryption report to show details of encrypted email processed in the last seven days. The report is in preview, so it doesn’t appear on any dashboard. However, if you’re an Office 365 tenant administrator, the report is revealed with this URL (Figure 1).

The report shows the date, sender, recipient, subject, and encryption details. The encryption template is either one of the default (like Encrypt only) or a custom template (one defined by the tenant).  The encryption method shows whether protection is applied by a user or automatically, such as by a transport rule.

Some Points to Improve

There’s no way to export this information, nor is it recorded in the Office 365 audit log. The information gathered also seems to ignore some encrypted messages, including email sent to Microsoft. No doubt these are the kind of glitches that will be sorted out before Microsoft moves the feature from preview to generally available.

For more information about email encryption in Office 365, read Chapter 24 of the Office 365 for IT Pros eBook.

S/MIME and the Unified Labeling Client

One of the interesting aspects of the latest release of the Azure Information Protection (AIP) client  (version 1.41.51.0) is its ability to use an existing S/MIME deployment instead of cloud-based rights management to sign and encrypt email.  The integration is only supported for the click-to-run version of Outlook 2016 for Windows.

The idea is that you can create a custom configuration for Outlook to call S/MIME instead of the normal rights management templates to encrypt an outbound message (read the online instructions). The custom configuration associates an S/MIME action (sign, encrypt, or both) with an AIP label. When the user applies the label to a message, the AIP client updates the message properties with the label metadata and applies whatever S/MIME action is defined.

The idea is not to replace rights management with S/MIME. Instead, it’s to help a small group of customers who have invested to deploy an S/MIME infrastructure. The custom AIP configuration does nothing to help customers manage S/MIME; it simply applies the S/MIME protection if it is available and functional.

Not for Most Office 365 Tenants

Although this feature proves the flexibility of the AIP client, I don’t think it is of much interest to the majority of Office 365 tenants. Here’s why:

• The solution only works for Outlook for Windows.
• Cloud-based rights management is built into and enabled for every Office 365 E3 and E5 tenant. You don’t have to do any work to encrypt messages with Outlook and OWA (or read those messages on any email client).
• The advent of Office 365 sensitivity labels, which will work for Office applications (Windows, Mac, and Online) in addition to email, makes rights management even more valuable. It’s not hard to see how Microsoft will extend coverage of sensitivity labels to other Office 365 data (like Teams conversations or channels) in the future.
• Rights management makes it easy to protect messages with transport rules.

So, a nice feature if you use S/MIME and have invested in that technology – but maybe it’s time for you to think about using something more modern and functional to protect more than just email?

To read more about sensitivity labels, rights management, and encryption, go to Chapter 24 of the Office 365 for IT Pros eBook.

Sensitivity Labels are a Game Changer

Today’s Petri.com post discusses the use of Microsoft 365 sensitivity labels through an updated set of Office desktop applications coming soon. A previous post reviewed the migration from Azure Information Protection (AIP) labels. Of course, you can create and deploy sensitivity labels to protect Exchange and SharePoint content without going anywhere near AIP. In the long term, AIP labels are only needed if you want to protect content that isn’t stored inside Office 365.

The important point is that AIP labels and sensitivity labels share a common foundation in the Azure Information Protection service and the set of rights management templates published through that service. Both update the same file metadata and both use the same permissions.

Rights management has been around for a long time. I think the technology got a bad rap because it was deemed complex and unwieldy.  Sensitivity labels change the dynamics because they are easy to create and publish, and easy for users to apply to Office documents stored inside SharePoint and to email sent by Exchange Online. For these reasons, sensitivity labels will make protection through rights management and encryption a daily part of Office 365 life.

Rights and Permissions

Protection means that a user cannot access content unless they have the rights to do so. Furthermore, once a user accesses content, the permissions assigned to them (the rights) dictate what they can do (print, edit, forward, reply, etc.). Protecting documents and email gives authors confidence that they control that content. For instance, adding a new recipient to a reply to protected message is useless from the perspective of that recipient because they don’t get the right to open the content because they’re not in the set assigned to the original message. All in all, protecting Office 365 content is a good thing.

The Downside of Protection

Even good technology can have its downside and protection is no different. Once you protect a document, you lose some functionality. The biggest issue is that Office 365 cannot search the content because it can’t decrypt the content to index it. This means that content searches and eDiscovery must rely on document metadata for its indexes. If users populate the metadata with terms that search can use to find documents, it might not be so much of a problem. But users are humans and humans often don’t do such a good job with metadata.

Of course, if a content search finds some protected content, you then face the further difficulty of what to do with it. Investigators might want to review the content to check whether it’s needed for eDiscovery purposes, but the content is encrypted. The solution is to use super-user privilege to decrypt the content. A technical solution exists, but dealing with encrypted files can be painful.

ISVs and Protection

In addition to the issues thrown up inside Office 365, any ISV who deals with Office 365 content needs to understand if the advent of sensitivity labels and increased use of rights management within Office 365 impacts their product. If a product depends on gaining access to content, it’s going to run into a brick wall when it tries to access protected content.

No Argument Against Protection

You can’t really argue against the goodness of securing access to confidential information. Sensitivity labels give users control over their information, and they should know what’s confidential and needs to be protected. Some user education is needed to ensure that everyone knows how best to use the range of visual markings and protection available through sensitivity labels, but overall, this is a very good feature that’s arriving into Office 365.

To read more about sensitivity labels, rights management, and encryption, go to Chapter 24 of the Office 365 for IT Pros eBook.

Reporting Files with Labels

Let’s assume that your users have applied Azure Information Protection or Office 365 sensitivity labels to a bunch of documents. How can you create a report of files to know which files are labelled and protected?

PowerShell to the Rescue

As it turns out, you can use PowerShell to examine the Azure Information Protection properties of files and extract the necessary information and use that to create our report. As always, an example helps to illustrate the point.

This PowerShell script looks for any Excel and Word documents in a folder (which could be a folder holding files copied by the OneDrive sync client from a SharePoint Online or OneDrive for Business document library). Each file is checked for the presence of an Azure Information Protection (AIP) or Office 365 sensitivity label (the same metadata is used). You need to be a tenant or AADRM administrator to be able to run the code.

$Report = @()
$Files = (Get-ChildItem -Path "c:\temp\" -Include *.docx, *.xlsx -Recurse)
ForEach ($F in $Files) {
$FileName = "C:\Temp\" + $F.Name
$TemplateName = $Null
$Status = (Get-AipFileStatus -Path $FileName)
 If ($Status.IsLabeled -ne $False) {
 If ($Status.RmsTemplateId -ne $Null) {
    $TemplateId = [GUID]($Status.RMSTemplateId)
    $TemplateName = (Get-RMSTemplate -Identity $TemplateId.Guid ErrorAction SilentlyContinue ).Name }
    $ReportLine = [PSCustomObject]@{
         File        = $F.Name
         IsLabeled   = $Status.IsLabeled
         LabelId     = $Status.MainLabelId
         Label       = $Status.MainLabelName
         Date        = $Status.LabelDate
         RMSGuid     = $Status.RMSTemplateId
         RMSTemplate = $TemplateName
         Owner       = $Status.RMSOwner }
 $Report += $ReportLine
}}
$Report | Export-CSV -NoTypeInformation c:\Temp\LabeledFiles.csv

Outputting Details

If a file has a label, we extract details of the label and the underlying rights management template. One interesting thing that I discovered when writing the script is that the Get-RMSTemplate cmdlet fails when passed the GUID of a template used by an Office 365 sensitivity label. The GUIDs are correct, but for some reason the cmdlet fails. The output for an individual file that has a label with protection is:

File        : ABPs and Teams.docx
IsLabeled   : True
LabelId     : 81955691-b8e8-4a81-b7b4-ab32b130bff5
Label       : Secret
Date        : 13 Nov 2018 12:29:42
RMSGuid     : c7fc2174-097c-4123-9cad-15f1a32cb145
RMSTemplate : Secret
Owner       : Tony.Redmond@office365itpros.com

Script Output

The output for the script is a CSV file that can be opened and analyzed with Excel or Power BI.

This script is included in our coverage of protecting Office 365 content in Chapter 24 of the Office 365 for IT Pros ebook. There’s another 44 pages about protection to read there…

Protect but Don’t Block

Office 365 tenants who use Rights Management with Azure Information Protection (and use a cloud key rather than their own key, or HYOK) can now include the special Any Authenticated Users in the permissions configured for protection templates. Previously, you could only define permissions for users within the same tenant or named individuals in other domains *(using their email addresses). Any Authenticated User is a special permission which grants a set of permissions defined in a template to any user who authenticates by signing into:

• An Azure Active Directory account. For example, anyone in another Office 365 tenant.
• A Microsoft Services (MSA) account. For example, anyone who uses Outlook.com.
• A directory service federated with Azure Active Directory (like Google) or where a one-time passcode is used to access protected content. These types of protection are usually involved when sending email to recipients of non-Microsoft email services.

The intention behind the Any Authenticated Users permission is to give tenants a method to encrypt information sent outside the organization so that it is protected in transit and at rest while still supporting granular permissions and access control (such as expiration and offline access). In effect, you’re not worried about who opens the content if they can authenticate, but you still want some control over what they can do with the content.

Like the permissions assigned to individuals or groups, you can grant specific permissions to Any Authenticated User. For instance, you can stop people who use the permission from copying or printing the content. You can also track and revoke access to the content at any time.

Any Authenticated Users and Sensitivity Labels

As you might know, Microsoft is currently in the process of unifying protection labels as defined in the Azure Information Protection portal with Office 365 labels. This doesn’t mean that we will have a single set of labels. Rather, Office 365 will have two sets, both of which are managed through the Classification section of the Security and Compliance Center:

• Sensitivity labels, which apply protection and are shared with Azure Information Protection.
• Retention, which define for how long Office 365 keeps information like documents and email.

The migration of labels from Azure Information Protection to Office 365 is still a work in progress. Here’s what I report in Petri.com on the topic.  You can add the Any Authenticated Users to a template in the Azure portal and it will be synchronized to the Security and Compliance Center. However, you can’t yet add the permission to a label through the Security and Compliance Center.

For more information about rights management, read Chapter 24 of the Office 365 for IT Pros eBook.