RMS sagt nein - Teil II

– eigentlich sagt RMS gar nichts. Conditional Access macht nur Dienst nach Vorschrift.

Wenn Conditional Access Richtlinien verschlüsselte E-Mail-Anhänge blockieren

Im ersten Artikel habe ich gezeigt, was im Hintergrund passiert, wenn externe Empfänger eine verschlüsselte Datei nicht öffnen können – und dass Entra ID nur dann ein Zugriffstoken für Azure Rights Management ausstellt, wenn die geltenden Conditional-Access-Richtlinien dies zulassen.

Heute geht’s um den nächsten Schritt:

Welche Conditional-Access-Policies genau verhindern diesen Zugriff – und warum?

🧩 Das Szenario

Heidi arbeitet weiter bei Contoso, ich bei BRÜHL SOLUTIONS. Ich schicke ihr wieder eine vertrauliche Datei per Mail – verschlüsselt durch ein Sensitivity Label. Dieses Mal existiert sogar ein Gastkonto für sie. Trotzdem: Word öffnet, lädt kurz, und dann … Fehlermeldung.

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

Also schauen wir uns an, welche Regeln im Hintergrund zuschnappen.

Kurz erklärt - Wa ist Conditional Access - und warum betrifft es verschlüsselte Dokumente?

Conditional Access (CA) ist der Mechanismus in Entra ID, mit dem festgelegt wird, unter welchen Bedingungen auf Cloud-Apps zugegriffen werden darf.

Diese Richtlinien greifen nicht nur bei sichtbaren Anmeldungen, sondern auch dann, wenn Anwendungen im Hintergrund ein Zugriffstoken für eine App anfordern – zum Beispiel für Azure Rights Management Services.

Wird der Zugriff durch eine Conditional-Access-Policy blockiert, stellt Entra ID kein Zugriffstoken aus. Der betroffene Dienst wird dann gar nicht erst erreicht – und genau das kann dazu führen, dass sich ein verschlüsseltes Dokument nicht öffnen lässt.

🚫 Vier typische Conditional-Access-Policies, die RMS blockieren

1️⃣ „Require compliant or hybrid-joined device“

Diese Policy verlangt, dass nur Geräte auf die Azure RMS App zugreifen dürfen, die in Intune registriert und als compliant markiert sind. Für interne Benutzer sinnvoll – für Externe fatal.

Heidis Laptop gehört Contoso, nicht mir. Mein Intune kennt ihn nicht, also ist er nicht compliant. Sobald Word den Schlüssel bei RMS anfordert, prüft Entra ID die Richtlinie und meldet:

„Kein compliant-Signal – Zugriff verweigert.“

Ergebnis: Datei bleibt verschlüsselt.

Selbst mit Gastkonto. Denn auch ein Gast sitzt meist an seinem eigenen Gerät, das "nicht compliant" ist.

2️⃣ „Require multifactor authentication (MFA)“

Viele Unternehmen fordern MFA für alle Cloud-Apps. Das ist grundsätzlich sinnvoll – problematisch wird es jedoch, wenn der Zugriff nicht interaktiv erfolgt.

Beim Öffnen eines verschlüsselten Anhangs fordert Word im Hintergrund ein Zugriffstoken für Azure Rights Management an. In diesem Moment gibt es keinen sichtbaren Anmeldeprozess und keinen MFA-Prompt.

Verlangt eine Conditional-Access-Policy dennoch ein MFA-Signal, kann Entra ID dieses nicht prüfen und stellt kein Zugriffstoken aus. Azure Rights Management wird nicht aufgerufen – und das Dokument lässt sich nicht öffnen.

Kein MFA-Nachweis → kein Schlüssel → Zugriff verweigert.

3️⃣ „Block access from unmanaged devices“

Diese Variante ist breiter als die erste. Sie blockiert alle Geräte, die nicht unter Verwaltung stehen – egal ob compliant-Prüfung aktiv ist oder nicht.

Manchmal erlaubt man noch Web-Access („browser only“), aber lokale Office-Apps fallen raus. Heidis Laptop ist nicht in meiner Verwaltung → Word greift lokal zu → blockiert.

Unterschied zu 1️⃣: Policy 1 prüft aktiv auf ein positives „compliant“-Signal. Policy 3 blockiert pauschal, wenn kein verwaltetes Gerät erkannt wird.

4️⃣ „Apply to All Cloud Apps“ (oder „Office 365“)

Der Klassiker. Viele Administratoren sichern ihre Umgebung ab, indem sie eine Policy für „All Cloud Apps“ definieren. Klingt logisch – ist aber tückisch.

Denn in „All Cloud Apps“ steckt auch die Anwendung „Microsoft Rights Management Services“ – also genau der Dienst, den Word im Hintergrund nutzt, um den Schlüssel zu holen.

Wenn diese globale Policy MFA oder Geräteanforderungen erzwingt, greift sie automatisch auch für RMS. RMS erwartet also, dass Bedingungen erfüllt sind, die gar nicht interaktiv bestätigt werden können. Ergebnis: endlose Anmelde-Schleifen oder „no access“.

💡 Das Muster dahinter

All diese Fälle folgen demselben Prinzip:

RMS blockiert, weil Conditional Access Bedingungen definiert hat, die in diesem Nutzungskontext technisch nicht erfüllt werden können.

Der Benutzer hat keine gültige Authentifizierung (oder kein gültiges Signal) →Entra ID verweigert RMS den Zugriff → Datei bleibt verschlüsselt.

🔧 Was man tun kann

• RMS gezielt von bestimmten CA-Bedingungen ausnehmen(z. B. Ausnahme für „Microsoft Rights Management Services“ oder „Office 365 Information Protection“)

• oder die Richtlinien so anpassen, dass sie für externe Benutzer realistisch erfüllbar sind – etwa durch Browser-Zugriff oder Entra B2B-Vertrauen.

Im nächsten Artikel schauen wir uns genau das an: Wie Entra B2B hilft – und warum es trotzdem oft nicht reicht. Denn auch mit Gastkonten kann RMS noch „nein“ sagen.