Solution: Add an exclusion to all your Conditional Access rules for Microsoft Rights Management Services or 00000012-0000-0000-c000-000000000000. More details are below!

Organizations encounter various hurdles when sharing encrypted content with external entities using tools like Microsoft Azure Information Protection (AIP) and Purview Information Protection (MPIP). One common challenge arises from configuring Conditional Access (CA) policies, such as "Require multifactor authentication for all users and all apps," which, while enhancing internal security, can lead to authentication errors when interacting with external users or applications.

Errors, often indicated by messages like AADSTS50020 and AADSTS16000, occur when the requesting service attempts to access encrypted content using user accounts not recognized within the expected tenant. This discrepancy between the requesting service's expectations and the actual identity configuration within the tenant can confuse and hinder collaboration.

This post is a typical example of security over-configuration and proof that complexity kills and destroys the goal of governed and controlled collaboration for business purposes... Look at control objectives instead and layer it at a bare-minimum per layer (defense-in-depth, not maze).

Selected user account does not exist in RANDOM-TENANT-NAME and cannot access the application RANDOM-GUID-HERE in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account.

Det valda användarkontot finns inte i klienten RANDOM-TENANT-NAME och har inte åtkomst till programmet RANDOM-GUID-HERE i den klienten. Du måste först lägga till kontot som en extern användare i klienten. Använd ett annat konto.

AADSTS50020: User account 'RANDOM-USER@RANDOM-DOMAIN.tld' from identity provider 'https://sts.windows.net/RANDOM-GUID-HERE/' does not exist in tenant 'RANDOM-TENANT-NAME' and cannot access the application 'RANDOM-GUID' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

To address these challenges, organizations must navigate the complexities of external identity management within their Azure and Microsoft 365 environment. Understanding the nuances of Conditional Access and External Identities/Connected Organizations settings is crucial for troubleshooting authentication errors effectively.

Root Cause Break-Down

Conditional Access rules and/or Azure Active Directory External Identities B2B Collaboration Tenant Settings and/or Entitlement Management Connected Organisation settings not configured correctly.

Background

When configuring Conditional Access policies with the scope "All Cloud Apps," organizations are essentially applying the policy universally across all applications and services that utilize Entra ID / Azure Active Directory (AAD) for authentication. This means that the policy will be enforced whenever users attempt to access any cloud-based application or service integrated with AAD.

When the "All-Users" condition is applied alongside the "All Cloud Apps" scope, it implies that the policy will be enforced for all users within the organization, regardless of their assigned roles, groups, or licenses. In other words, every user account governed within the organization's Azure AD tenant will be subject to the conditions and requirements defined in the Conditional Access policy.

The devil is in the details

Read that previous paragraph a few times and ask yourself, what about guest users? Exactly that! All-Users includes guest users, external users and connected organisation users! That scope is way to wide or maybe it is intended behaviour.

Now go back to the part called All Cloud Apps. Back in the day, Microsoft Purview and Azure Information Protection were not deemed "Cloud App" nor was Rights Management a system recognised as Cloud but on-premise solutions. This behaviour has changed in 2022 and it became available under this umbrella.

The result leading to the issue

The behaviour of the "All-Users" and "All Cloud Apps" combination within a Conditional Access policy results in the specific configurations and requirements set by the organisation resulting in the error as described: "Create a user in the tenant first so it can authenticate to fulfil the requirement to gain access to the application".

What you need to remember is that the identity conveyed to the Idp, Azure Active Directory (AAD), and the application controls applied by Microsoft Purview Information Protection (MPIP) may not always align perfectly. While MPIP governs the correlation of identity and actions within the application and services and makes application based decisions, the decision to decrypt data is ultimately handled here by the umbrella term "Rights Management Services" (RMS). Access to RMS is dependent on your base identity conveyed and evaluated by AAD and since that involves CA as per your config, it dies as the identity is not where it thought it would be when it resolves the authentication chain. This distinction underscores the need for careful architecture, configuration and alignment between AAD settings and application controls to ensure seamless data protection and access management.

Access to data decryption is controlled by Rights Management Services (RMS), which relies on your conveyed identity to Entra ID / Azure Active Directory (AAD). If there's a mismatch between your identity and the settings in Microsoft Purview Information Protection (MPIP), it can cause authentication issues. To avoid this, make sure your AAD requirement settings match your application controls for MPIP.

Solution / Fix

None of these are really fixes, but let us call them workarounds instead as none of these are perfectly sound...

• Option 1: Exclude all guest users from the Conditional Access scope. This is a simple solution that effectively removes guest users from the scope of Conditional Access policies.
• Option 2: Create a user-flow that allows people to register for accounts and/or allow your personnel to add accounts to the tenant...
• Option 3: Exclude Microsoft Azure Information Protection (nowadays called Microsoft Rights Management Services) from the All Cloud Apps scope. This can be done by identifying the application with the ID 00000012-0000-0000-c000-000000000000 within your tenant and excluding it from the scope of Conditional Access policies.

Option 3 is by far the better approach as it not only addresses the immediate issue but also prepares and simplifies future B2B and collaboration settings not hindering its scopes. It does however open up for limited enumeration.

I don't like option 1 at all. It opens up too many use-cases that I would normally want to lock down. Hence my general recommendation is to use option 3 instead. However, in some cases, it is simply not feasible to implement option 3 and you would opt for option 2 due to other requirements.

Normal Setup

Please note that you have to do this for each of your conditional access policies with the scope of All-Users and All Cloud Apps, requiring multifactor or similar settings.

Step 1 - Exclude

Search for Microsoft Rights and it should pop up. If it doesn't look for Microsoft Azure Information instead. It will show you 00000012-0000-0000-c000-000000000000

Step 2

Be sure to review the warning message! Under normal circumstances, you should not need to review these by excluding your current user if you only changed that exclude scope. I normally click I understand. Proceed anyway.

For those wondering, I have multiple breakglass accounts. These accounts are the ones I have excluded as users despite the policy being called all users. I have ticked the All-Users box without excluding guests, but have excluded a group called "break-glass"

Cross Tenant or B2B settings

Whenever cross-tenant access settings restrict access by applications, they must be configured to allow access to the Microsoft Rights Management Service 00000012-0000-0000-c000-000000000000. If this access isn't allowed, users can't be authenticated and authorized to open encrypted content. This configuration can be set as a default setting and as an organizational setting.

• To permit sharing of encrypted content with another organization, create an inbound setting that allows access to Microsoft Rights Management Services or Microsoft Azure Information Protection (ID: 00000012-0000-0000-c000-000000000000)
• To permit access to encrypted content that users receive from other organizations, create an outbound setting that allows access to Microsoft Rights Management Services or Microsoft Azure Information Protection (ID: 00000012-0000-0000-c000-000000000000)

When these settings are configured for the encryption service, the application displays Microsoft Rights Management Services instead of Microsoft Azure Information Protection. Who knows when this will finally show the same value in both views...

Sources