Skip to main content

Microsoft Purview Information Protection

Foundation: Microsoft Purview Information Protection (MPIP) / Azure RMS​

Understanding the standard MPIP/Azure RMS workflow is essential before diving into DKE specifics, as DKE builds upon this foundation.

  • Core Functionality: MPIP is fundamentally a client-side encryption technology that automates key management for end-users, simplifying protection compared to traditional PKI. It relies heavily on Microsoft Entra ID for user identity (using email addresses or User Principal Names) to control authorization. Beyond encryption, it enforces usage restrictions (rights) – like preventing printing, restricting editing, or setting expiry dates – defined by the author or central policies (e.g., sensitivity labels). Crucially, these rights travel with the encrypted file.
  • Key Concepts & Components (Standard Flow):
    • Microsoft Entra ID: Provides identity services and tenant isolation. User/group identities (based on email/UPN attributes) control authorization throughout the process.
    • Purview Information Protection Service: Cloud service for managing sensitivity labels and protection settings within the Microsoft 365 tenant.
    • Azure Rights Management (Azure RMS) Service: The core cloud service holding the tenant's cryptographic keys (specifically, the Microsoft-managed key pair) and processing cryptographic requests.
    • Clients: Applications (like Microsoft 365 Apps) on user devices (desktops, mobile, virtual) or authorized cloud service instances that need to interact with protected content.
    • (DKE Specific) DKE Web Service: The customer-controlled component, which will be discussed in the context of the DKE flow later.

Standard Encryption Process (MPIP/Azure RMS)​

This describes how content is protected without DKE, using only the Microsoft-managed key:

  1. Label Application: A user applies a sensitivity label configured for encryption in an RMS-aware application (e.g., Word).
  2. Content Key Generation: The application generates a unique symmetric AES key (Content Key) in memory for this specific document (tied to its documentID).
  3. File Encryption: The application encrypts the document content stream using this unique Content Key.
  4. Publishing License (PL) Creation: The application creates a Publishing License (PL). This XML structure contains the Content Key, the usage rights/permissions defined by the label or author, and other metadata. Steps 2-4 occur locally within the application's memory.
  5. PL Encryption & Embedding: The application encrypts the sensitive parts of the PL (most importantly, the Content Key) using the Azure RMS tenant's public key (retrieved and cached from the Azure RMS service). The encrypted PL is then embedded within the document file structure. Note: Some metadata within the PL, like the URL of the tenant's Azure RMS service, remains unencrypted to allow clients to find the correct service.

Standard Decryption Process (MPIP/Azure RMS)​

This describes how authorized users or services access content protected without DKE:

  1. Open Attempt & Service Discovery: A user opens the protected document in an RMS-aware application. The application reads the Azure RMS service URL from the unencrypted part of the PL.
  2. Authentication & GIC: The user authenticates to the Azure RMS service via Microsoft Entra ID. If it's the user's first interaction with RMS, the service provisions a user-specific RSA key pair (GIC - Global Identity Certificate). The GIC private key is stored securely in the user's local profile (e.g., Windows profile); the public key is known to RMS.
  3. License Request: The application sends the encrypted PL (not the whole file) and proof of the user's identity (including their GIC public key) to the Azure RMS service identified in step 1.
  4. Authorization Check: Azure RMS validates the user's identity against the permissions defined in the PL, potentially checking Microsoft Entra ID group memberships or other attributes. It determines the user's effective rights for this specific document (permissions are additive if granted via multiple groups).
  5. Use License (UL/EUL) Issuance: If authorized, Azure RMS uses its tenant private key to decrypt the Content Key from the PL. It then creates an End User License (EUL), also known as a Use License. The EUL contains the decrypted Content Key and the user's specific effective permissions. This EUL is then encrypted using the user's public GIC key.
  6. Content Decryption & Enforcement: The application receives the encrypted EUL. It uses the user's private GIC key (stored locally) to decrypt the EUL, thereby retrieving the Content Key. The application then uses the Content Key to decrypt the actual document content and simultaneously enforces the permissions specified in the EUL (e.g., allowing viewing but disabling printing or copying).

Note on Service Access: This RMS flow isn't limited to end-user applications. Authorized cloud services (like Exchange Online transport rules, Data Loss Prevention services, Microsoft Purview eDiscovery, search indexers, Microsoft Copilot, etc.) can also act as RMS clients. They authenticate to Azure RMS, obtain a Use License if permitted, and decrypt content to perform their functions on the clear text data.

Last updated on