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.

Decision to Use Sublabels is an Implementation Issue

One of the topics that should be discussed before the implementation of sensitivity labels in a Microsoft 365 tenant before the creation and publication of labels to users is whether to use sublabels. Take the example in Figure 1 where three sensitivity labels (General, Confidential, and Highly Confidential) are parents to sets of sublabels. The General label has two sublabels (also called child labels).

A sublabel works like a primary label and can apply protection (rights management-based encryption) to email and files. It’s not When you use sublabels, the parent label acts as a container and cannot be chosen by users to label content in applications, even if it has settings to apply protection. Only the sublabels are selectable.

The Logic Behind Using Information Protection Sublabels

The main reason to use sublabels is to create a logical structure to guide users to apply the most appropriate label to content. The logic is that the parent labels are the major entry points for users to choose from. For instance, using the structure shown in Figure 1, if the user wants to label a file that’s not personal or public, they have three options to choose from. Their knowledge about the information in the file should help them to distinguish between General, Confidential, and Highly Confidential. Once they’ve made that important decision, they then decide the degree of sensitivity of the information and apply the most appropriate sublabel.

The Logic for Avoiding Information Protection Sublabels

The argument against using sublabels is that if the implementation team isn’t careful, it is easy to create a complex structure that hinders rather than helps users make the right decision. The logic is that a simple flat list of sensitivity labels ranked from least important (at the top) to the most confidential (at the bottom) is easier for people to understand.

This approach works if users are presented with a limited number of labels to choose from. Showing six labels with carefully chosen names that clearly communicate the level of confidentiality is likely easier for users to understand and navigate than a list of fifteen labels. In international deployments, the display names for sensitivity labels can be translated into different languages. In this scenario, it’s important that the label names have the same relevance in all languages.

Deployment of Information Protection Sublabels

Creating sublabels follows the same process as creating a regular label. The big difference is the starting point. To create a sublabel, you select the parent label (which logically must be created first) and then choose the option to create a sublabel (Figure 2). Part of the creation process is to determine the priority order for sublabels within the parent label’s set, but aside from that, if you can create a regular label, you’ll have no difficulties creating a sublabel.

Like regular labels, sublabels must be deployed to end users through label publishing policies. Each policy publishes a selected set of labels to target users. If a policy includes a parent label, make sure to include all its sublabels.

The Purview compliance portal doesn’t allow regular labels to become sublabels or vice versa. However, this can be done using PowerShell. To do this, you must sign into the Exchange Online management module and then connect to the compliance endpoint to retrieve details of the sensitivity labels defined in the tenant. The important information you need is the ImmutableId, the GUID that identifies a sensitivity label. Here’s how to sign into the compliance endpoint and list the current set of sensitivity labels:

Connect-IPPSSession

Get-Label | Format-Table Name, ImmutableId

Name                             ImmutableId
----                             -----------
Public                           2fe7f66d-096a-469e-835f-595532b63560
No Encryption                    8b652c9a-a8b7-40ec-bb1a-c5334b1b7fef
Non-business use                 a49e1277-93db-4a2f-8105-43c5196b4fef

Find the label you want to be the parent and the label you want to make into a sublabel. Then run the Set-Label cmdlet to connect the two labels using their GUIDs.

Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -ParentId "d179cfc9-43d4-41b6-9ddb-3e1aaf3224c8"

Transforming a regular sensitivity label to become a sublabel changes the priority order of the label. This can lead to priority mismatches when users apply the sublabel to files stored in SharePoint Online if container management labels are used to manage sites. It’s a small point to be aware of.

To disconnect a sublabel from a parent label, run Set-Label and set the parent label identifier to $null. These commands disconnect a sublabel and resets its priority:

Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -ParentId $null
Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -Priority 30

Organizational Culture Drives the Decision

Deciding to use or avoid sublabels essentially comes down to organizational culture. Companies with a computer-literate user community might find the granular nature of sublabels easy to use where a tenant supporting less technology-oriented groups might find that a simple list of sensitivity labels is the best approach. As part of the deployment process, it’s a good test to test both approaches to see which works best.

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.

Conditional Access MFA Gives Outlook Desktop a Problem with Protected Email

I think most Microsoft 365 tenant administrators would agree that multifactor authentication (MFA) is a good thing. MFA stops bad guys compromising accounts even if they have the password. Microsoft’s recent little bother with Midnight Blizzard could have been cut off had the account whose password was uncovered by a password spray attack been protected with MFA.

Sensitivity labels are also good in terms of their ability to protect sensitive Office documents and PDF files with encryption. The usage rights assigned in sensitivity labels stop people who don’t have access from being able to decrypt and view the content of protected files.

Two good things create a warm feeling of snug protection, or so it might seem. That is, until conditional access policies get in the way. Specifically, conditional access policies that insist on MFA for all cloud apps without exclusions. This seems like a very good kind of policy because it enforces MFA before users can connect to OWA, the new Outlook “Monarch” client, SharePoint Online, Teams, and so on. However, “all cloud apps” means all cloud apps, including the Microsoft Rights Management Services app. This is a multi-tenant app that exists in tenants that use Microsoft Information Protection, the basis of the encryption applied by sensitivity labels to protect files.

Get-MgServicePrincipal -filter "displayname eq 'Microsoft Rights Management Services'" | Format-Table DisplayName, AppId, SignInAudience

DisplayName                          AppId                                SignInAudience
-----------                          -----                                --------------
Microsoft Rights Management Services 00000012-0000-0000-c000-000000000000 AzureADMultipleOrgs

Let’s assume that you deploy a conditional access policy to enforce MFA for all cloud apps. With this configuration in place, users generate and send some protected email by applying sensitivity labels with encryption. Some messages go to external recipients, but that’s OK because the usage rights defined in the labels allow the external recipients to access the content.

The Problem with MFA for All Cloud Apps

All works wonderfully if the external recipients use OWA, Monarch, or Outlook Mobile to read the messages. Decryption for these clients is managed by Exchange Online, which obtains the necessary use licenses to allow the clients to access the content. However, Outlook desktop (Win32) uses a different scheme and must obtain use licenses from Microsoft Rights Management Services running on the originating (your) tenant. This is when you see the dialog telling you that Outlook is configuring the computer for Information Rights Management (Figure 1).

But the conditional access policy in the sending tenant insists on MFA for all cloud apps and there’s no way for Outlook to satisfy an MFA challenge in your tenant. Deprived of the use license, Outlook falls back to displaying the RPMSG wrapper for the message (Figure 2).

Clicking the read the message link brings the user to the Office 365 Message Encryption portal, where they can read the message. This proves that the usage rights given to the user allow access. The problem lies with not being able to obtain the use license due to the MFA challenge.

Excluding Microsoft Rights Management Services

The simple solution is to exclude the Microsoft Rights Management Services app from all conditional access policies that enforce MFA for user connections. This is easily done by editing policies through the Entra admin center (Figure 4).

PowerShell makes it easy to scan and update conditional access policies in the tenant. A similar approach to the one to add breakglass accounts to conditional access policies can be used to add an exclusion to policies.

The script (available from GitHub) performs these steps.

• Connects to the Microsoft Graph PowerShell SDK.
• Runs the Get-MgIdentityConditionalAccessPolicy cmdlet to find the set of enabled conditional access policies.
• Checks each policy to see if an exclusion for the Microsoft Rights Management Services app is present.
• If no exclusion is present, the script checks if the policy uses MFA (with or without authentication strength) as a control.
• If the policy applies MFA, the script checks if a forced password change is set (this eliminates the possibility of adding an app exclusion) and that the policy doesn’t use an authentication context. Both prevent the addition of an excluded app to the policy.

Once it’s sure that an exclusion is possible, the script adds the exclusion. Figure 5 shows the script in action.

It’s an Ecosystem Thing

It’s unfortunate when a clash occurs between two important parts of the Microsoft 365 ecosystem. It’s a reminder to us all about the importance of taking a holistic view of functionality instead of focusing on a single workload. Some will think that this problem is something that Microsoft testing should have found. That’s a fair perspective, and Microsoft’s documentation does cover some potential issues with conditional access and encrypted documents, but it’s unlikely that the testing regime considers how sensitivity labels work with Outlook desktop for external recipients when MFA is involved.

Any debate must be tempered by the realization that the clash appeared due to the increased usage of multifactor authentication (due to incessant campaigning by Microsoft) allied to increased use of sensitivity labels to protect information. Both are good trends.

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.

Find SharePoint Documents to Decrypt Before Tenant Divestiture

A reader wanted to know the best way to find a bunch of files protected by a sensitivity label. The scenario is that the organization had divested an operating division. Sites used by that division had protected files that needed to be decrypted before they moved to a new tenant. If this failed to happen, the protected files would be inaccessible in the new tenant because the users signing into that tenant didn’t have the right to access their content. The question therefore is what’s the best way to find SharePoint documents protected by sensitivity labels so that administrators can remove the labels before the divestiture.

Office documents store label information in their file attributes, so the basic task is to search those attributes to find files protected with one or more specific labels. You could try and do the job with PowerShell and the Graph API. For instance, I have a script to report the files in a SharePoint document library, including the labels assigned to files. Another script uses the Unlock-SPOSensitivityLabelEncryptedFile cmdlet from the SharePoint Online management module to remove labels from documents. The two could be combined to find and remove labels from protected files.

The PowerShell approach is viable if the exercise spans several thousand documents in a few sites. Things become more problematic as the numbers scale up. For instance, sites with document libraries configured to apply default sensitivity labels to new documents (requires Office 365 E5 licenses) could accumulate thousands of protected documents in each library.

Using eDiscovery Searches to Find SharePoint Documents Protected by Sensitivity Labels

eDiscovery searches could solve the problem. Microsoft Purview eDiscovery (Premium) supports finding protected content. The documentation says that files “located on a SharePoint or OneDrive account are searchable and decrypted when the search results are prepared for preview, added to a review set in eDiscovery (Premium), and exported.” Figure 1 shows search preview displaying a protected document found by eDiscovery (Premium).

eDiscovery Premium can’t process documents protected by sensitivity labels with user-defined permissions (permissions assigned by the document author when they apply the label to the document) or when user access granted by the sensitivity label has an expiration date. In addition, eDiscovery Premium can’t decrypt files protected by the Azure Information Protection unified labeling client that are subsequently uploaded to SharePoint Online or OneDrive for Business.

Purview eDiscovery (Standard) and content searches can also find items protected with sensitivity labels. However, these solutions do not decrypt the content unless an unprotected document is an attachment for a protected email. That’s OK, because if you find and export the protected files, an Azure Information Protection (AIP) super-user can remove labels from files using the Set-AIPFileLabel cmdlet from the Azure Information Protection module. Although this is feasible, if you’re contemplating processing thousands of documents, I would buy some Office 365 E5 licenses and use Purview eDiscovery (Premium).

Configuring Content Searches to Find SharePoint Documents with Sensitivity Labels

To search for SharePoint files through Microsoft Search or a Purview content search, you use sensitivity label identifiers (GUIDs). The SharePoint Online search schema includes a managed property called InformationProtectionLabelId, which holds the GUID (identifier) for the sensitivity label assigned to a document. You can use this property to search for documents with a specific sensitivity label in SharePoint search or content searches by using the form InformationProtectionLabelId:GUID. For example, InformationProtectionLabelId:2fe7f66d-096a-469e-835f-595532b63560. The search results are trimmed and only display documents whoever performs the search can access.

An alternative approach is to remap the Sensitivity property, which stores the local language value of the label, to one of the 200 customizable RedefinableString managed properties available in SharePoint Online. This approach allows users to search using label names like “Public” and “Confidential,” but the downside is that it’s possible to assign multiple local language values for sensitivity label display names. If this happens, the searches would need to look for all defined values. By comparison, the identifier is unique and immutable, so using label identifiers is a better choice for search criteria.

To find the label identifiers, connect a PowerShell session to the compliance endpoint and run this command:

Get-Label | Format-Table ImmutableId, DisplayName

ImmutableId                          DisplayName
-----------                          -----------
2fe7f66d-096a-469e-835f-595532b63560 Public
8b652c9a-a8b7-40ec-bb1a-c5334b1b7fef No Encryption
a49e1277-93db-4a2f-8105-43c5196b4fef Non-business use
fb0975b2-1ea1-4c3c-850c-e859e690d282 Partner-Accessible Content
e42fd42e-7240-4df0-9d8f-d14658bcf7ce General Access

Now create a content search and input the label identifier into the search conditions, prefixed with InformationProtectionLabelId, just like shown in Figure 2:

To search for documents with different sensitivity labels, separate the label identifiers with OR. For example, here’s the Keyword Query Language (KQL) query to find documents with either of two labels created between 19 May 2023 and 23 June 2023:

InformationProtectionLabelId:1b070e6f-4b3c-4534-95c4-08335a5ca610 OR InformationProtectionLabelId:2fe7f66d-096a-469e-835f-595532b63560(c:c)(date=2023-05-19..2023-06-23)

Dealing with Protected Content

Searching for protected files isn’t difficult. The real question is what you do with the files that the search uncovers. Having a bunch of encrypted files (with or without the new and improved encryption cipher) isn’t much good unless you can decrypt them. That’s where most of the problems lie, which is why Microsoft might have included the feature in Purview eDiscovery (premium).

Learn about using sensitivity labels, eDiscovery, and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

AES256-CBC Will Protect Office Documents and Email

Last year, some researchers expressed worries that the AES 128 ECB (Electronic Cookbook Mode) cipher used by Microsoft Information Protection to encrypt documents and emails could be compromised. Microsoft uses the cipher to ensure backward compatibility with older Office versions.

The need for backward compatibility appears to have lifted. Announced in MC590144 (June 15, 2023, Microsoft 365 roadmap item 117576), Microsoft Information Protection will start using AES 256 in Cipher Block Chaining (AES256-CBC) mode from late August 2023 with full deployment expected by the end of September 2023.

Sensitivity Labels Apply Better Protection

In practical terms, if you apply a sensitivity label (Figure 1) to an Office document, export an Office document to a PDF, or email (including meetings), or use the Purview Message Encryption feature (previously Office 365 message encryption or OME) to set Do Not Forward or Encrypt-Only for emails, the level of encryption protecting those items will increase. Items previously protected will receive the upgraded protection the next time the items go through an encryption/decryption cycle. For instance, if someone edits a protected document stored in a SharePoint Online document library, SharePoint will apply the improved encryption when it saves the file. Full details are available in this Microsoft Technology Community post.

Enhanced protection is available in the Microsoft 365 apps for enterprise, SharePoint Online, Exchange Online, Purview Message Encryption, the Azure Information Protection (AIP) unified labelling client (version 2.17 or later), AIP PowerShell module (2.17 and later), and the Purview Information Protection Scanner for on-premises repositories.

Third-party applications built using the Microsoft Information Protection SDK 1.13 or later support items protected with AES256-CBC. This includes the paid-for versions of Adobe Acrobat that can apply and manage sensitivity labels. It might take a little time for ISVs to issue upgraded versions of their products that support AES256-CBC.

Impact on Four Groups

Although the transition to AES256-CBC should be seamless for Microsoft 365 tenants, Microsoft calls out four groups of customers that the change will impact. These are organizations:

