Sensitivity labels – Authenticated users

The option “Authenticated users” has been around for some time. Even when we were still talking about Azure Information Protection, this setting was present when configuring the permissions within a label. In this blog (and video) I want to show you what to expect from this setting when working with guest-users. The video has been added at the end of this article, but you can also access it here.

Encryption

Encryption is the most important aspect to consider when looking at the permissions for a label. Microsoft Information Protection uses Azure RMS to encrypt and decrypt information, based on these permissions. In the most common set-up the keys used for this encryption are stored in Azure and you will need an Azure AD account to encrypt/decrypt documents. This also goes for guest-users!

Testing

So, an Azure AD account is required for the encryption to work on documents. Microsoft also provides us with information which states that information protection also works great in external collaboration scenario’s, using guest accounts.

But this information (Secure external collaboration using sensitivity labels – Microsoft Tech Community) also includes a very specific mention when discussing the types of accounts – see below…

And the same mention goes for any other (non Microsoft) email address. So, does this work? Well, to make a long(er) story short: yes, but there are some caveats.

Working with guests – sharing links

When working with guests or externals from Office 365 you basically have two major options: share information (documents, folders) or share access to the entire container (Microsoft Teams, SharePoint Online). When sharing a document, the external party receives an e-mail containing the link. When accessed, a passcode is required which will be send to the e-mail address specified. Based on this link, the document will be opened in either read-only or edit-mode (Office documents that is).

In this case, the external party does not need any specific Microsoft account. Any e-mail address will do. And this is relevant for the sensitivity label. Let’s say we have a document with a sensitivity label that has permissions assigned to it. These permissions allow john@email.com to open this document. But when this document is shared using SharePoint Online, John will see this:

Not to user-friendly error message, this. But the cause is easily determined. John@mail.com does not have a Microsoft account associated to it. And therefor, the document cannot be decrypted using just this e-mail address. And that’s what Microsoft mean when they mention “Recipients would have to create a Microsoft account…..”

Working with guests – invites

So, let’s work with guest in Azure AD. We will invite John to our tenant (either by adding him to a Teams environment or using Azure AD itself). John will be prompted to create a Microsoft account and MFa is enforced. This latter part is not standard, but mandatory in my book.

When accessing the Teams environment or using a sharing link, John now uses the newly created Microsoft account. And because of the labels permission settings – this now works like a charm.

So, if this works – what kind of accounts can be used? In the video I use three accounts to access labeled documents. These are:

• An Office 365 account (Azure AD);
• A Microsoft account (Outlook.com);
• A non-Microsoft account (Protonmail.com) – with a Microsoft account created.

There can be no surprise that these accounts all work with sensitivity labels. But when I would have shared a protected document with the Protonmail.com user, without a Microsoft account attached, I would have received the same message.

Authenticated users setting

In the video I use three different kinds of documents:

• An non-labeled document;
• A labeled document only accessible to internal users;
• A labeled document accessible to internal users and all authenticated users.

In order for this to work, I need the “Authenticated Users” setting in my label. As this term indicates, any user that can authenticate against Azure AD will be able to access the labeled documents and get “Viewer” rights. So this is not the most restrictive setting available. You will need to manage access to these labeled documents on the container level as-well (and/or add Conditional Access to the mix).

So, let’s test this out. Using the account above, all three documents can be accessed. Two of these can be opened (first and second picture). But because one of the documents does not have the “Authenticated Users” setting, all guest-users receive an error-message (third picture).

Wrapping up

Azure AD still is one of the most important components for sensitivity labels. That is – when we are starting to use the permission settings. This is because of the encryption which kicks in when these permissions are applied to the document.

Because of this, please remember that all users (internal and guests) still need an Azure AD, Microsoft or RMS for individuals account for the “Authenticed users” setting to work.

More information? Check out this Microsoft blog:

Secure external collaboration using sensitivity labels – Microsoft Tech Community