Wie Microsoft Sensitivity Labels den Zugriff auf Planner beeinflussen können

Ein Kunde meldete einen Vorfall, der auf den ersten Blick keine Logik hatte.

Nach der Einführung von Sensitivity Labels an eine Pilotgruppe konnte eine Praktikantin plötzlich nicht mehr in einem Planner-Plan arbeiten. (Sie war nicht Teil der Pilotgruppe). Der Plan hat bei der Einführung der Labels das Label "General" erhalten — ohne Verschlüsselung, ohne Rechteeinschränkung. Dokumente, die mit dem gleichen Label gelabelt worden sind, konnten problemlos weiterhin von ihr bearbeitet werden.

Als der Kunde sie in die Pilotgruppe der Label-Policy aufnahm, war der Zugang zurück.

Das ist die Sorte Vorfall, bei der man im ersten Reflex denkt: "Na klar, sie war nicht in der Policy, deswegen ging es nicht." Aber dieser Reflex passt nicht zu dem, was Microsoft selbst über Sensitivity Labels sagt.

Was eigentlich passieren sollte

Die Microsoft-Dokumentation zieht eine klare Trennlinie zwischen zwei Dingen, die in der Praxis ständig verwechselt werden.

Das eine ist das Anbringen eines Labels: Wer ein Label setzen oder ändern können soll, muss in einer Label-Policy enthalten sein, die dieses Label publiziert. Ohne Policy sieht der Nutzer das Label gar nicht.

Das andere ist das Öffnen gelabelter Inhalte: Hier ist die Policy-Mitgliedschaft irrelevant. Geregelt wird der Zugriff allein über die Schutzeinstellungen, die im Label selbst eingebettet sind — typischerweise Verschlüsselung mit Rechten auf bestimmte Personen oder Gruppen.

Daraus folgt eine Aussage, die für unseren Fall entscheidend ist:

Ein Label ohne Verschlüsselung kann niemanden vom Öffnen abhalten. Es gibt schlicht keine Berechtigung, die fehlen könnte.

Genau das war in unserem Fall die Konstellation. "General" trug keinen Schutz. Die Praktikantin hätte den Plan öffnen können müssen — Policy hin oder her.

Was tatsächlich beobachtet wurde

Sie konnte es nicht. Bis zur Aufnahme in die Pilotgruppe blieb der Plan zwar sichtbar, aber unaufrufbar.

Um das einzuordnen, habe ich es im eigenen Lab nachgestellt. Zwei Testnutzerinnen, kontrolliert in die Publishing-Policy aufgenommen und wieder entfernt, auf bestehenden und auf frisch erstellten gelabelten Plänen.

Und es trat tatsächlich auf — genau einmal. Eine Testnutzerin außerhalb der Label-Policy konnte einen gelabelten Plan nicht öffnen. Erst die Aufnahme in die Pilotgruppe stellte den Zugriff her. Exakt das Muster aus dem Kundenfall.

Danach war Schluss. Ich habe es immer wieder versucht — der Fehler ließ sich kein zweites Mal provozieren. Auch beim Kunden nicht. Ein einziges sauberes Auftreten, und dann nie wieder.

Reproduzierbar war damit nur, dass das Verhalten nicht stabil reproduzierbar ist: Es passiert, aber es lässt sich nicht erzwingen.

Was das bedeutet

Ein Vorfall, der einmal sehr deutlich auftritt und sich dann nicht mehr provozieren lässt, ist schwer einzuordnen. Er passt zu keinem sauberen Mechanismus — denn ein Mechanismus würde sich wiederholen lassen. Eher sieht es nach einem Zustand aus, der unter bestimmten zeitlichen Bedingungen entsteht und wieder vergeht. Aber das ist schon die erste Vermutung, nicht der Befund.

Ehrlich gesagt: Ich habe keine belastbare Erklärung. Ich habe ein paar Mechanismen durchgespielt — Cache- und Propagationsverhalten, Effekte aus der laufenden Rollout-Phase, eine begleitende Nebenwirkung an anderer Stelle —, aber keiner davon erklärt sauber, warum der Fehler genau einmal auftrat und sich danach nie wieder zeigte.

Was sich dagegen sicher sagen lässt

Zwei Dinge lassen sich unabhängig von der Ursache festhalten.

Erstens: Planner lässt sich nicht selektiv vom Default-Labeling ausnehmen. Es gibt keinen PowerShell-Schalter und kein app-spezifisches Opt-out, mit dem man Planner aus der automatischen Vergabe herausnimmt.

Zweitens: Bei der Umstellung kann es zu genau diesem Zugriffsfehler kommen. Auch ohne Verschlüsselung, auch bei einem Label, das nichts sperren sollte. Es tritt nicht zuverlässig auf, aber es tritt auf.

Zwei Empfehlungen für die Praxis

Aus dem, was wir sicher wissen, lassen sich zwei nüchterne Folgerungen ziehen.

Zugriffsprobleme nach einer Label-Änderung sollten in den ersten 24 Stunden nicht als Berechtigungsproblem behandelt werden. Der Reflex, sofort Scopes zu erweitern oder Menschen in Pilotgruppen aufzunehmen, kann ein Symptom auflösen, das sich von selbst aufgelöst hätte — und macht den Pilot dabei kaputt.

Wenn die Aufnahme in die Pilotgruppe das Problem behebt, heißt das nicht zwingend, dass die fehlende Mitgliedschaft die Ursache war. Es kann ebenso gut sein, dass der Eingriff selbst einen Refresh ausgelöst hat, den Abwarten genauso geleistet hätte.

Eine Frage an euch

Mein Lab hat den Vorfall nicht reproduzieren können. Vielleicht ist die Propagations-These die richtige, vielleicht das Preview-Verhalten, vielleicht etwas Viertes, an das ich nicht gedacht habe.

Habt ihr seit Dezember Zugriffsprobleme auf gelabelte Planner-Pläne gesehen — bei Labels ohne Verschlüsselung? Trat das einmalig auf oder dauerhaft? Was hat es gelöst — und wie sicher seid ihr, dass die Lösung wirklich die Ursache adressiert hat?

Schreibt es in die Kommentare oder schickt mir eine Nachricht. Wenn sich Muster zeigen, fasse ich sie in einem Folgeartikel zusammen.