• Using the subscription version of Office (Microsoft 365 apps for enterprise) with Exchange Server (on-premises or hybrid). The Exchange development group is working on a patch to allow Exchange Server to support AES256-CBC that should be available in July. However, the patch will only be available for Exchange Servers with support, so that means the latest versions of Exchange 2016 and Exchange 2019. Microsoft will automatically exclude organizations using the Azure Rights Management connector from using AES256-CBC until January 2024 to allow them time to apply server upgrades.
• With applications built using the Microsoft Information Protection SDK. These organizations must upgrade their applications to V1.13 of the SDK.
• Using perpetual versions of Office (2016, 2019, and 2021 LTSC). These versions can consume items protected with AES256-CBC, but some work is needed to allow clients to create items protected with the new cipher.
• Using the current version of the AIP Viewer, PowerShell module, or Scanner. Workstations need to upgrade to the latest version of the unified labeling client to enable support for AES256-CBC for components installed by the client.

Failure to take action to upgrade installations before Microsoft rolls out the change in August 2023 will result in Exchange Server failing to decrypt protected email. More details are available in Microsoft’s Technical community post.

Moving to Stronger Encryption

Even if the potential for compromise required attackers to follow an unlikely path, Microsoft has answered the doubts expressed by researchers with this update. That’s a welcome change that will kick in during August 2023. Users shouldn’t be aware of the transition and won’t be impacted by the change if administrators of the highlighted organizations take action.

For more information about the transition to AES256-CBC, see Microsoft’s documentation.

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.

Making Plans to Introduce Sensitivity Labels for Meetings

I previously wrote about how sensitivity labels protect meetings created in Outlook and OWA and the way that labels can apply settings to Teams meetings, if meeting organizers have Teams Premium licenses. In that article, I said that introducing sensitivity labels for meetings requires up-front planning. This article discusses some of the topics that such a planning exercise might cover.

Label Scoping

Scoping defines to what objects applications can apply labels. In the past, the split was simple: information protection (encryption) for files and emails or container management for groups, sites, and teams. The introduction of meetings and a recent update to introduce separate scopes for emails and files (MC514980, updated 3 Mar 2023, Microsoft 365 roadmap item 99939) means that things are a tad more complex now (Figure 1).

Looking at the options to define the scope for a sensitivity label, you can select the following for items:

• Emails: Labels are only available to Outlook clients.
• Files: Labels are available in Word, PowerPoint, and Excel (Online, subscription, and mobile). These labels are also assignable to PDFs by the Adobe Acrobat paid-for products (or by export from Office) and to files stored outside Office 365 by the AIP extension for Windows Explorer.
• Meetings: Labels are available for meetings created in Outlook and OWA and the Teams desktop and browser clients. Because meetings include elements of email (meeting notifications and responses) and files (attachments), if you select this option, you must also enable the label for Emails and Files.

In the past, I have recommended having separate sets of sensitivity labels for information protection and container management. I think this approach leads to easier management because labels serve one purpose. The question now is should we have separate labels for meetings?

It’s a harder question to answer because meetings require files and emails. If Microsoft had created a scope for meetings that implicitly includes files and emails but didn’t display these labels for users to apply to email and documents, then I’d say yes. Because they didn’t, any label created for meetings is also available for email and documents, so we need a different approach to guide users.

Label Naming

The obvious answer is the display name assigned to sensitivity labels for meetings. By including “Meeting” in some form in the display name of labels created to protect meetings, hopefully people will use the labels for their intended purpose and not to label documents and emails.

To start, we might create a limited set of sensitivity labels for meetings:

• Public (no protection – label is for visual marking only).
• Internal meeting (protection limits editor access to tenant members).
• External meeting (protection limits access to anyone who can authenticate against Azure AD).

As time goes by and experience develops, the need might emerge for other labels. For example, if the finance and legal departments work with external advisors, the organization might decide to create sensitivity labels for their meetings with a label policy to publish the labels to users in those departments. The protection in these labels could assign co-editor permission to people in the domains owned by the external advisors to allow them to edit documents shared in meetings.

You can create display names for sensitivity labels with a maximum of 64 characters (excluding % \ & < > | ? : and ;), so plenty of room exists for innovative naming schemes. Just remember some basic facts about labeling:

• Applications have limited space to display label names (especially mobile apps).
• If you create a wide range of sensitivity labels for different scopes, users might have difficulty deciding upon the most appropriate label to apply to items.

Figure 2 shows the effect of scoping and naming, Only four sensitivity labels in the tenant are scoped for meetings. Each has a name that is clear in its purpose (the Very Secret label is a little tongue in cheek; Confidential would be a better name). A checkmark appears beside the Internal meeting label, meaning that it is the selected label. When a label is automatically selected for new meetings, it’s because it is the default label for meetings selected in the sensitivity label policy published to this account.

Keep It Simple

Keeping it simple is key. Use scoping to make sure that applications make appropriate sensitivity labels to users. Give the labels clear and understandable names. If necessary, translate the display names of labels for use in multinational organizations. Follow those two simple rules with the sensitivity labels used for meetings and users should be happy.

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

Outlook and Teams Meetings Both Benefit from Added Protection

Published in message center update MC513052 (last updated 27 April 2023, Microsoft 365 roadmap item 98924) and finally rolling out over May, Outlook (Mac, Windows, and OWA) can assign sensitivity labels for meetings. That is, if you have Office 365 E5 licenses.

Last October, I speculated that Microsoft’s claim of protection and recaps for Outlook and Teams meetings would be deliver very different functionality. Now we see that protecting meetings is a multi-part story composed of:

• Defining and publishing sensitivity labels configured with the meeting protection setting.
• Defining and publishing sensitivity labels configured with Teams online meeting settings. Meeting organizers require Teams Premium licenses to use sensitivity labels with Teams online meeting settings.
• Defining and publishing Teams meeting templates describing different forms of meetings (internal, external, highly secure) to help users choose the right configuration for their meetings. Microsoft describes a concept of three tiers of protection for Teams meetings.

This article covers the basics of creating and using sensitivity labels with Outlook meetings.

Using Outlook to Assign Sensitivity Labels for Meetings

Sensitivity labels have always been able to protect “normal” email, including attachments. Meeting requests and responses are a different form of emails because they include metadata about a meeting (date and time, location, and attendees) that a recipient can use to create an event in their calendar. Given that people often include a great deal of confidential information in meeting requests, I don’t know why Microsoft did not extend protection to calendar messages until now.

When you apply a sensitivity label with encryption to a meeting, the body (text containing details of the event) and any attachments inherit the rights management protection defined in the label. Other information like the meeting title and participant list is not encrypted. This is like normal messages where encryption protects only the content and attachments of messages.

Figure 1 shows how to assign a sensitivity label to a meeting with OWA. Only the set of sensitivity labels configured to protect meetings appear in the drop-down list for users to select from. You can configure a default sensitivity label to apply to all meetings through the sensitivity label policy that publishes labels to users.

A protected meeting operates like any other protected email. Outlook wraps the contents of the message and its attachments in a protected rpmsg message. If the receiving client is “enlightened” (it knows how to process protected messages), it can decrypt the message and display it inline. If not, the user receives a link to access the content through the Office 365 Message Encryption (OME) portal. Note that clients can only open protected messages if the recipient has the right to view the content. The rights are set in sensitivity label properties and will stop people who don’t have the right to view content opening the messages. For instance, the “Internal meeting” label might restrict access to users within the tenant. If someone outside the tenant is a meeting participant, they cannot open the message.

Points to Ponder

While working with protected meetings, I noticed a couple of points worth highlighting:

• You can insert a Loop component in a meeting request created in OWA. Recipients can edit the content of the Loop component even if the sensitivity label blocks edit access. This is because Loop doesn’t support sensitivity labels yet. Current builds of Outlook desktop (subscription) doesn’t support adding Loop components to meeting requests.
• If you assign a restrictive sensitivity label to a meeting, you might stop meeting participants being able to edit attachments. This might be what you want to do, but it’s a change in behavior that users need to understand.
• Sensitivity labels determine rights based on email addresses. If someone forwards a protected meeting invitation to someone else, they might not be able to access the content if the rights specified in the label doesn’t have an entry that matches their email address (or domain). One advantage gained is that if people forward meeting invitations without permission outside the organization, the external recipients won’t have access to the meeting content.

Sensitivity Labels for Meetings in Outlook Mobile

Outlook Mobile can open protected messages (decryption occurs on the server) and can process inbound events to include them in the calendar. However, the meeting body is not decrypted (Figure 2), which means that the user knows they have a meeting to attend but can’t see the text explaining what the meeting is about unless they open the meeting with Outlook desktop or OWA. However, the deeplink for the Teams meeting remains usable because it is not encrypted.

In addition, Outlook mobile cannot send protected meetings because the client doesn’t include the encryption technology needed to apply protection.

Don’t Rush to Deploy Sensitivity Labels for Meetings

Introducing protected meetings isn’t something to do on a whim. Like any information protection project, some consideration is needed, especially if sensitivity labels are already deployed. That topic deserves a separate article, which I’ll get to in due course.

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.

Need Recedes for Unified Labeling Client

On April 11, Microsoft announced that they will retire the AIP client, aka the Unified Labeling client, aka the AIP add-on for Office, on 11 April 2024. The add-on has been in maintenance mode since January 1, 2022, so its final retirement was only a matter of time. Once retirement happens, users cannot assign sensitivity labels to documents through the add-on.

A Long Road

In 2016, when I first started writing about how to protect Office documents with labels, the labels were called Azure Information Protection labels and users needed to install the add-on to add elements like the information protection bar and the code to apply rights management to documents. The situation was natural because Azure Information Protection was a separate product that targeted Office but had no formal alignment with Office development. The add-on was only available for Office on Windows.

Things changed when Microsoft decided that sensitivity labels were strategically important to Office 365, which meant that they needed to build support for sensitivity labels across the infrastructure in apps like SharePoint Online and Exchange Online and desktop, browser, and mobile apps. Sensitivity label support is now broad and deep across Microsoft 365, including for container management of sites, groups, and teams. Regretfully, sometimes Microsoft demands additional licenses for features that seem very basic, such using the Syntex-SharePoint Advanced Management license to control the assignment of default sensitivity labels to SharePoint document libraries.

In 2019, Microsoft started the process of removing the add-on by incorporating the code to handle sensitivity labels in the Office applications (native mode protection). The goal is to provide the same or better functionality in the out-of-the-box Microsoft 365 apps for enterprise (Office desktop) versions of Word, Excel, and PowerPoint. Microsoft says that the Microsoft 365 apps for enterprise “now have most of the capabilities found in the AIP Unified Labeling add-in for Office as well as advanced capabilities not possible with the AIP Unified Labeling add-in for Office.” The most important of these capabilities are:

• PDFs exported from the Office apps retain protection applied by sensitivity labels.
• Sensitivity labels can protect meeting invitations (including attachments) and responses.
• Account switching.
• Users cannot disable labeling controls.

Microsoft has long stressed that incorporating code from the Microsoft Information Protection SDK to make applications natively aware of information protection leads to better performance and increased stability. In other words, something that’s built-in is likely to work better than when an application needs to load in external code.

Native protection is only available with the subscription versions of Office. The functionality isn’t supported by perpetual versions of Office like Office 2019.

Making Changes to Ease Migration

Technologies that affect how people work are usually harder to migrate to new platforms than background processing is. Changes to Office applications are good examples of the truth of this assertion (as anyone who remembers the introduction of the ribbon in Office 2007 can attest).

As an example, the add-on features an information protection bar that people like. The Microsoft 365 apps don’t use the information protection bar. Instead, Microsoft has changed the menu and title bars of the Office apps to highlight labels in a different way, including displaying different colors for different labels. The latest tweak is in Outlook desktop, where the latest builds feature a prominent new button to allow users to more easily assign a sensitivity label to emails (Figure 1).

Other Azure Information Protection Elements

I stopped using the unified labeling client two years ago. However, I have installed the unified labeling client on PCs to get other elements that came with the add-on such as the Azure Information Protection PowerShell module and the ability to classify and protection files from the Windows Explorer. The PowerShell module is especially helpful when the need exists to remove sensitivity labels from files.

Microsoft says that they are not retiring these elements, nor are they retiring the viewers that allow people to view protected content on Windows, iOS, and Android, or the Azure Information Protection Scanner. Microsoft says that following the retirement of the add-on, they will remove it from the installable package available in the Download Center. User will be able to install the new version of the package to access the other elements, which will also be rebranded as Microsoft Purview capabilities.

Time to Move On

The unified labeling client or add-on for Office has served its purpose. It’s time to let it go and migrate as quickly as possible to use the built-in capabilities that exist in Office. Apart from the small fact about the retirement, it’s clear that Microsoft has poured engineering effort into building out the sensitivity label infrastructure across Microsoft 365 for the last several years. Benefit of that work isn’t available to the add-on, which is a good a reason to move on as anything else.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Understanding Who Does What with Sensitivity Labels

The Activity explorer is in the Data Classification section of the Microsoft Purview Compliance portal. Its intention is to allow tenant and compliance administrators to understand how users apply retention and sensitivity labels to files and messages over the last 30 days. The Activity explorer also surfaces retention label usage and DLP activities, but in this discussion, we focus on analyzing the use of sensitivity labels.

The information presented in the Activity Explorer comes from the unified audit log. Microsoft’s documentation says that extraction “transforms” the audit data. In other words, Activity Explorer extracts the relevant information from the audit event payloads and presents the data in a more accessible form along with a set of filters to cut and dice the data in whatever way you want.

Good as the Activity Explorer UX might be, it’s not a tool to perform any in-depth analysis of audit data relating to sensitivity labels, especially when the volume of events generated daily grows. In this article, I explain how to extract the audit payload information for events relevant to user application of sensitivity labels to documents and messages and answer questions like who applies sensitivity labels and what labels they use.

I’ve been down this path before to explore the audit events generated for sensitivity labels after Microsoft introduced the feature in early 2021. Time moves on and changes happen, so it was time to write a new script (available from GitHub) to demonstrate the principle of analyzing sensitivity label audit records. Feel free to expand its code to meet your needs.

Fetching Sensitivity Label Data

Many audit events related to sensitivity labels hold the immutable identifier for the label rather than its display name. To find the set of labels in the tenant, connect to the compliance endpoint with Connect-IPPSSession and run the Get-Label cmdlet. To make it convenient to convert an identifier to the label name, put the results in a hash table.

Write-Host "Retrieving sensitivity labels used in the tenant"
$Labels = @{}
[array]$LabelSet = Get-Label | Select-Object ImmutableId, DisplayName
If (!($LabelSet)) { Write-Host "Can't find any sensitivity labels - exiting"; break }
ForEach ($L in $LabelSet) { $Labels.Add([string]$L.ImmutableId, [string]$L.DisplayName) }

Fetching Audit Data

The next step is to retrieve relevant audit records from the audit log. This code:

