RMS sagt nein: Warum verschlüsselte E-Mail-Anhänge bei externen Empfängern scheitern

Immer wieder das selbe:

„Externe Empfänger können verschlüsselte E-Mail-Anhänge nicht öffnen“

Die Datei ist korrekt gelabelt und der Versand klappt. Technisch scheint alles in Ordnung zu sein, das Dokument ist sogar in der Email-Vorschau sichtbar – und trotzdem kann es in der Word Applikation nicht geöffnet werden und endet beim Empfänger mit einer Fehlermeldung. Beispielsweise diese hier:

Was dann oft passiert: Man sucht den Fehler bei Purview, beim Label oder bei Outlook. Aber das Problem sitzt tiefer. Es steckt im Zusammenspiel vom Rights Management Services (RMS) und Conditional Access – also genau da, wo Identität, Zugriff und Sicherheitsrichtlinien aufeinandertreffen.

Ich werde dieses Thema in den nächsten Artikeln Schritt für Schritt durchexerzieren, damit wirklich klar wird, was technisch passiert, warum RMS blockiert, und wo man ansetzen muss, um das Problem dauerhaft zu lösen.

🧩 Das Setting

Heidi (die Empfängerin) arbeitet bei Contoso, ich (die Absenderin) bei BRÜHL SOLUTIONS (😎). Ich schicke ihr eine vertrauliche Präsentation per E-Mail – geschützt mit einem Microsoft Purview Sensitivity Label, das den Anhang automatisch verschlüsselt.

Ich fühle mich sicher und erwarte von Heidi ASAP eine Bearbeitung. Doch bei Heidi geht nichts. Sie klickt doppelt auf die Datei, Word öffnet sich – und dann:

„Sie haben keine Berechtigung, dieses Dokument zu öffnen.“

Peinlich und auch ärgerlich für mich.

⚙️ Was im Hintergrund passiert

Sobald Heidi den Anhang aus der Email öffnen möchte, startet Word im Hintergrund eine unsichtbare Kommunikation mit Azure Rights Management Services (RMS). RMS ist der Dienst, der entscheidet, ob jemand den Entschlüsselungsschlüssel bekommt oder nicht.

Das Zusammenspiel sieht vereinfacht ungefähr so aus:

Word (klopft beim Entra ID des Absenders): „Hey Entra, Heidi möchte diese Datei öffnen, aber sie ist verschlüsselt.

Entra ID: "Ok, ich prüfe zuerst, ob Heidi eine gültige Identität hat und ob sie - unter den geltenden Conditional-Access-Richtlinien - den RMS-Dienst nutzen darf."

Entra ID wertet intern die CA-Policies aus...

Entra ID: „Hallo Word – leider kann ich dir den Zugriffstoken nicht geben. Heidi erfüllt nicht alle Bedingungen, um auf den RMS-Dienst zuzugreifen.“

Und das ist kein Fehler. Entra ID blockiert den Zugriff bereits während der Token-Ausstellung. Der Azure Rights Management Dienst wird erst gar nicht aufgerufen.

🔍 Warum das so ist

Damit RMS den Schlüssel herausgeben darf, müssen zwei Dinge gleichzeitig funktionieren:

1️⃣ Authentifizierung – Entra ID muss wissen, wer da anfragt. Ohne gültige Identität kein Zugriff.

2️⃣ Autorisierung – Die Conditional Access Policies müssen den Zugriff auf die App „Azure Rights Management Services“ erlauben.

Scheitert eines davon, bekommt RMS kein grünes Licht. Und ohne grünes Licht kein Schlüssel.

💡Das Grundmuster lautet:

Damit ein verschlüsselter Anhang geöffnet werden kann, muss Entra ID ein Zugriffstoken für Azure Rights Management Services ausstellen.

Dieses Zugriffstoken ist die zwingende Voraussetzung dafür, dass Azure Rights Management den Entschlüsselungsschlüssel bereitstellen darf. Kommt das Token nicht zustande, endet der Prozess an dieser Stelle – unabhängig davon, ob das Sensitivity Label korrekt konfiguriert ist oder der Versand technisch einwandfrei funktioniert hat.

Es gibt verschiedene Gründe, warum Entra ID ein solches Zugriffstoken nicht ausstellt. Diese Gründe liegen typischerweise nicht im Label selbst, sondern im Zusammenspiel von Identität, Zugriffskontext und Richtlinien.

In den nächsten Artikeln beleuchte ich diese Ursachen Schritt für Schritt und zeige, an welchen Stellen in Entra ID man ansetzen muss, um solche Szenarien nachhaltig zu verstehen und zu beheben.