Conditional Access policies and encrypted documents

Reading time: 10 minutes

Introduction

Seamless B2B collaboration is crucial for most organizations these days. And Microsoft 365 offers a lot of (secure) options for this. But working securely and easily is not always as straightforward. As one organization recently discovered.

To be fair and upfront; the information in this article is also available from Microsoft Learn. It did take me some time to find this. Also, I’ve written an article earlier on the subject of Azure AD accounts and the new B2B Collaboration options which are described below.

What is the issue?

The focus of this article is on Microsoft Purview Information Protection (or Microsoft Azure Information Protection) and how encryption affects the end-user. The scenario is easy enough:

A user from organization X creates an Excel sheet. This sheet is labeled as “Highly confidential” and user-defined permissions are assigned. These permissions include a user from organization Y. Both organizations use Microsoft 365 and are therefore using Azure Active Directory. The document is stored in SharePoint Online and then shared with the user for organization Y (and also using email).

When the user tries to open the document, Information Protection tries to ascertain the permissions. And in no time, this error message is displayed.

This is weird. Both users have an Azure AD account. And using an Azure AD (or Microsoft Live) account is required for encrypted documents to be decrypted.

Well. This is correct and the identities of these users are not the problem. Azure Active Directory conditional access and guest users are.

Understanding authentication

To understand the problem, we must have an understanding of the authentication process for Microsoft Purview Information Protection. Assigning permissions to a document using the platform relies on Azure Rights Management, which in turn uses Azure Active Directory for user authentication.

Encryption and decryption of documents depend on the Azure Active Directory. And when you don’t have such an account (or a supported Microsoft account), Microsoft offers a so-called “RMS for individuals” account. This is basically an Azure Active Directory account created in an unmanaged tenant.

When you open a protected document, both Azure Active Directory and Azure Rights Management will be contacted by the information protection client. Azure Active Directory will check if the account exists in any Azure Active Directory and Azure Rights Management will be contacted to check the permissions. These checks will be performed by the information protection client and the cloud service handling these checks is Microsoft Azure Information Protection.

Note: this is in a very small nutshell 🙂

So, what is the problem? In my scenario, the requirements are met. Both users have an Azure Active Directory account and therefore should be able to open the document. Well, the problem has to do with Conditional Access and guest accounts.

Conditional Access

It is very common (and sound) practice to use conditional access rules in Azure Active Directory. It is part of a zero-trust architecture and when done right, very powerful. I will not delve too deeply into these rules. But you do need to realize that these rules will apply to users (internal and/or external) and can be aimed at specific cloud applications.

In most cases, rules are applied to all users and all applications – with some exceptions applied.

Some years ago, Microsoft announced that Azure Information Protection (as it was then known) was to become another app that could be targeted by conditional access rules. The use-case for this was to add more security to specific users of the information protection service. For example: when accessing specific documents from an untrusted location, MFa could be enforced.

Do note:

1. This is the Microsoft Azure Information Protection service, which is called by the information protection client when opening a labeled document for the first time;
2. This service is part of the “All cloud apps” section in a conditional access rule;
3. A conditional access rule is triggered based on the account used to log in to Azure Active Directory.

The third note above is most important for the issue described above.

Guest accounts

When you have proper guest accounts, you can apply the Conditional Access rules to these as well. When accessing the resources in your tenant, these guests will be asked to comply with these rules. An example might be that MFa is required.

Let’s say that in the example above, the user from organization Y did have a guest account in the tenant of organization X. When opening the protected document, he would need to accept the MFa prompt. And then the document would have opened.

But instead, the user was surprised to see the error message above. Most probably, the user did not have a guest account. And this makes sense, from a Microsoft 365 perspective. Not too long ago, when a document and/or site was shared with an external party – an external/guest account was created in Azure Active Directory. That is to say: if this was configured in the Sharing settings for SharePoint Online and OneDrive.

Microsoft enhanced this experience with One Time Passcodes (OTPs) when sharing documents. No external/guest users were created. Instead, the user received this OTP via email. Nowadays, it is even the default setting for SharePoint to use the concept of a SharePoint Online guest account. Which is not the same as an Azure Active Directory guest account.

So, put simply, at this moment you will probably not have real guest users added to your tenant. There is an option to solve this, however, and my colleague Pim Jacobs wrote this article about the Azure B2B integration for SharePoint and OneDrive.

Putting two and two together

Getting back to the issue at hand. The user from organization Y is presented with an error stating that there is no guest user known in the tenant of organization X.

We have conditional access rules aimed at all users, including guests. These rules include Microsoft Azure Information Protection. Guest users are no longer created in the tenant and therefore do not exist.

And here we have the problem: the conditional access rules cannot determine if the user can access the Microsoft Information Protection platform in order to get the permissions to the document. The document cannot be opened and the error-message is displayed.

What does Microsoft say?

Microsoft confirms this scenario. Although I doubt that all the implications are always clear. For example, in this article on external collaboration.

Microsoft does offer four possible solutions (or workarounds).

1. Start using the cross-tenant access settings in Azure Active Directory. This is a somewhat new function, that is also required for Microsoft Teams Shared Channels. In this situation, any MFa claim will be trusted from the external Azure Active Directory;
2. Create guest accounts in the tenant;
3. Remove Microsoft Azure Information Protection from any conditional access policy;
4. Remove external users from the scope of any conditional access policy, including Microsoft Azure Information Protection.

As a short-term solution, I would probably go for option 3. The use case for adding this platform to a conditional access rule is very specific. If you do not need it and have set up comprehensive conditional access rules for other cloud platforms – then this is definitely an option. Option 2 might work. But look closely at this article, although this only applies to SharePoint Online. In the end – option 1 is best for B2B collaboration. It allows for more functionality but also solves these kinds of problems.

Additional information

Microsoft Learn – FAQ – AIP and conditional access

Authenticated users setting

Microsoft Tech – secure external collaboration using labels

Microsoft Learn – secure external collaboration

That’s it.

I hope this article was helpful.