• Declares the set of audit operations to fetch.
• Sets start and end dates for the audit log search. Office 365 E3 tenants can go back 90 days while Office 365 E5 tenants can fetch data for the last year.  Depending on the volume of audit events generated in your tenant, you might need to reduce the timespan for the search.
• Calls the Search-UnifiedAuditLog cmdlet to perform the audit log search.
• Removes any DLP events returned by the search. If a DLP policy applies a sensitivity label to an email message, Exchange also logs an MIPLabel event. The script only needs to process one event, so it drops the DLP events.

$Operations = ("SensitivityLabelUpdated", "SensitivityLabelApplied", "FileSensitivityLabelApplied", "MIPLabel")
$StartDate = (Get-Date).AddDays(-90)
$EndDate = (Get-Date).AddDays(1)
[Array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Formatted -ResultSize 5000 -Operations $Operations
If (!($Records)) { Write-Host "No audit records for sensitivity label application found - exiting" ; break }

$Records = $Records | Where-Object {$_.RecordType -ne "ComplianceDLPExchange"}

Analyzing Audit Data

Every audit record has a payload in a JSON-formatted property called AuditData. Although some of the important properties for an audit event, such as the user, operation, and timestamp, are available without going near AuditData, to extract details of the action captured in an audit record, the code must convert AuditData.

After converting AuditData, a Switch statement processes audit records for the different operations. For instance, here’s what happens for a SensitivityLabelApplied event:

    "SensitivityLabelApplied" {
     $Type = "Label assigned by user"
     $LabelAdded = $Labels[$AuditData.SensitivityLabelEventData.SensitivityLabelId]
     $Application = $AuditData.Application
     $ObjectId = [System.Web.HttpUtility]::UrlDecode($AuditData.ObjectId)
     $Item = $ObjectId.Split('/')[-1]	
     $Site = "https://" + $ObjectId.Split("/")[2] + "/sites/" + $ObjectId.Split("/")[4] + "/"
    }

Before writing out details of an audit event, the code checks if the user noted is one of the special SharePoint accounts. In addition to manual user application of a sensitivity label to an Office document or PDF file, the system can assign labels through an auto-label policy or if an administrator defines a default sensitivity label for a document library. To highlight these operations, the code updates the type property for the report.

If ($UserId -eq "app@sharepoint") {
     $Type = "Default label applied by document library" 
 } ElseIf ($UserId -eq "SHAREPOINT\system") { 
   $Type = "Label applied by auto-label policy" } 

Assigning sensitivity labels as the default for a document library or through an auto-label policy requires Office 365 E5 or Microsoft 365 Compliance E5 licenses. See Microsoft’s compliance licensing guidelines or the PDF download specifying Purview features and licensing requirements.

Reporting the Data

After processing each audit record, the code updates a PowerShell list containing the report output. As usual, you can do whatever you want with the data. To answer the questions posed above, I used the Group-Object cmdlet to generate this result:

Most commonly used sensitivity labels
-------------------------------------

Name                  Count
----                  -----
Public                  109
Confidential             33
Internal                 15
Eyes Only                 5
Sensitive Stuff           3
Black Matter              3
No Encryption             1
Secret                    1
Market Sensitive          1

Given that the Public label is the default for the document library I use to hold blog posts, it’s not surprising that it’s at the top of the list. When reviewing who applied sensitivity labels (Figure 1), it was no surprise that that my account came in on top. I also found non-tenant users listed among those who applied labels. This can happen if the tenant has a mail flow rule that applies sensitivity labels to inbound messages.

Exporting Activity Explorer Data

If you’re interested in a more general export of the data used by the Activity Explorer, Microsoft released the Export-ActivityExplorerData cmdlet to general availability in October 2022. It’s not the most elegant cmdlet available in the Exchange Online management module (V3.0 or later), but it might do a job for you. For more information, Vasil Michev covers the Export-ActivityExplorerData cmdlet on his blog.

No Consistency in Audit Payloads

It would be nice if Microsoft 365 engineering groups all generated the same kind of content in audit records. The basics of audit records are consistent, but the information inserted into the audit payload varies dramatically across workloads. The lack of consistency means that those who want to interrogate the audit log to extract information (including the Activity Explorer) must jump through hoops to get what they need. That’s a real pity because it makes the audit log a less accessible asset for tenant administrators.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Default Sensitivity Label for SharePoint Document Libraries Now Rolling Out Worldwide

Update 2 April 2023

In January 2022, I explained the process to assign a default sensitivity label to a document library in a SharePoint Online site. At the time, Microsoft was in the early days of the feature’s development and the configuration was a very manual process. Now, the public preview software is generally available worldwide. Documentation to set up and use the feature also available.

Setting a default sensitivity label is very simple. Select Library settings from the cogwheel menu and choose the desired sensitivity label (Figure 1). Naturally, you can only select a label that’s configured for file and email protection rather than those set up for container management. If you have multiple document libraries in a site, each library can use a different default sensitivity label. That’s a nice touch because usually if a site has multiple libraries, the libraries serve different purposes, and the chosen label can reflect that purpose instead of being a one-size fits-all selection.

Licensing

Although Microsoft hasn’t confirmed this, assigning a default sensitivity label to a document library will follow the usual line of regarding anything that performs an automatic action as a premium feature. Accordingly, you’ll need Office 365 E5 or Microsoft 365 E5 Compliance licenses to use the feature when it is generally available.

Update: The feature is now available and requires one of these licenses:

• Microsoft Syntex – SharePoint Advanced Management
• Microsoft 365 E5/A5/G5
• Microsoft 365 E5/A5/G5/F5 Compliance
• Microsoft 365 F5 Security and Compliance
• Microsoft 365 E5/A5/G5/F5 Information Protection and Governance
• Office 365 E5/A5/G5

PDF Files and Existing Documents

As Microsoft’s documentation explains, the reference to support for PDF files in the UI is incorrect. New Office documents uploaded by users receive the default label within a few minutes, but PDFs are ignored for now. It’s likely that Microsoft will address this issue when the feature is generally available toward the last quarter of 2022.

New documents that have labels are ignored. Existing documents already present in the library are also ignored. In other words, SharePoint Online doesn’t scan all documents and apply the default sensitivity label to any without an assigned label. However, when users edit Office documents that don’t have an assigned label, SharePoint Online will apply the default sensitivity label defined in the policy applicable to the site. This change is due in mid-October 2022.

More Changes Coming for PDFs

In June, Microsoft announced that Office applications would maintain sensitivity label support when used to create PDFs. This is part of Microsoft’s work to remove the need for organizations to deploy the now-deprecated unified labelling client to apply sensitivity labels to PDFs. According to MC387639, the public preview for this functionality should be available around about now.

An associated message center notification (MC411677, August 10 2022) lets Visual Basic for Applications (VBA) developers know that soon PDFs generated when VBA scripts use Office features will also maintain sensitivity labels for the output files. This is Microsoft 365 roadmap item 93406. Microsoft is warning that some VBA add-ins will need to be updated when the change is effective in December 2022.

Meanwhile, Adobe is running a preview program to allow its Acrobat product to apply, remove, and update sensitivity labels to PDFs. The free Adobe Acrobat DC reader product has been able to read protected PDFs (if the user has the appropriate rights granted by the sensitivity label) for several years. The new functionality is currently understood to be limited to Adobe’s paid-for products.

Sensitivity Labels Increasingly Mainline

It takes time for a new technology to become mainline. Sensitivity labels are getting there. Native (built-in) support for encryption, decryption, and rights management within apps are important steps forward. Office and PDF documents are the most common formats used within Microsoft 365. Their increasing embrace of sensitivity labels makes it easier for people to protect their most sensitive information, and that’s a good thing, even if it makes it a little harder for ISVs to process encrypted user data.

Keep up to date with developments like the app support for sensitivity labels by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

The Long Road to Progress

Sensitivity labels do an excellent job of protecting Office documents, largely because the applications include the necessary code to apply and access encrypted documents. The situation is less successful when dealing with other common business file formats (like protected PDFs). The now-almost obsolete unified labeling client contains an Explorer extension that allows users to Classify and protect files. This approach works for some file types (like the MP4 files generated by Teams meeting recordings), but needs to be tested to ensure that it works and is usable for other kinds of files.

Things would be much better if maintainers of file types incorporated code from the Microsoft Information Protection (MIP) SDK into their products. For example, Adobe PDF is a very common file format used for business purposes. In December 2018, Adobe and Microsoft announced the availability of an integration of MIP with Adobe Acrobat Reader. Essentially, Adobe added code to support the opening of protected PDFs using a plug-in created by Microsoft.

Edge and Protected PDFs

In 2020, Microsoft upgraded the Edge browser to open protected PDFs. This made life easier because Edge can use cached credentials (from accessing other Microsoft 365 apps like OWA or OneDrive for Business) to validate a user’s identity and establish their rights to access protected content.

One issue that continues with Edge is that although it displays a banner to inform the user that they’re accessing a protected PDF, it doesn’t reveal the name of the sensitivity label (Figure 1). By comparison, Adobe Acrobat Reader DC displays the label when it opens a protected PDF (Figure 2).

Considering their tendency to throw the kitchen sink into Edge in terms of new features, it’s a curious omission on the part of the Edge developers.

On small point: since the launch of the MIP plug-in for Adobe, a registry value controls the display of the information bar for sensitivity labels. Originally, it was necessary to have a single DWORD value called bShowDMB set to 1 at HKEY_CURRENT_USER\SOFTWARE\Adobe\Acrobat Reader\DC\MicrosoftAIP to expose the information bar.

For whatever reason, with the latest update, Adobe appears to have moved the value to HKEY_CURRENT_USER\SOFTWARE\Adobe\Adobe Acrobat\DC\MicrosoftAIP. Or maybe the value needs to exist in both locations. My PC currently only has bShowDMB set at Adobe Acrobat\DC\MicrosoftAIP and everything is working.

Issues with Protected PDFs

Although it became less difficult to open protected PDFs, two issues remained:

• Microsoft deprecated the unified labeling client. Its strategy is to build native MIP support into applications instead of depending on a separate client. The unified labeling client is now in maintenance mode.
• Having to download and install a separate MIP plug-in for Adobe Acrobat is a separate administrative operation that users often overlook. This leads to frustration when they can’t access protected PDFs.

Another issue is that you can’t apply sensitivity labels to items stored in SharePoint Online or OneDrive for Business through the browser GUIs. This doesn’t matter so much for Office documents because sensitivity label support is available in the application. However, it means that if you want to protect PDFs, you must apply sensitivity labels using the unified labeling client before uploading the PDFs to Office 365. This action requires users to have Azure Information Protection licenses.

Improving Sensitivity Label Support for PDFs

Help is on the horizon. Three developments are coming together to make protected PDFs easier to generate and use.

• The latest Office Insider build includes the ability to output protected PDFs when saving, exporting, or sharing Office documents with sensitivity labels. The output PDFs inherit the same protection as applied to the source documents. Some gotchas exist, like the need for developers of PDF add-ins to potentially update their code and the inability to retain protection when printing to PDF. Even so, this is a big step forward because it removes the need to use the unified labeling client to apply a sensitivity label to protect PDFs.
• The latest version of Adobe Acrobat Reader DC (version 22.001.20142 and later) bundles the MIP plug-in with its installer, removing the need for a separate installation. The benefit of hindsight is that bundling the plug-in is something that Adobe probably should have done sooner.
• Microsoft 365 roadmap item 93331 (due in preview in June with general availability in October 2022) describes an integration with Adobe Acrobat to allow users to apply sensitivity labels within the application on Windows and macOS. Apparently, this covers the paid-for versions of Acrobat rather than the free reader, but it’s still an improvement. (update: the integration is now available)

While the Office update is the most important, collectively, these changes will make it much easier to create protected PDFs.

Keep up to date with developments like changes in sensitivity labels and Office by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Cleaning Up a Mess

Delegates are users granted access rights to another user’s mailbox or to a shared mailbox. Often, delegates receive full access permission to a mailbox to allow them to process inbound and outbound emails. The classic example is of an executive assistant supporting a senior manager. The assistant is the delegate with full authority over the manager’s mailbox and might even be able to send emails on their behalf or as the manager.

Delegate access is a well-known area of functionality for Exchange and Outlook. Despite different implementations in the various Outlook clients (here’s how it works for the mobile clients), things usually work without a hitch until some complexity arises. Dealing with emails encrypted using Microsoft Purview Information Protection (MIP) sensitivity labels is an example of that kind of complexity.

The good news is that Microsoft is enabling some control to how Outlook clients allow delegates to access and work with MIP-protected messages and their attachments. Differences exist between Outlook for Windows and the other Outlook clients interact with encrypted items and the controls Microsoft is now rolling out apply only to:

• Outlook Web App.
• Outlook for Mac.
• Outlook Mobile for iOS and Android.
• Mail App for Windows.

In their June 6 post, Microsoft acknowledges that “some inconsistencies” exist across the set of Outlook clients. Here’s what’s happening.

New PowerShell Cmdlets

The control is in the form of a set of three new PowerShell cmdlets in the Exchange Online management module. These are:

• Set-MailboxIRMAccess: Block a specified delegate from accessing encrypted messages in a user or shared mailbox.
• Get-MailboxIRMAccess: Check if a block exists for a specified delegate in a user or shared mailbox.
• Remove-MailboxIRMAccess: Remove a block from a user.

Full Access and Different Outlook Clients

Delegate access to encrypted messages depends on the type of mailbox and how the delegate receives full access permission:

• Outlook for Windows clients do not support delegate access to encrypted messages sent to user mailboxes. Delegates can only read encrypted messages if the sender includes the delegate as a TO or CC recipient. In this scenario, the delegate’s ability to read the message depends on the rights granted to them as a recipient. If the rights assigned to recipients include one applicable to the delegate, they can read the content. If not, they cannot.
• Outlook for Windows clients support delegate access to encrypted messages sent to shared mailboxes if the delegate has full access and auto-mapping is specified when the delegate receives permission to the mailbox. Auto-mapping forces Outlook for Windows to open the shared mailbox as part of the resources available to the delegate. It is the default used by Exchange Online and is assigned when granting full access to a delegate for a mailbox using the Microsoft 365 admin center or Exchange admin center.
• The other Outlook clients support delegated access to encrypted messages in both user and shared mailboxes if the delegate has full access to the mailbox.

Microsoft documents some restrictions that apply to delegate access for encrypted messages.

Blocking Access

To prevent delegates with full access to a user or shared mailbox from being able to view encrypted messages using clients other than Outlook for Windows, you can block their access by running the Set-MailboxIRMAccess cmdlet. For example, this command blocks the ability of Kim Akers to read any encrypted messages delivered to the Customer Services mailbox:

Set-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com -AccessLevel Block

To make sure that a block is in place, use the Get-MailboxIRMAccess cmdlet.

Get-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com

Identity                       User                           AccessLevel
--------                       ----                           -----------
Customer Services              Kim.Akers@office365itpros.com  Block

The time required to implement the block depends from client to client. OWA imposes the block within a few minutes, while other clients might take longer. It all depends when a client checks with the server to learn that a block is in place. When a block applies, delegates see that they don’t have the necessary permissions when they attempt to access encrypted messages (Figure 1).

A block placed on delegate access remains in place until an administrator removes it and only affects the ability of a delegate to read encrypted messages using clients that support the block. For instance, the block will stop a delegate reading encrypted messages in a shared mailbox using OWA or Outlook for iOS, but they can switch to Outlook for Windows to see the message content. In addition, blocking access does not hide message subjects, which can contain sensitive information, nor does it prevent a delegate from deleting or moving encrypted messages. The block exists for reading, and only works for clients that support the block.

To remove the block and restore the ability to read encrypted messages to a delegate, run the Remove-MailboxIRMAccess cmdlet:

Remove-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com

Good Block for Confidential Information

Microsoft is addressing a real customer need with these controls. There’s no point in protecting confidential messages with sensitivity labels if an unintended recipient (a delegate) can read the content. It would be nice if all the Outlook clients worked the same way. However, that’s probably too much to hope for until the One Outlook project delivers a common client across all platforms. Given the speed that Project Monarch is moving at, that might take some time yet.

Learn about protecting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

Advanced Setting Manipulated by PowerShell

For the last year, Microsoft has steadily added to the ability of sensitivity labels to manage different aspects of SharePoint Online sites. Possibly because of a desire not to clutter up sensitivity label settings in the GUI, the developers chose to manage the settings via PowerShell. Adding to the ability to manage the external sharing capability and default link settings, administrators can now control site sharing permissions (a preview feature) via a new advanced sensitivity label setting.

In the SharePoint Online browser interface, this option is available through Site Permissions – Site Sharing (Figure 1).

It’s possible to set site sharing permissions to block all but site owners with PowerShell by running the Set-SPOSite cmdlet with the DisableSharingForNonOwners switch. For example

Set-SPOSite -Identity https://office365itpros.sharepoint.com/sites/Office365Adoption -DisableSharingForNonOwners

However, the Set-SPOSite cmdlet doesn’t allow administrators to enable site sharing for non-owners. It’s a very simple off switch that cannot go back or set site sharing permissions to the option where only site owners can share the site. The new capability for sensitivity labels delivers a way to address these shortcomings, but only for sites assigned sensitivity labels with the advanced setting defined.

Available Site Sharing Permissions

Three site sharing permissions settings are available (the descriptions are from the GUI shown in Figure 1):

• MemberShareAll: Site owners and members can share files, folders, and the site. People with edit permissions can share files and folders. This is usually the default setting assigned to new sites.
• MemberShareFileAndFolder: Site owners and members, and people with edit permissions, can share files and folders, but only the site owners can share the site.
• MemberShareNone: Only site owners can share files, folders, and the site.

Updating the Site Sharing Permission

To assign a new site sharing permission, connect to the compliance endpoint by first connecting to Exchange Online (Connect-ExchangeOnline cmdlet) and then running the Connect-IPPSSession cmdlet. You then have access to the compliance cmdlets and can run the Set-Label cmdlet to update the MembersCanShare advanced setting. For example:

Set-Label -Identity 'General Access' -AdvancedSettings @{MembersCanShare= 'MemberShareFileAndFolder'}

To ensure that the update worked, run the Get-Label cmdlet:

Get-Label -Identity "General Access" | Select-Object -ExpandProperty Settings

[contenttype, Site, UnifiedGroup]
[tooltip, General access to information in a team, group, or site that's available to anyone in the organization plus guest members.]
[displayname, General Access]
[memberscanshare, MemberShareFileAndFolder]

Note that the Get-Label cmdlet only lists advanced settings that apply to a sensitivity label. For instance, the external sharing capability setting doesn’t appear here because it is not set for the General Access label.

Wait and Verify

The new label setting must propagate to SharePoint Online before it applies to the sites assigned the sensitivity label. The synchronization process usually takes about 24 hours, but it can take longer. After waiting for a day or so, to verify that the change worked, select a site with the sensitivity label you updated and check its site sharing permissions. Because we selected ‘MemberShareFileAndFolder’ as the value for the setting, you should see permissions as shown in Figure 2.

If the permission doesn’t show up as expected, check that the label settings are correct and wait another day before checking again. If nothing budges after a week, it’s time to seek assistance from Microsoft Support.

GUI Updates Take Time

Some will ask why Microsoft doesn’t expose advanced sensitivity label settings in the (now renamed) Microsoft Purview compliance portal. After all, many settings are managed through sensitivity labels in the GUI, including external sharing capability (Figure 3). This setting was originally only settable through PowerShell.

Although I don’t know for sure, I suspect that the answer is “development time.” In other words, after a new sensitivity label setting becomes generally available, extra development effort is necessary to update the GUI and make sure that everything works as it should. Patience is a virtue…

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Public Preview Available Now

Message center notification MC337330 (February 28) announces co-authoring for protected documents on both iOS and Android mobile devices. Microsoft 365 roadmap item 88512 explains the new feature as “Multiple authors can edit labelled and protected documents in Word, Excel, and PowerPoint simultaneously, frictionless, and with auto-save, as if they were regular documents.”

Protected documents are those assigned a sensitivity label with rights-management based encryption. Protected documents stored in SharePoint Online and OneDrive for Business are unencrypted to allow system services like Microsoft Search and Data Loss Prevention policies to access both document metadata and content. Encryption is applied when users download documents.

Co-Authoring History

Office online first supported co-authoring for protected documents in November 2019. General availability of the capability in both the Windows and Mac versions of the Microsoft 365 apps for enterprise (desktop) arrived in late 2021. Before co-authoring can happen in a tenant, the setting to enable the feature must be set in the Microsoft 365 compliance center (Figure 1).

I’m sure that the new mobile support will be most appreciated by those who use iOS and Android tablets rather than mobile phones. Anecdotal evidence suggests that many senior employees use tablets when away from the office, and those are the people likely to receive protected documents for review. However, even on an iPhone, it’s perfectly feasible to edit protected documents when other users have the documents open. In Figure 2, we see that Word has locked a paragraph because another user is active there. Locking makes it easier to avoid multiple conflicting changes in the same location.

The AutoSave (synchronization) mechanism isn’t the same as used by the Office online or desktop apps. It seems like the mobile apps synchronize with the server every minute or so rather on an ongoing basis as co-authors input and amend text. If you leave a document open in a co-authoring session and come back to it several hours later, the app downloads the latest content.

Joining the Co-Authoring Preview

Co-authoring of protected documents on mobile devices is now in public preview. It’s not a general preview as you must submit a request to Microsoft to have them enable the preview for your tenant. You’ll also need to upgrade the Office apps on your device to version 16.0.14931 or higher on Android or 2.58.207 or higher on iOS. More information is available in this Microsoft Technical Community post.

Teams Calendar Search

Another recent update that didn’t get much publicity is the inclusion of calendar meetings in search results in the Teams mobile client. Naturally, because it depends on access to the calendar in your Exchange mailbox, search for calendar items only works when you are signed into your home tenant. The feature is generally available to all tenants. You might need to update your Teams mobile client to see calendar items show up in search results.

The search results (Figure 3) look as you’d expect. Search can find any calendar item, and if the item is a Teams meeting, you’ll see the option to join the call (even long after the meeting finished).

On the grand scheme of things, neither of the two features is especially important. They’re more like fill-in functionality to round out how an application works and to make it more useful. You might never use either feature. But if you do, you’ll be glad that Microsoft added them to the mobile apps.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

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.

Feature Became Generally Available in July 2022

According to a LinkedIn post by Microsoft Principal Program Manager Sanjoyan Mustafi, administrators will soon be able to assign default sensitivity labels to document libraries in SharePoint Online and OneDrive for Business. The capability is in private preview at present, but Microsoft 365 tenants can sign up to join the preview here.

Update: According to message center notification MC391948 (June 13), rollout of the public preview of setting a default sensitivity label for a document library will roll out in late June. This is Microsoft 365 roadmap item 85621.

Update 2: On July 29, Microsoft announced that the roll-out for the public preview code had begun and that all tenants would receive the update within 90 days. The documentation is also available.

Today, you can require that users add a sensitivity label to documents and define a default label to use. This is done through settings of the sensitivity label publishing policy which makes labels available to users. Requiring documents to be labelled works, but you don’t know what labels users will choose. Sometimes, it might be necessary to ensure that every document in a library receives the same sensitivity label to reflect the level of confidentiality of the library, and that’s where the new capability comes in.

The Backend to Apply Sensitivity Labels

The preview includes the back-end code to define a default label and apply it to new Office documents uploaded or copied to or saved in a library. An asynchronous thread examines new items to check if they already have a sensitivity label. The stamping of the default sensitivity label on new items by the thread can take a few minutes.

If a new item already has a user-applied sensitivity label, the thread ignores the document based on the principle that explicit assignment by users always takes precedence over automatic assignment. If the item has a label of a lower priority (sensitivity labels have a priority order from 0 to n, with 0 being the lowest) received through automatic assignment (usually because a label publishing policy mandates the application of a default label), the thread replaces the label and applies the default label defined for the library.

For now, labeling only happens for new Office documents (support for PDFs will come later). Existing documents remain untouched, and you must apply labels manually if you want all documents to have the same label. However, in the future, Microsoft plans to update the code so that SharePoint will apply labels whenever a user opens an unlabeled document in a library with a default label.

Note that a user can remove the default label assigned for the library or replace it with a label of higher or lower sensitivity. In these cases, the user-assigned label remains, again following the principle of user precedence.

Update: Figure 1 shows the UX to configure a default sensitivity label for a document library. To access this screen, go to Library settings.

Configuring for Default Sensitivity Labels

Prior to Microsoft delivering the UX to configure a default sensitivity label for a document library, you had to update the configuration of the target document library using the SharePoint API. You can do this with Postman (the tool favored by Sanjoyan), but I prefer PowerShell, which is what I used. Sanjoyan explains the procedure in his post, but briefly is:

• Get a bearer token to authenticate with SharePoint Online. You can copy the token if you’re logged into SharePoint Online by using the developer tools (F12).
• Create a header structure to hold details of the transaction, including the bearer token.
• Create a body structure to define the GUID of the sensitivity label you want to add as the default for the library. Use Connect-IPPSSession to connect to the Compliance center endpoint and run Get-Label to find the list of labels. The GUID for each label is in the ImmutableId property.

Get-Label | Format-List DisplayName, ImmutableId

• POST to the URL for the document library using the header and body defined earlier.

The commands I used to update a document library were:

$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Accept", "application/json;odata=verbose")
$headers.Add("Content-Type", "application/json;odata=verbose")
$headers.Add("X-HTTP-Method", "MERGE")
$headers.Add("If-Match", "*")
$headers.Add("Authorization", "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IkRya21Mczl1akhnMkp1SE5CRm5vOERicXBJSSJ9.eyJhdWQiOiIwMDAwMDAwMy0wMDAwLTBmZjEtY2UwMC0wMDAwMDAwMDAwMDBAYjY2MjMxM2YtMTRmYy00M2EyLTlhN2EtZDJlMjdmNGYzNDc4IiwiaXNzIjoiMDAwMDAwMDMtMDAwMC0wZmYxLWNlMDAtMDAwMDAwMDAwMDAwIiwibmJmIjoiMTY0MzMxNTU5MiIsImV4cCI6IjE2NDMzMTkxOTIiLCJ1cG4iOiJ0b255LnJlZG1vbmRAcmVkbW9uZGFzc29jaWF0ZXMub3JnIiwicHVpZCI6IjEwMDNCRkZEODA1Qzg3QjAiLCJjYWNoZWtleSI6IjBoLmZ8bWVtYmVyc2hpcHwxMDAzYmZmZDgwNWM4N2IwQGxpdmUuY29tIiwidmVyIjoiYnJvd3NlciIsInRpZCI6ImI2NjIzMTNmLTE0ZmMtNDNhMi05YTdhLWQyZTI3ZjRmMzQ3OCIsImFwcGlkIjoiYzU4NjM3YmItZTJlMS00MzEyLThhMDAtMDRiNWZmY2QzNDAzIiwiYXBwX2Rpc3BsYXluYW1lIjoiU2hhcmVQb2ludCBPbmxpbmUgQ2xpZW50IEV4dGVuc2liaWxpdHkiLCJzY3AiOiJGaWxlcy5SZWFkV3JpdGUuQWxsIFNpdGVzLk1hbmFnZS5BbGwgU2l0ZXMuRnVsbENvbnRyb2wuQWxsIFRlcm1TdG9yZS5SZWFkV3JpdGUuQWxsIiwiaXBhZGRyIjoiNTEuMTcxLjIxMi4xMjkiLCJzZXNzaW9uaWQiOiIzYzdiMjUzYy0zNmJjLTQ1ZTctYmQ4OS1mNGRhZjdkZjZhNmEiLCJzaWduaW5fc3RhdGUiOiJbXCJrbXNpXCJdIn0.m0VNYiAPfu7GKuTcnAi0hc4ay7TAQ-KzlH1g3hRzRzJZccoLeRepey8k7ydNHsvdhO8N0E4mMEEz3dD8Tk-1qreBzNrqPkB6p2s8hGF1J04RaR6vkyTqJypFXLRXgmSsVrPsX1huNnkwZ0d_ShmPowUToZk_HN0MrDRIEleCks32pg1nQs2Umk63BkWAaUHJy_pLhYJOea0uzSc7iPeVpPaAQ8PbK8K4eRJX__DEByQueUSOd21V9O6KJ9ey-JasryPiqtncFUDGrofQ6EZztjwaCAjQubRv7RjOkMYeucgsgiI7cvfuvuCzcXjc6oqdosZwc-18Uurq_8r8ks9c4A")

$body = "{
`n `"__metadata`": {
`n `"type`": `"SP.List`"
`n },
`n `"DefaultSensitivityLabelForLibrary`": `"27451a5b-5823-4853-bcd4-2204d03ab477`"
`n}
`n"
$Uri = 'https://office365itpros.sharepoint.com/sites/Office365Adoption/_api/web/lists/GetByTitle(''Documents'')'
$Update = Invoke-RestMethod -Method 'Post' -Headers $Headers -Body $Body -Uri $Uri

Formatting of these commands must be precise, and the bearer token must be valid or the update will fail (I know, because I made many mistakes before doing it just right). The easiest way to make sure is to open the site you want to update in a private browser window to force a recent authentication and then copy the token (use F12 in Edge and access Local storage, then copy the value of the key for the identity for SharePoint Online as shown in Figure 2).

After configuring a default sensitivity label, it’s a good idea to change the default view for the library to include the sensitivity label to remind users that documents now have labels.

Steady Progress

Sensitivity Labels and SharePoint Online had a rocky start. There was a time when the content of protected Office documents was inaccessible to search and eDiscovery. That’s in the past (if you enable support) and Microsoft is busy filling out all the details that make software more useful. Adding a default sensitivity label to document libraries is a nice step forward but remember that using this capability will require Office 365 E5 or above, just like all the other auto-label application features in Microsoft 365.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Seeking Protection Against Forwarding

A question came in about the best way for internal email to be protected against external sharing. The company in question uses dynamic distribution lists for employee communications like organizational announcements. Management wants recipients to be unable to forward this email to external people. It’s a common request that goes back to the earliest days of information protection.

Outlook and OWA support encryption through the two default templates made available through Office 365 Message Encryption (OME) to users with Office 365 E3 and E5 licenses. The Encrypt-Only template protects email in transit and makes sure that only people on the addressee list can open messages. The Do No Forward template adds in a block to prevent forwarding. On the surface, it seems like the Do Not Forward template is a good choice. And is it, but only if you use regular distribution lists. OME-protected messages don’t work with dynamic distribution lists. The reason is simple and comes down to the inability to obtain use licenses from the Information Protection service.

Dynamic Membership Stops Protection Licensing

Exchange Online resolves the membership of a dynamic distribution list to know who should receive copies of messages sent to the list. For years, resolution happened when the transport service processed a message sent to a dynamic distribution list. Recently, Microsoft changed this to a timed basis, meaning that Exchange Online resolves the recipient query against the directory to find list membership daily. List membership is less dynamic than it once was, but the lack of immediacy doesn’t usually make much difference in practice.

When Exchange Online processes email sent to a dynamic distribution group, it bifurcates the message to create a copy to deliver to each recipient. If the message is protected with OME, recipients receive an encrypted copy with their email address in the message recipients. To open the copy, the recipient needs the right to access the content, which works for OME because the publishing license for the message includes the recipient. However, because Exchange Online creates message copies in the transport pipeline for list recipient, the publishing license doesn’t include their details. Email clients cannot verify that the recipient has the necessary permission, so they cannot open the message (Figure 1).

In a nutshell, OME templates work well when sent to individual recipients present in messages when sent. They just can’t deal with the way Exchange Online adds recipients to messages during transport.

Use a Sensitivity Label to Protect Confidential Email

Although dynamic distribution lists cannot be used with OME, sensitivity labels offer a solution. You cannot control the rights assigned through an OME template, but this control is possible in a sensitivity label. The key is to include the special All users and groups and your organization group in the permissions assigned in the label (Figure 2).

You can also assign permissions to individual users or groups (but not dynamic distribution lists). If you do this for a label used with dynamic distribution lists, make sure that you assign permissions to cover everyone in the list. If you don’t, some recipients will be unable to read messages. All users and groups in your organization is a convenient way to ensure that everyone in the tenant can read content protected by the sensitivity label, including documents stored in SharePoint Online and OneDrive for Business.

When you add permission assignments to the label, you define the rights the assignees receive. While you can create a custom permission set containing specific rights, Microsoft makes it easy to assign rights through predefined sets. Details of the Viewer role appear in Figure 3. Recipients with this role can read content but they cannot perform other actions like print or forward. Assigning this role to the special group in a sensitivity label ensures that everyone with an account in the tenant can read any content protected by the label.

After configuring the sensitivity label, it can be made available to users through a label publishing policy. This process will take some hours because it requires clients to refresh their label cache. Once this happens, users can apply the sensitivity label to email sent to dynamic distribution lists, and tenant accounts who are members of those lists can read the messages (Figure 4).

If someone forwards a message to someone outside the tenant, that user won’t have the necessary rights to open the message and all they’ll see is a message with an encrypted attachment. They can follow the directions in the message to the OME portal and attempt to open the message there, but without rights, nothing will happen. This is a good example of rights management in action.

Rights Management and Office 365

Anyone with an Office 365 license can read content protected with sensitivity labels. To apply sensitivity labels, you need at least an Office 365 E3 license. Remember that sensitivity labels also support container management for Groups, Teams, and Sites, so they’re more than just a way to apply encryption.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Making Sure Confidential Documents are Retained

By their very nature, sensitivity labels are intended to mark documents and files as containing important information. With this thought in mind, it makes sense to apply retention labels to files based on the sensitivity of the information they contain. Given that they know the content, you can ask users to assign appropriate retention labels to files, but humans are imperfect and often forget, which is where auto-label retention policies come in.

Auto-label retention policies run in the background to check Exchange Online messages, and files in SharePoint Online sites and OneDrive for Business sites. Auto-label retention labels also support Microsoft 365 Groups, meaning that they apply to the messages in group mailboxes and the files in the SharePoint Online team sites belonging to groups (including Teams). The basic principles of auto-label retention policies are:

• Identify the objects to label through a content query. The query could be the presence of a sensitive information type known to Microsoft 365, like a credit card number. Microsoft 365 includes over 250 different sensitive information types, and organizations can create their own types to handle business requirements. Organizations can also create trainable classifiers based on business documents and use classifiers with auto-label policies. Finally, you can use a search constructed with the Keyword Query Language (KQL), which is what we’ll use.
• Define a retention label for the policy to apply when it finds content matching its conditions. You can choose any retention label defined in the organization.

Auto-label retention policies are an advanced compliance feature, meaning that any account which comes within the scope of a policy must have an appropriate license (like Office 365 E5 or Microsoft 365 compliance).

Working Through an Example

In this example, we’ll create an auto-label retention policy to assign a retention label to documents and messages protected by the Highly Confidential sensitivity label. To do this, you:

• Connect to the compliance endpoint with PowerShell by connecting to Exchange Online and then running the Connect-IPPSSession cmdlet.
• Find the unique identifier (GUID) for the selected sensitivity label by running the Get-Label cmdlet. The ImmutableId property contains the GUID.

Get-Label | ? {$_.DisplayName -eq "Highly Confidential"} | Select-Object -ExpandProperty ImmutableId

Guid
----
9ec4cb17-1374-4016-a356-25a7de5e411d

• Use SharePoint search to test the KQL query for the auto-label policy. The search term is in the form InformationProtectionLabelId:9ec4cb17-1374-4016-a356-25a7de5e411d wherethe managed SharePoint property used to hold sensitivity labels (InformationProtectionLabelId) is combined with the GUID identifying the sensitivity label you want to search for. Run the search and open one of the documents returned by the search to check that it has the correct sensitivity label. If no documents are found, it might indicate that the GUID is incorrect or that your account has access to no documents assigned this sensitivity label.
• If the search term finds the correct documents, go to the Information governance section of the Microsoft 365 compliance center to create an auto-label retention policy. The condition of the policy uses the same search term as the content query to find the target documents. The policy action applies a suitable retention label to keep the documents for the desired period. Figure 1 shows the KQL query inserted in the settings of an auto-label retention policy.

• Configure the policy with target locations. Remember to use Microsoft 365 Groups to cover SharePoint sites owned by groups and teams. Publish the policy when everything is complete.
• After ten days or so, check that documents with the sensitivity label have the correct retention label, remembering that if a user assigns a retention label to a document, an auto-label policy won’t replace it.

The ten days mentioned above is an estimate rather than a guarantee. It can take SharePoint Online anything from seven days to two weeks for a new auto-label retention policy to become operational and start to apply retention labels.

Retention and Sensitivity

If you have the necessary licenses, auto-label retention policies are a great way to make sure that important information is kept for as long as required or that other information is removed once no longer required. Another example is to apply retention labels to Teams meeting recordings (a more flexible option than the default Teams-only retention for meeting recordings).

Microsoft’s original labeling plan features labels that had both retention and sensitivity capabilities. That plan fell by the wayside, perhaps because such labels might have been very complex to implement and manage. We now must implement retention labels and sensitivity labels separately. Auto-label retention policies are one way to bring the two together in some small way.

The Office 365 for IT Pros eBook includes chapters with in-depth coverage of both retention labels and sensitivity labels. If you’re planning a deployment which includes these components, you can benefit from our insight.

Unexpected Announcement at a Curious Time

In an unexpected twist just as people were leaving for the holiday period, Microsoft announced on December 21 that, effective January 1, 2022, the Microsoft Information Protection unified labeling client is in maintenance mode. In their post, Microsoft is clear that this status means only that they will not invest in new functionality for the client as they prefer to dedicate engineering resources to building out Microsoft Information Protection (MIP) capabilities in other ways. Although Microsoft won’t enhance the software, they will maintain it to allow customers to continue using the unified labeling client and fix bugs.

Unified Labeling Client Functionality

The unified labeling client includes four major pieces of functionality.

• Adds the Sensitivity button to the menu bar of Office desktop applications (perpetual versions) to allow users apply sensitivity labels to Office files. The Office applications in Microsoft 365 apps for enterprise include these UI elements. The code to encrypt and decrypt files is in the unified labeling client.
• Integrates with Windows File Explorer to allow users apply sensitivity labels to files stored outside Microsoft 365 through a Classify and Protect option in the right-click menu.
• Installs a viewer to allow the display of protected content when an application can’t handle these files.
• Installs a PowerShell module to allow administrators to manage protected files.

The unified labeling client replaced the original Azure Information Protection client, which Microsoft deprecated on March 31, 2021. The software only runs on Windows. Its heritage goes back to the original Azure Information Protection project when add-on software was the only way to enable information protection functionality. Things are very different now because the Office apps (mobile, click-to-run desktop, and browser) used with Microsoft 365 include native support for sensitivity labels and don’t need any add-on software. By native, I mean that the apps include the necessary MIP code to fetch and display sensitivity labels and encrypt and decrypt files as necessary.

Customer Needs for Information Protection

However, some customers use older versions of the Office desktop apps which don’t support MIP, want to apply sensitivity labels to files stored outside SharePoint Online, OneDrive for Business, and Exchange Online, or need to apply labels to non-Office formats which support sensitivity labels (PDF is a good example). These are the classic use cases when customers decide to deploy the unified labeling client and pay for the necessary Azure Information Protection licenses. See this page for the latest information about the client.

Although Microsoft emphasizes that the unified labeling client remains available and supported, customers will want to see continued progress to build out the MIP ecosystem in both Microsoft and third-party apps. There’s no point in making an investment in MIP if its domain is limited to Microsoft 365 and the Office apps. The role of the MIP SDK is critical in terms of convincing ISVs to support protection of non-Microsoft application data. Adobe’s implementation of MIP to protect PDF files is an example of what’s needed.

In other news conveyed in the same post, Microsoft says that they will sunset the AIP mobile viewer apps for iOS and Android on December 31, 2022. In addition, as announced in early 2020, Microsoft will remove the ability to manage AIP labels in the Azure portal on March 31, 2022. This is not unexpected as full (and better) support for sensitivity label management is available in the Microsoft 365 compliance center.

Better Communication Would Help

Most organizations don’t like surprises which affect their IT strategy. Posting an announcement in the Microsoft Technical Community just before Christmas to inform customers that software is going into maintenance mode nine days later is not an example of good communications. The text creates more questions than it answers. For instance, how long will the unified labeling client remain in maintenance before Microsoft decides to depreciate it? Are more ISVs including native MIP support in their applications? Will customers have to continue to pay for licenses at the same rate to use software that’s no longer under active development?

No doubt Microsoft will answer these and other questions as time goes by. It just would have been better to give customers more notice and more information when this announcement appeared. At least Microsoft made the announcement in time for us to include the information in the January 2022 update for Office 365 for IT Pros!

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Office Apps Check for Sensitivity Label When Opening Both New and Old Documents

Message center notification MC305436 (December 15, Microsoft 365 roadmap item 88515) informing tenants that sensitivity labels now apply to modified documents might have puzzled a few. It certainly caused me to think a little before understanding what’s going on, especially after reading Microsoft’s summary: “Coming to public preview, default labeling policies can now be applied to any supported document that a user edits, not just a new document.”

To understand the full context of what’s happening, we need to go back to the past. When Azure Information Protection came along in 2016, users needed to install a separate client, now called the unified labeling client, on Windows workstations to use labels. The client is still in use today, but only to apply labels to files stored outside Microsoft 365.

Microsoft originally developed a separate client because Office applications (online, mobile, and desktop) at the time didn’t understand how to deal with sensitivity labels. The apps couldn’t encrypt or decrypt documents and included no user interface elements to allow users to select labels to apply.

Enlightened Office Apps

Things are different today because the Office apps are “enlightened” (obviously, they were in the dark previously). In other words, they now support Azure Rights Management data protection by including Microsoft Information Protection code to handle sensitivity labels, connect to the service to fetch use licenses, display label information, and apply visual settings (watermarks, headers, and footers). Microsoft documents the current sensitivity label capabilities of Word, Excel, and PowerPoint in this page.

And if you enable support for sensitivity labels in SharePoint Online and OneDrive for Business, the content of protected files becomes available for processing by Microsoft Search, Data Loss Prevention (DLP), and other services. All in all, Microsoft has done a ton of work to build out the infrastructure surrounding sensitivity labels over the last few years. Anyone with an Office 365 or Microsoft 365 license can consume (access) content protected with sensitivity labels, but you need Office 365 E3 or above to apply sensitivity labels to content.

However, some customers invested in the unified labeling client (still only available for Windows) and paid for the necessary Azure Information Protection licenses. To help customers move away from the unified labeling client, Microsoft is steadily increasing the protection features available in Office, and the change reported in MC305436 is part of that effort.

Mandatory Labeling Via Policy

When you edit the settings for a sensitivity label publishing policy, you can choose to require users to apply a sensitivity label to new email and documents (Figure 1). Later in the policy settings, you select the default label to apply.

Because this is an automatic operation, Microsoft requires users to have Office 365 E5 licenses or above (see this guidance on Microsoft Information Protection licensing).

The change due to roll out in mid-January will allow Office to apply sensitivity labels to an unlabeled document when a user opens the file. Until now, Office only applied default labels to new documents, which meant that you could have a bunch of unlabeled but sensitive documents in a SharePoint Online document library that will never receive sensitivity labels unless a user explicitly opens and labels the documents. Now, each time Office opens a document, it checks for a label in the document metadata, and if none is present, Office applies the default label specified in the sensitivity label publishing policy. If a user comes within the scope of multiple publishing policies. Office applies the default label from the highest priority policy.

For more information about the deployment and management of sensitivity labels, see the Information Protection chapter in the Office 365 for IT Pros eBook. Or browse the Office 365 for IT Pros presentation on sensitivity labels at the recent European Collaboration Summit.

First In-Person Event Since 2019

The last in-person event I spoke at was the European SharePoint Conference in Prague in December 2019. Much has happened since, but as society gradually recovers from the effects of the Covid-19 pandemic, conferences are beginning to cast off the constraints imposed by having to run as virtual gatherings. Don’t get me wrong. Virtual conferences filled a gap while travel was impossible or restricted, but the energy, vitality, and enthusiasm present when gathering to listen to a series of sessions delivered by Microsoft Teams or Zoom is very different to an in-person event.

All of which means that I am looking forward to being in Dusseldorf, Germany for the European Collaboration Summit (ECS) starting on November 29. ECS runs alongside its sister event, the European Cloud Summit. Both events are being run under strict Covid-19 protocols to protect all those involved.

ECS is a community event which isn’t run purely on a commercial basis (costs must be covered, so the event is sponsored). The result is that the ECS vibe is quite different. Because it’s a community event, ECS sessions deliver more independent and diverse thought about how technology works and how to extract value from deployments. Compared to the blandness of a Microsoft event like Ignite, the level of marketing hyperbole, overpromising, and under delivery is far less.

Although I enjoy seeing the range of expertise available in most ECS sessions, I consider it regrettable that all the ECS keynote sessions feature Microsoft employees. This is no criticism of the Microsoft speakers, most of whom I know well. Instead, it’s a desire for conferences to surface diverse leadership opinions instead of automatically assuming that the only source of inspiration and knowledge comes from those with a Microsoft badge. There’s surely some independent thinking available in the Microsoft collaboration community suitable for a keynote to replace and counterbalance the sameness of the messages delivered by Microsoft at conferences around the globe. Remember, if we all believed the marketing bluster received from Microsoft in the past, everyone would be communicating by Yammer instead of using email and Teams.

My Schedule

ECS begins with a day of workshops on Monday with sessions delivered over the following two days. I’ll cover All About Microsoft 365 Sensitivity Labels at 14:45 on Tuesday, 30 November in Room 1 (Aurum room) while fellow Office 365 for IT Pros author and MVP Paul Robichaux will present on Email is the Easy Part: 5 Pitfalls to Avoid in Tenant-to-Tenant Migrations at 15:00 on Wednesday, 1 December at the Teams Stage.

I’ve covered the development of sensitivity labels and their spreading influence within Microsoft 365 since the debut of the technology. Recent articles include:

• How Sensitivity Labels can control the external sharing capability for SharePoint Online Sites.
• How to Decrypt SharePoint Online Documents using PowerShell and the Graph API
• How to use Sensitivity Labels to protect Teams meeting recordings.
• Synchronizing Sensitivity Labels from Microsoft 365 Groups to Update SharePoint Online Sites.
• How to Report the Audit Events Generated by Sensitivity Labels.
• Power BI Support for Sensitivity Labels.
• Using Advanced Settings for Sensitivity Labels with Outlook.
• How to Monitor Changes in the Sensitivity Labels Applied to Sites, Teams, and Groups.

Hopefully, I will have some new information to share with attendees. That’s the plan, but like most plans, it will go out the window once the first slide hits the screen. We’ll see how things evolve based on audience participation, questions, and whatever comes into my head at the time.

Here’s a downloadable copy of my presentation (not protected by a sensitivity label)

Regretfully, I won’t be at ECS on Wednesday. Other commitments bring me back to Dublin on Wednesday morning. However, there’s a bunch of good sessions scheduled for day 2 of ECS, so I suspect I’ll be one of the few leaving early.

Learn about protecting Office 365 content by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant. We have a full chapter explaining all you need to know about Information protection.

Learning from the MIP Pros

If you’re interested in Microsoft Information Protection (MIP), you should consider joining the Yammer group where the MIP team share information about how their products work. Which is where I came across a thread covering a situation where someone (for whatever reason) deletes an RMS protection template. This isn’t good because RMS (Rights Management Services) templates underpin components like the sensitivity labels used by people to protect Office documents and PDFs. Essentially, the fear expressed was that if someone removes a template, people would be locked out of documents and email protected by the sensitivity label based on that template. It’s a reasonable concern.

The Publishing License Backstop

As explained in the thread, the publishing license helps to rescue users from the problem of a deleted template. The publishing license (PL) holds details inherited from the template when a document owner applies a sensitivity label to an item. The PL holds the access control list specified in the template (think of a list of email addresses (including the special addresses like anyone in the tenant or any authenticated user) and the rights assigned to each person). For example:

The PL is encrypted so that only the rights management service can access its contents and is signed by the client, meaning that every client can see who applied the template.

When someone attempts to open an item protected by a sensitivity label, they obtain a use license (UL) from the rights management service. Clients that support offline access, like Outlook, can preload use licenses. The UL is an XrML certificate stating the user’s rights to access an item. The UL also holds the encryption key needed to access the item content and has an expiry date (usually 30 days from the time of grant). When the UL expires, it is renewed through user authentication. At this point, any changes to the preassigned rights in the sensitivity label become active. Ad-hoc or user-defined permissions stay in place unless updated on an item.

The combination of UL and a rights account certificate (RAC) allows access to a protected file. The RAC is obtained when someone first uses rights management on a workstation and renewed automatically every 31 days.

Let’s assume that someone goes ahead and deletes the Confidential template, which is used by the Confidential sensitivity labels (these days, most templates are created when sensitivity labels are created, so they have the same name). Many documents assigned the Confidential label are stored in SharePoint Online and OneDrive for Business. When a user with the right to access one of these documents attempts to open the file. At this point, the app (SharePoint Online) requests UL from the rights management service and includes the PL from the file. Because the RMS service cannot find the template, it falls back on the PL and issues a use license based on whatever access rights are noted there. Usually this means that users who expect to have access can continue to access the file, and all is well. However, if administrators have made changes to the access list over time, it could be that the PL from a document does not match the latest access list in the template before its removal. In this case, the users not in the access list cannot open the file.

Don’t Remove Templates

The thread concludes with a strong recommendation not to remove templates. Although the PL backstop exists and works (within reason), it’s not something that you want to depend upon. If you want to stop using a sensitivity label and its template, remove the label from all publishing policies so that users can no longer apply the label to new content. For more information about how MIP uses licenses, read this post (old but still informative).

Protect Most Confidential SharePoint Online Sites

Adding to their container management capabilities, a feature for sensitivity labels demonstrate how to use authentication contexts with Entra ID conditional access policies to ensure secure access to information in SharePoint Online sites.

An authentication context is a way to tag information which needs special attention. First introduced in March 2021, authentication contexts are additional information required by a service provider before it grants access to a resource. Microsoft positions authentication contexts as a method to “target policies for data and actions within an app.” Put another way, authentication contexts allow organizations to apply more granular control to targeted data.

As implemented for sensitivity labels, authentication contexts link conditional access policies to let applications like SharePoint Online know that users must provide some extra information before they can access information in labelled sites. Let’s work through an example.

Define an Authentication Context

The first thing to do is to define an authentication context. In the Security section of the Entra ID admin center, open the Protection section, select Conditional Access and choose Authentication context. I created a context called Require MFA (Figure 1). The name is what you’ll see in apps like sensitivity labels. The ID for the context shown towards the bottom of the screen (c1 in this case) is an internal value written into the settings of sensitivity labels which use authentication contexts.

The Publish to apps checkbox is set, meaning that this authentication context is visible to apps like sensitivity labels and can be used by conditional access policies.

Create a Conditional Access Policy

The next step is to create a conditional access policy to use the authentication context to force multi-factor authentication. Conditional access policies can range from very simple to very complex. To prove that everything works as expected, I created a simple policy which blocks access to resources tagged with the authentication context unless the user authenticates with MFA. The new thing here is that you select the authentication context instead of apps (Figure 2). The requirement to use MFA is selected in the Grant section (not shown here).

Another easy thing to include in a conditional access policy to protect sensitive data is to include a terms of use (TOU) check to force users to read and acknowledge conditions governing access before they gain access to a site.

Updating the Sensitivity Label

To protect SharePoint Online sites with the conditional access policy, we configure a sensitivity label with the authentication context. Figure 3 shows the UI for sensitivity labels where we’ve selected the authentication context.

Any attempt to access a site with the label causes SharePoint Online to look at the label settings to see if an authentication context is specified. If one is found, SharePoint Online queries Entra ID to find which conditional access policy is associated with the authentication context and invokes the policy. In our example, attempts to access the site succeed if the user authenticates with MFA and fail otherwise.

Using PowerShell to Assign Authentication Contexts to Sites

The value of Sensitivity labels is that they make it easy to assign a set of different controls to containers, including conditional access policy protection to SharePoint Online sites. However, if your tenant doesn’t use sensitivity labels (yet), you can update sites with PowerShell. After you assign a label with an authentication context to a site, SharePoint Online updates two site settings:

• ConditionAccessPolicy: Holds the name of the conditional access policy protecting the site. When using an authentication context, this value is “AuthenticationContext.”
• AuthenticationContextName: Holds the name of the selected authentication context. As per Figure 1, it is “Require MFA.”

Check the values by running the Get-SPOSite cmdlet:

Get-SPOSite -Identity https://office365itpros.sharepoint.com/sites/SuperConfidential | ft con*, aut*

ConditionalAccessPolicy AuthenticationContextName
----------------------- -------------------------
  AuthenticationContext Require MFA

Now we know the properties to update, we can update other sites using the Set-SPOSite cmdlet:

Set-SPOSite -Identity https://office365itpros.sharepoint.com/sites/ProjectAjax -AuthenticationContextName "Require MFA" -ConditionalAccessPolicy "AuthenticationContext"

Testing the Block

To test that everything worked as expected, I used Teams. Many SharePoint sites created today are linked to Teams, so it seemed like a good test scenario. As expected, when I tried to access a site assigned the sensitivity label without using MFA, the Teams Files channel tab failed to connect and displayed an error (Figure 4).

Microsoft says that they are upgrading the Teams Files channel tab to prompt for MFA authentication when necessary. This will make access smoother and avoid users seeing the instant fail in the current experience.

When I tried to open the site using the SharePoint Online browser interface, it opened successfully. This puzzled me for a moment until I realized it was because the account had gone through a self-service password reset (SSPR) challenge and that the credentials gathered through that process satisfied the MFA requirement. This is because Microsoft now uses combined security information for MFA and SSPR (if your organization doesn’t use combined registration, you can enable it using these instructions). When I encountered the SSPR “your organization needs more information” challenge, it didn’t immediately make me think that MFA was involved, but it was!

To confirm that Entra ID enforces the conditional access policy for the site, you can check the Entra ID sign-in logs. Figure 5 shows that Entra ID invoked the policy because a user covered by the policy signed into SharePoint Online. The sign-in record doesn’t capture details of the site, but if only one sensitivity label uses the conditional access policy and you know who signed in, you can put two and two together to know what happened.

Increasing Control

Linking sensitivity labels with conditional access policies increases the granularity of control a label can exercise over SharePoint Online sites and increases the usefulness of sensitivity labels for container management. Multiple conditional access policies can use a context, which opens a bunch of different possibilities about how to control access in different circumstances.

Given the amount of confidential information stored in SharePoint Online, it’s nice to be able control conditional access so easily and a good example of how Microsoft is steadily building up the container management capabilities for sensitivity labels. Make sure that you have the necessary licenses before you use the feature!

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Build Organization-Wide Consistency in Sharing Behavior

Updated: February 24, 2022

Sensitivity label container management settings can control the sharing capability of SharePoint Online sites. Separately, the advanced settings of sensitivity labels can control the default sharing link settings for sites and documents. Enforcing consistent sharing capabilities is a good example of how container management through sensitivity labels make it easier to apply organizational standards across sites in a Microsoft 365 tenant.

Controlling Site Sharing

If you create a sensitivity label and configure it to apply a sharing capability of “Only people in your organization,” any site which receives the label automatically enforces that sharing capability. Site owners cannot change the sharing capability of a site without changing the label assigned to the site. Although tenant administrators can’t stop site owners changing a label, this is an auditable action which organizations can track to revert if necessary.

Controlling Default Sharing Link Settings

SharePoint Online creates sharing links when users share content from a site (Figure 1). The sharing link identifies what the person receiving the link can do with the content (read or edit). It also identifies who can use the link (anyone, specific people, tenant accounts).

SharePoint administrators can configure settings for the default sharing link for a site through PowerShell by running the Set-SPOSite cmdlet from the SharePoint Online management module. The relevant parameters are:

• DefaultSharingLinkType: Defines the default sharing link type for the site. For example, if this is “Internal,” the default sharing link type is set to anyone in the organization. The default is None, meaning respect the organization setting (defined with Set-SPOTenant).
• DefaultLinkPermission: Set to View or Edit to define what the link recipient can do. The default is None, meaning respect the organization setting.
• DefaultLinkToExistingAccess: The default is False. If set to True, the default sharing link type is set to People with existing access.

Defining a default sharing link type does not mean that site users are limited to the settings used to create sharing link. Users can update their sharing links to use other settings (for example, change the permission from edit to view), providing they remain within the constraints defined for the site’s external sharing capability.

Updating Sensitivity Labels with Default Sharing Link Settings

Now generally available (February 2022), you can configure the advanced settings of sensitivity labels to control the default sharing links generated for sites. The advantage of this method over configuring settings using Set-SPOSite is that any site assigned a label inherits the settings automatically. You don’t have to configure each site individually.

For now, configuration is by updating the advanced settings for a label with PowerShell. Given past practice, it’s possible that we will see a GUI for advanced label settings sometime in the future.

To update label settings, you connect to the compliance endpoint with PowerShell. Do this by running the Connect-IPPSession cmdlet from the Exchange Online management module. You can then use the Set-Label cmdlet to update the sensitivity labels. The setting names for Set-Label do not correspond exactly with the values used by Set-SPOSite. Here are the values:

• DefaultSharingScope (DefaultSharingLinkType) can be SpecificPeople, Organization, or Anyone.
• DefaultShareLinkPermission (DefaultLinkPermission) can be Edit or View.
• DefaultLinkToExistingAccess is True or False (default False).

You can update link settings separately or together. For example, these commands set the default sharing scope and permission in two steps:

Set-Label -Identity 'Guest Access' -AdvancedSettings @{DefaultSharingScope = "SpecificPeople"}
Set-Label -Identity 'Guest Access' -AdvancedSettings @{DefaultShareLinkPermission = "Edit"}

Or set the two values in one command:

Set-Label -Identity 'Non-Business Use' -AdvancedSettings @{DefaultShareLinkPermission = "Edit"; DefaultSharingScope = "Anyone"}

To check the settings for the label and confirm the configuration, run the Get-Label cmdlet:

Get-Label "Non-Business Use" | Select -ExpandProperty Settings
[contenttype, Site, UnifiedGroup]
[tooltip, Apply this label to a team, group, or site intended to support a non-business use such as a sports club or approved employee society.]
[displayname, Non-business use]
[defaultsharingscope, Anyone]
[defaultsharelinkpermission, Edit]

To set the default sharing link for the site so that it overrides any existing setting and uses people with existing access instead, run:

Set-Label -Identity 'Confidential Access' -AdvancedSettings @{DefaultLinkToExistingAccess  = "True"}

Like any other changes made to sensitivity labels, it can take up to 24 hours before SharePoint Online respects updates to the default sharing link settings.

Update Default Sharing Link Settings for Documents

Being able to control the default sharing link settings for sites by applying sensitivity labels is good. Being able to control default sharing link settings at a document level is even better. Microsoft added this capability between the preview and general availability. The same mechanism is used.

• Update a sensitivity label with default sharing link settings.
• Apply the sensitivity label to documents.
• If users share the labeled documents, SharePoint Online or OneDrive for Business use the settings from the label to generate the sharing link unless the site settings are more restrictive, in which case they take precedence.

The idea here is that you might have some specific documents in a site that you want people to pay attention to if they share the documents. The hope is that users will notice the differences in the sharing link generated by SharePoint Online or OneDrive for Business and recognize that they should be extra careful. The good thing is that people often accept default sharing link settings without question. The bad thing is that people mightn’t notice that a document is more confidential than the rest…

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new development as they happen.

Many Recent Changes

Information Protection and Governance is an area Microsoft has invested in heavily for the past few years. Many new features constantly appear, such as native support for sensitivity labels in the Microsoft 365 apps for enterprise, trainable classifiers, auto-labelling policies for sensitivity labels, and so on. Amongst all the change, one constant is that tenant administrators are often unsure about the licensing requirements demanded to protection data. Let’s try and figure out what the situation is.

The Split Between Manual and Automatic Processing

The first thing about information protection and governance features is that Microsoft makes a clear distinction between manual and automatic processing. When a user takes an action to do something, it’s manual processing and the required license is usually included in Office 365 E3. For information protection features, Microsoft enforced the differentiation in 2019 with the introduction of two Microsoft Information Protection service plans for Office 365. The standard plan is in Office 365 E3; the premium is in Office 365 E5.

The standard set of information protection and governance functionality in Office 365 E3 includes:

• Manual application of sensitivity labels to Office documents via Microsoft 365 apps for enterprise, Office Online (including OWA), and Office mobile.
• Manual application of sensitivity labels for container management to Teams, Groups, and Sites. Bizarrely, the person who applies the label (an administrator or group owner) must have an Azure AD Premium P1 license. The unfathomable logic is that the automatic inheritance of settings from the label to the underlying Azure AD group is advanced functionality.
• Manual Application of retention labels to documents and email.
• Basic Office 365 Message Encryption (OME). This includes the default Encrypt-Only and Do Not Forward templates to protect email.
• Data Loss Processing for Exchange Online and SharePoint Online (Teams is an outlier as its DLP policies require Office 365 E5).

Automatic processing usually means that some form of auto-apply policy is involved. For example, you can deploy auto-label policies to apply sensitivity labels or retention labels to documents and email. Office 365 E5 covers these policies along with Advanced OME and customer key for Office 365. Sometimes Microsoft’s definition of automatic is a little strained. For instance, if you define a default retention label for a SharePoint Online document library so that new documents created in the library receive the defined label, it’s automatic and therefore needs an E5 license.

However, for more advanced functionality like Bring Your Own Key (BYOK), Hold Your Own Key (HYOK), or double-key encryption (DKE), you’ll need a premium license like Microsoft 365 E5, Microsoft 365 E5 Compliance, and Microsoft 365 E5 Information Protection and Governance. These licenses also cover scenarios like using S/MIME with sensitivity labels, data classification in SharePoint Online, and using sensitivity labels with Power BI.

Tools to Help Understand Licensing

Given the number of features and plans available in this space, the issue of licensing can be quite complex. Microsoft publishes guidance to help tenant administrators and licensing coordinators understand when premium licenses are required to cover security and compliance features. A useful Microsoft 365 compliance comparison spreadsheet (Figure 1) is also available to show which license covers each feature. The spreadsheet also identifies gaps in terms of desirable features not covered by licenses held by a tenant.

Non-Enforcement is No Excuse

In some cases, a feature might not enforce the stated licensing requirement. This could be because the necessary code is not yet available. The code might or not appear soon. In any case, a tenant must have licenses to use functionality. It’s a bad place to be in if features the business depends on suddenly stop working because Microsoft updates its license enforcement code.

Possible to Protect Sensitive Meeting Recordings with Some Downsides

Although it’s listed as one of the applications which support sensitivity labels, the only way that Stream uses sensitivity labels is when it creates a new Microsoft 365 group. At that point, you can assign a sensitivity label with container management settings to the new group. Container management is good, but it doesn’t protect the data owned by the group.

This situation creates the question of how best to protect confidential videos. Because sensitivity labels control access to files using fine-grained rights management, they are an attractive choice. Stream “classic” doesn’t support the option to protect files in this manner, but the transition of Stream storage to SharePoint Online and OneDrive for Business creates a potential solution. As we’ll discuss, the basic technology works, but some implementation issues generate more friction than you’d like, possibly because Microsoft hasn’t figured out how the components should work together.

Unified Labeling Client and OneDrive

Microsoft touts the ability of SharePoint and OneDrive to store just about any type of file up to 250 GB, which makes it easy to store recordings of even the longest meeting. However, no user interface exists in the browser interface for SharePoint or OneDrive to assign sensitivity labels to files. Office (online, desktop, and mobile) applications can apply sensitivity labels, including encryption if needed. Exchange Online mail flow rules can also assign sensitivity labels to messages. Outside these implementations, writing some PowerShell or Microsoft Graph code or using Microsoft’s unified labeling client are the only ways to assign sensitivity labels to files.

The unified labeling client runs only on Windows workstations. It integrates with File Explorer to add a Classify and protect option to make it simple to add protection to any file which File Explorer can access. Applying protection to PDF files is a popular use case for the unified labeling client.

The OneDrive sync client can synchronize online folders and files to local copies, so it doesn’t take much lateral thinking to put two and two together and conclude it should be possible to assign sensitivity labels to meeting recordings stored in OneDrive. And as it turns out, it’s true. The only downside is that the unified labeling client requires Azure Information Protection P1 licenses. These licenses are part of the Enterprise Mobility and Security suite, but not bundled in any Office 365 plans.

Protecting Meeting Recordings

Figure 1 shows a set of MP4 video files (and a Word document) in the Recordings folder of my OneDrive for Business account. This is the location where Teams stores its meeting recordings. A label already protects one of the recordings (bottom right), as shown by the Azure Information Protection padlock icon. To protect another file, select it, and choose File Explorer’s Classify and protect option.

The unified labeling client launches to allow the user to select the sensitivity label they wish to apply. Some sensitivity labels apply markings to files without encryption, but as the MP4 format doesn’t support headers, footers, and watermarks like those used in Office documents, the only labels offered for selection in Figure 2 are those which encrypt content.

After selecting the label to apply, click Save to allow the client to encrypt the file. On my i7 Surface Book 2, the client took twelve seconds to process the 358 MB recording (for a meeting lasting 46 minutes). The size of the file is in line with the expected storage consumption for Teams recordings.

Downsides

We now have a protected MP4 file. The downsides are:

• The link posted in Teams for the recording as part of the meeting resources breaks. The recording is still listed as a resource, but the link points to the original MP4 file which no longer exists because it is replaced by the encrypted file (which has a .pfile extension). Protecting the recording also removes the sharing links for the file, so even if you reverse course and remove the label, Teams can’t access the file.
• Because the encryption process creates a new file without sharing links, the owner of the file must share the file with those permitted to view the recording.
• The OneDrive MP4 file viewer can’t open the protected file.
• The only way to view the protected video recording is through the Azure Information Protection viewer (part of the unified labeling client), meaning that those who want to view the recording must install the unified labeling client. Their account also needs an Azure Information Protection license.

In a nutshell, the unified labeling client treats Teams meeting recordings like any other MP4 file it protects. Encryption breaks any special connection between Teams to OneDrive for Business. The result is a protected recording, but the file owner needs to allow access to those to view the recording.

Maybe Not Completely Ready

Just because you can do something doesn’t mean that you should do something. Although you can protect Teams meeting recordings with sensitivity labels, the downsides indicate that the Microsoft engineering teams involved (Teams, SharePoint, Stream, and Microsoft Information Protection) have not yet worked through the issues to come up with a more seamless implementation. To be fair, Stream is in the middle of its switchover from Azure to SharePoint storage, and Microsoft might work through this point as that process unfolds. Service encryption with customer key is one of the work items listed for the migration to the New Stream, but support for sensitivity labels isn’t mentioned.

Until a more seamless integration is available, it’s reasonable to conclude that using sensitivity labels to protect Teams meeting recordings stored in OneDrive is possible with downsides.

Information protection is an important topic covered by the Office 365 for IT Pros eBook. That’s why we think about and test this kind of stuff. Benefit from our work by subscribing to the book. Its monthly updates keep everyone informed about what’s happening inside Office 365.

Understand How People Use Sensitivity Labels to Protect Office Documents

If you enable support for sensitivity labels in SharePoint Online and OneDrive for Business (and you should), most of the previous frustrations that organizations have experienced in dealing with protected go away. Protected (encrypted) content can be indexed and found by eDiscovery, co-authoring is supported (with Office Online), and so on. And very importantly, Office 365 captures audit events when people apply, remove, or change sensitivity labels with Office documents.

Originally, only sensitivity label actions performed by the Office Online apps were captured. This is fine, but most user interactions with Office documents occur through the desktop apps. The gap in coverage is closing and the latest versions of the Microsoft 365 apps for enterprise (aka Office click to run) now create audit records when they apply or remove labels from documents. I’m using version 2012 – current channel preview (build 13350.20316) as the basis for this article, but I can see that audit records have been generated since mid-December.

Although the latter part of December is a period of low work activity, the number of events captured since compared against previous months confirms the view that desktop apps are used more heavily to generate documents, spreadsheets, and presentations. At least, in my tenant.

Separate Audit Events

Nice as it is to have the additional insight into the use of sensitivity labels, it’s regrettable that Microsoft did not use the same operation names when generating audit records for the desktop apps as they do for the online apps. The operation is the name of an auditable action.

It’s possible that the logic here is that the actions originate in two different sources and the different operations mean that administrators can conduct precise audit searches to find records for either the desktop or online apps – or both.

The new operations are:

• SensitivityLabelApplied: A sensitivity label is applied to an Office document. This operation is also used when capturing a record for the application of a label to a SharePoint site. The two can be distinguished by the record type, which will be either SensitivityLabeledFileAction (for Office) or SharePoint. Events are recorded when users apply sensitivity labels to Outlook messages, but not for messages protected by OME. OWA and Outlook mobile clients don’t currently generate audit events when users label messages.
• SensitivityLabeledFileOpened: An Office document with a sensitivity label is opened by a desktop app.
• SensitivityLabelRemoved: A sensitivity label is removed from an Office document.
• SensitivityLabeledFileRenamed: An Office document with a sensitivity label is renamed to become a new file. This event is also logged when a labelled file stored on a local device (not a copy synchronized by OneDrive) is edited.

As in many cases with Office 365 audit log records, the new events need to be parsed out before they’re useful. This is reasonably easy to do with PowerShell, albeit at the need to examine and interpret the payload content of each type of event.

Reporting Audit Events

Seeing is believing and it’s always easier to understand how things work when you have a practical example. I’ve written a script to grab all the events for sensitivity labels for the last three months and create a report. Each of the event types is unpacked and interpreted to make it clear what the event means. The output is a CSV file which can be analyzed in whatever way you wish. Or you can examine the output on-screen through the Out-GridView cmdlet (Figure 1).

The script is available in GitHub. You’ll need to connect to the Exchange Online management module and the security and compliance endpoint to run the cmdlets in the script. The compliance endpoint is used to fetch the list of sensitivity labels defined in the organization and create a hash table of GUIDs/identifiers (the keys) and label names (values). Some audit events contain label names but it’s more typical to only find a label identifier recorded, so lookups against the hash table translate identifiers into label names.

As you can see from the output, in my tenant most audit records are recorded when an Office desktop app opens a protected file:

Job complete. 370 Sensitivity Label audit records found for the last 90 days

Labels applied to SharePoint sites:  51
Labels applied to new documents:     45
Labels updated on documents:         5
Labeled files renamed:               29
Labeled files opened (desktop):      200
Labels removed from documents:       40
Mismatches detected:                 0
----------------------

Report file written to C:\temp\SensitivityLabelsAuditRecords.csv

In this case, no mismatches are noted between the label applied to a site (container management) and those assigned to documents stored in the site. My users might just be learning how to label documents properly!

We write tons of PowerShell scripts to check out how Office 365 really works and understand where any fault lines might be. Our GitHub repository is available to all. Even better, we explain how to use our scripts and other PowerShell commands to manage Office 365 in the Office 365 for IT Pros eBook.

New Label UI Rolling Out

Update: This capability is now Generally Available. See this post for more information.

Previewed earlier this year, Microsoft has extended the container management settings for sensitivity labels to include control over the external sharing setting for SharePoint Online team sites connected to Microsoft 365 Groups. As per Microsoft 365 roadmap item 68700, the updated user interface to allow tenants to choose the external sharing setting is now rolling out to the Microsoft 365 compliance center.

By default, sensitivity labels do not control external sharing, so if you intend using labels for this purpose, you need to edit the labels used for container management to choose the appropriate setting. To limit the choice available to users and to make label management simpler, my advice is to maintain separate sets of labels: one set for information protection and marking and the other for container management.

Options for External Sharing

SharePoint Online supports organization-level and site-level settings for external sharing. Site-level settings are often used to set a more restrictive level of sharing for sites containing important or confidential information.

The control available in sensitivity labels is over the site-level setting for external sharing. When you assign a sensitivity label to a site (Figure 1), SharePoint Online applies the container management settings to the site, including the external sharing setting.

As shown in Figure 2, the control in a sensitivity label offers the same four external sharing options as can be applied through the SharePoint admin center (see below) or PowerShell (the relevant value used with the Set-SPOSite cmdlet is in parenthesis):

• Anyone (ExternalUserAndGuestSharing): Sharing is allowed with all external users, and documents can be shared using anonymous access links (Anyone links).
• New and existing guests (ExternalUserSharingOnly): Sharing is allowed with new external users, who must accept a sharing invitation and go through an authentication process to create a guest account.
• Existing guests (ExistingExternalUserSharingOnly): Sharing is only allowed with the guest users already in an organization’s directory.
• Only people in your organization (Disabled): No sharing with external users is allowed.

When defined, the external sharing setting is stored in the externalsharingcontroltype value in the label. After connecting a PowerShell session to the compliance center endpoint, we can examine this setting:

$Settings = Get-Label "Confidential Access" | Select -ExpandProperty LabelActions | ConvertFrom-Json
$Settings | ?{$_.Type -eq "protectsite"} | Select -ExpandProperty Settings

Key                        Value
---                        -----
allowfullaccess            false
allowlimitedaccess         false
blockaccess                true
disabled                   false
externalsharingcontroltype Disabled

Label Settings and Tenant Settings

As noted above, the settings available in a sensitivity label match those available for SharePoint Online. Figure 3 shows the values as set in the SharePoint admin center. Remember that the external sharing setting applied to a site cannot be less restrictive than that allowed by the tenant. For instance, if the tenant doesn’t allow Anyone links, you can’t set that external sharing level for a site.

The compliance center GUI doesn’t validate the external sharing capability selected for a label against what’s allowed by the tenant. If a less restrictive external sharing capability is set in a label, SharePoint Online will ignore the setting when it applies container management settings to the site.

The Effect of Caching

SharePoint Online caches sensitivity label data. For this reason, if you update an existing label to add a setting for external sharing, it won’t be available to be applied to sites for 24 hours. On the other hand, if you create a new label with a setting for external sharing, it will be available within 15 minutes.

The Office 365 for IT Pros eBook is the only book covering the technology, deployment, and management of Office 365 apps which is updated monthly. Don’t you think you need to understand what’s going on inside Microsoft’s cloud office service? Subscribe today!

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.

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.

Apply Microsoft 365 Sensitivity Labels at Scale to at-rest Data

Office 365 sensitivity labels are used to mark messages and Office documents with visual indicators of the importance or sensitivity of an item. Optionally, a sensitivity label can also invoke rights-management based encryption to protect labeled items.

Manual application of sensitivity labels is a good way to protect new messages and documents but does nothing to deal with the mass of documents and messages that already exist inside Office 365. To address the issue, Microsoft is running a preview program for auto-labeling Word, Excel, and PowerPoint files stored in SharePoint Online sites and OneDrive for Business accounts (Exchange Online will come later). The solution is intended to allow Office 365 tenants to protect existing content at scale without needing anyone to review large quantities of documents.

Microsoft’s Information Protection team recently hosted a Teams Live Event (Figure 1) to discuss what they’re working on in the preview and hope to make generally available later this year. The event recording (in Stream) is available to all (via anonymous join) and is a good example of how Teams can host product briefings if you’ve never used this technology. Further information is in the Yammer Information Protection community (also open)

Auto-Label Policies for Sensitivity Labels

Auto-label policies are configured with rules that look for at-rest (closed) documents containing Office 365 sensitive data types (such as bank account details). For example, a policy might include rules to detect documents with two or more instances of passport or personal identity card numbers and protect matching documents with a sensitivity label called Personal Information. Apart from the hundred-plus standard sensitive data types defined by Microsoft, auto-label policies also support custom sensitive data types defined by the tenant, meaning that you could scan for documents relating to a sensitive project and auto-label those files.

The source documents are examined by a background process capable of applying sensitivity labels to up to 25,000 documents per tenant daily (so it might take some time to process all content in the target sites). The process scans files to find instances of sensitive data types that match the rules set in auto-label policies. When a match is detected, the process applies the sensitivity label unless a user has already applied a sensitivity label (explicit assignment always beats auto-assignment). Labels applied automatically remain with documents if they are moved out of a site or account processed by an auto-label policy.

Preview Limits

The preview allows tenants to have up to ten auto-label policies (these limits might be upgraded when auto-label policies reach general availability). During the preview, each policy can cover up to ten sites or accounts. When generally available, the load imposed on the service needed to process files means that it’s likely that a limit for scanned sites will still exist. This will force tenants to select sites where sensitive data needing protection is most likely to be found. Office 365 E5 or Microsoft 365 E5 licenses are needed for all accounts that contribute files to the sites scanned by auto-label policies.

Test Mode

Auto-labels have a test mode, meaning that you can discover what files in a target location match the rules set in a policy. The idea is to allow administrators to tune policy rules by seeing what effect changes to rule conditions have. Another interesting feature is the content explorer, which displays lists of files containing sensitive data types in the scanned sites. Again, the idea is that admins can use this information to fine-tune auto-label policy settings.

If the preview progresses as expected, auto-label policies should be generally available in the Microsoft 365 compliance portal in the March-April 2020 timeframe. If you want to join the preview, you can register your tenant details here.

We have a complete chapter about protecting Office 365 content in the Office 365 for IT Pros eBook. We’ve been tracking the progress of sensitivity labels since their first introduction, so our coverage is pretty good.

Classic AIP Client and Label Management in Azure Portal to Cease

On January 6, Microsoft announced the deprecation of the classic Azure Information Protection (AIP) client and management of labels through the Azure portal (Figure 1). Following the discovery of some”technical issues” (and probably some customer feedback), Microsoft withdrew the announcement, which said that support for the client and management of its labels through the Azure portal would cease on March 31, 2021.

Microsoft hasn’t communicated what the issues blocking the deprecation are or when they will be resolved. A discussion in the Azure Information Protection Yammer community (available to join by anyone) said that Microsoft is “still committed to move all AIP customers as soon as possible to the new Unified Labeling client...” (Figure 2).

Unity of Focus

The focus of the Microsoft Information Protection team is on the unified labeling version of the AIP client, so-called because its labels are shared across multiple platforms. Microsoft’s public position expressed in April 2019 is 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.” They make a strong case that the unified client should be used for deployments if at all possible. Microsoft has published a list of features from the classic client which it does not intend to deliver in the unified client. If any of the missing features are critical to your deployment, you should discuss the situation with your Microsoft representative.

Given that the now-retracted announcement about the deprecation of the classic AIP client was made, we can anticipate that the deprecation will happen at some point in the near future. With this in mind, using the unified AIP client is the best route forward.

Office 365 Sensitivity Labels

In the Office 365 world, unified labels are known as sensitivity labels. Unified labels are unavailable in GCC. Office 365 tenants manage sensitivity labels through the Security and Compliance Center (or the new Microsoft 365 Security Center). The labels are published to users through label policies and can then be used to classify Office files according to their sensitivity. Recent versions of the Office click to run applications include native support for labels for Windows, Mac, and mobile, meaning that you don’t need to deploy the AIP client to use labels to protect confidential information, including the rights-management based encryption of email, Office documents, and PDF files.

Native support is in preview for Office online apps and the SharePoint Online/OneDrive for Business browser interfaces. Another preview allows sensitivity labels to apply classifications and control some aspects of Office 365 Groups, Teams, and SharePoint Online team sites. Both previews are expected to progress to general availability throughout Office 365 in a month or so.

Licensing

Office 365 E3 and E5 (and equivalent) tenants do not need additional licenses to use sensitivity labels. Tenants only need to deploy the AIP client if they want to apply labels to files stored outside Office 365 or to use some of the features not included in sensitivity labels, such as the AIP scanner. This article compares the current labeling capabilities of the classic, unified, and native clients. Microsoft says that some of the features missing from the unified client will appear during 2020.

Impact on Office 365 Tenants

In most cases, tenants who use the AIP client have migrated from the classic client to the unified client over the last year, so the deprecation should not have much impact unless you use the perpetual version of the Office desktop applications (including Office 2019), as this software does not include native support for sensitivity labels. In all cases, if you use the AIP client, you need Azure Information Protection P1 or P2 licenses, depending on the level of desired functionality.

Office 365 for IT Pros keeps an eye on what’s happening with Microsoft Information Protection and Office 365 sensitivity labels in Chapter 24. It’s a compelling read, if you’re into protection.

Protect Sensitive Email From Your iOS or Android Device

Office 365 notification MC193643 published on October 22 brings the good news that Outlook for iOS and Android has started to roll out native support for Microsoft 365 Sensitivity Labels. The update fulfills Office 365 roadmap items 32648 (iOS) and 32649 (Android). Support for sensitivity labels is available in Outlook for iOS 4.7.1 (which is what I tested) and Outlook for Android 4.0.39.

Native support means that you can protect messages created in Outlook mobile by applying any of the Office 365 Sensitivity Labels published to your account via a label policy. Outlook Mobile clients have long been able to read protected content; this change adds the ability to apply protection (encryption) on the device.

Support For Sensitivity Labels Gradually Spreading

OWA recently got native support as did the Office ProPlus desktop applications. The remaining outliers are the Office Online apps and the SharePoint Online and OneDrive for Business browser interfaces. Sensitivity labels and policies are managed in the Security and Compliance Center.

Protecting Sensitive Email with Outlook for iOS

To apply an Office 365 Sensitivity Label to a new message, click the […] menu when composing the message and select Add Sensitivity (or Edit Sensitivity if you want to change the assigned label).

Next, select the sensitivity label to apply to the message (Figure 2). You can select any of the labels published to your account. Some labels apply markings (like headers) to messages while others encrypt the content using a Rights Management Template. The labels with a padlock icon apply encryption.

After applying a label, you continue to finalize the text and send the message. In Figure 3 we can see that the assigned label will encrypt the message because a padlock icon is present.Labels used for marketing have a stamp-like icon (not a postage stamp).

Where Encryption Happens

Unlike Outlook desktop or OWA, the Outlook mobile clients do not encrypt protected messages on the device. Instead, the message passes to the Exchange Online transport service where the label is detected and encryption, if needed, is applied prior to recipient delivery. Any attachments for labeled messages receive the same level of protection.

Exchange Online uses the same approach to decrypt protected content before delivery to mobile devices.

S/MIME Support Too

Microsoft also announced (MC193642) the general availability of S/MIME support for Outlook Mobile. Although Office 365 Sensitivity Labels can protect email and documents for Office 365 users, including when items are sent outside the tenant, S/MIME is sometimes preferred because it is an Internet protocol or because an organization has invested in the certificate infrastructure for S/MIME. The good thing is that Office 365 users can now choose either approach to protect confidential information. See this link for more information about the two methods for email protection.

Office 365 Sensitivity Labels are covered in detail in the Office 365 for IT Pros eBook. Subscribe now to stay updated with developments across Office 365.

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.

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.

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!

Preparing for Office 365 Sensitivity Labels

Microsoft’s 15 February announcement (MC173614) that they are updating the Office 365 E3, E5, and Advanced Protection and Compliance SKUs to include new Information Protection service plans might have surprised some. After all, Office 365 E3 and E5 tenants are already automatically enabled for rights management and can use the feature to protect email and documents.

What’s happening is that Microsoft is clearing the decks to prepare for the general availability of Office 365 sensitivity labels and the predictable rise in interest about protecting Office 365 content, especially that stored in Exchange Online, SharePoint Online, and OneDrive for Business. It’s also likely that Microsoft will extend the reach of sensitivity labels to other Office 365 apps, including Teams.

Azure Information Protection Licenses

Today, a lacuna exists in licensing terms. Azure Information Protection (AIP) is the technology built on top of rights management. AIP labels can apply protection (encryption) or just mark content (for instance, with a footer). AIP labels can be used to protect content stored inside Office 365, but no integration exists between these labels and Office 365 apps because the predominant use of AIP labels is to mark content stored outside Office 365.

To use AIP labels to protect content, you need an AIP license. The license comes in two forms – standard and premium. The premium license covers automatic labeling, where applications like Word and Excel can apply labels based on content detected in files. Sensitivity labels support automatic labeling (enabled in the latest preview of the AIP client), and I anticipate that this will be a premium feature.

Clarifying Office 365 Licensing

Up to now, it has been assumed that because Office 365 E3 and E5 tenants are automatically enabled for rights management, their existing licenses cover protection applied by sensitivity labels. The new service plans clarify the matter. Although Microsoft’s announcement isn’t clear on the point, it seems logical that Office 365 E3 will include Information Protection for Office 365 – Standard in its list of service plans and Office 365 E5 will include Information Protection for Office 365 – Premium. This approach clarifies the licensing issue and allows for premium features like automatic labeling to be restricted to the higher Office 365 E5 SKU.

Because Information Protection is a separate service plan within a SKU (like Yammer or To-Do), you will be able to selectively enable or disable it for users. For instance, you might not want some people to apply sensitivity labels until they receive training and understand how protection works.

You don’t have to do anything to prepare for the change. The new service plans will turn up in March and once they appear in your tenant, you can enable or disable Information Protection for accounts through the Office 365 Admin Center or PowerShell.

For more information about Information Protection, read Chapter 24 of the Office 365 for IT Pros eBook. There’s lots of stuff there about encryption, rights management, templates, and AIP.

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.

Glitches Removed and Smoother Operation

Following October’s preview of a joint effort between Microsoft and Adobe to support Azure Information Protection for PDF files, the integration reached General Availability on December 11. As you’d expect, some of the glitches observed in the preview have been cleaned up and the integration seems pretty solid, like better visibility of Microsoft Information Protection (MIP) label information in protected files.

I tested the integration with the latest version of Adobe Acrobat DC. First, I removed all traces of the preview integration, including an older version of the Unified Labeling client, Acrobat DC, and the AIP plug-in. I then rebooted my PC and installed the latest version of the Unified Labeling client, Acrobat DC, and the plug-in. Everything worked as expected.

PowerShell Protection

Cmdlets to work with Microsoft Information Protection labels are included in the AIPService PowerShell module. You can use these cmdlets to protect PDFs in bulk. Before starting, you need to know the GUID for the label you want to apply. You can get this by running the Get-Label cmdlet in the Exchange Online Management module (use the Connect-IPSSession cmdlet to connect to the compliance endpoint first). Equipped with the label GUID, we can construct some code to find a set of files and apply the label to each file. Here’s a quick example that you can easily customize by setting the target location and target files variables to point to the files you want to process.

$TargetLocation = “c:\Temp\”
$TargetFiles = “*.pdf”
$Files = (Get-ChildItem ($TargetLocation + $TargetFiles) -File -Recurse)
ForEach ($F in $Files) {
   $FileName = $TargetLocation + $F.Name
   $FileStatus = (Get-AipFileStatus -Path $FileName)  
   If ($FileStatus.IsLabeled -eq $False) {
      Set-AIPFileLabel -Path $FileName -Label $LabelId }
}

Protected PDFs in Office 365

The current integration works with both the older AIP and Office 365 sensitivity labels labels and is designed to operate with files stored in Windows. PDFs are very popular in Office 365 environments, so it’s likely that protected PDFs will end up inside Office 365 as email attachments or stored in SharePoint Online and OneDrive for Business.

If you upload a protected PDF to a SharePoint Online document library and then try to open it, SharePoint can use the browser or an online viewer. If you use the Edge browser, it supports protected documents. Other browsers will use the viewer which doesn’t work with protected PDFs. You’ll have to download the PDF to a PC that has a supported PDF reader (like the Azure Information Protection viewer or Acrobat DC with the plug-in)  installed to be able to read the content.

Future Integration with Office 365?

It’s possible that Microsoft and Adobe will work together to enhance the integration by extending it into Office 365 so that access to protected PDFs is smoother and that users can use Office 365 sensitivity labels to protect PDFs in addition to AIP labels. 

For more information about Microsoft Information Protection and rights management protection, read 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…

Native Means No Extra Product Needed

In October 2018, Microsoft and Adobe launched the public preview of a “native” integration of rights management protection for Adobe PDF documents. Native means that the PDF files are protected using the ISO standard for PDF encryption (ISO 32000-2:2017) and can be opened and processed by applications which support the standard. Microsoft has also published a list of PDF readers that support protection applied by Azure Information Protection.

PDFs are a very popular way to exchange business documents between organizations. The big advantage for companies who invest in Azure Information Protection is that they will no longer need to buy, deploy, and manage third-party add-on products to read protected PDFs. Instead, they’ll be able to use Adobe Acrobat (Microsoft’s preferred reader) to open and interact with protected PDFs and have the rights defined for the file respected by the reader.

Figure 1 shows the security information for a PDF protected with Azure Information Protection. One disappointing point is that you don’t see the name of the template applied to protect the file (in this case, “Confidential”). This feature might be added by the time the preview turns into a generally available product.

Unlike previous third-party implementations of rights-management protected PDFs, which use a PPDF file extension to show the encrypted nature of the files, native-protected files keep their PDF file extension.

New Software Needed

To apply native protection to PDF files, you need the latest version of the Azure Information Protection client. To read the files, you need a supported reader that understands both the ISO standard and how to display the rights assigned by Azure Information Protection, such as Adobe Acrobat (third-party readers like Foxit are also available). The Edge Chromium browser can open and read protected PDFs. To use Acrobat, you currently need the preview released on October 12, which contains a preview of the integration plug-in. Both the reader and the plug-in must be installed.

Available in 2019

It’s important to underline that what’s been released is a preview that is not intended for use in production and only supports a specific version of Adobe Acrobat for now. Microsoft and Adobe aren’t saying when the native integration will be generally available, but I expect this to happen in or around early 2019. The new capability should be popular with Office 365 tenants as it will remove some complexity (and maybe cost) from their protection infrastructures.

All aspects of Azure Information Protection (including protected PDFs) are covered in Chapter 24 of the Office 365 for IT Pros eBook.