Gruppen und Lizenzierung

Die Gruppe ist die Einheit der Verwaltung — und die Stelle, an der Fehler skalieren

Einzelzuweisungen sind ehrlich: Wer einem Konto ein Recht gibt, sieht genau, was er tut. Sie skalieren nur nicht. Deshalb läuft in Microsoft Entra ID fast alles über Gruppen — Zugriff auf Anwendungen, Zuweisung von Lizenzen, der Geltungsbereich von Zugriffsregeln und, in einer Sonderform, sogar Rollen.

Der Preis steht selten daneben: Dieselbe Gruppe, die eine Änderung für 400 Personen auf einen Klick reduziert, macht einen Irrtum für 400 Personen wirksam. Eine falsch gesetzte Mitgliedschaftsregel nimmt keine Lizenz weg, sondern hunderte. Dieses Modul behandelt deshalb nicht nur, wie Gruppen funktionieren, sondern die vier Stellen, an denen sie sich anders verhalten als erwartet.

Zwei Gruppentypen, und einer kann weniger, als man denkt

Die Auswahl beim Anlegen wirkt wie eine Geschmacksfrage. Sie ist eine Festlegung darüber, was überhaupt Mitglied werden kann.

Sicherheitsgruppe

Steuert Zugriff auf gemeinsam genutzte Ressourcen. Mitglieder können Benutzer, Geräte und Dienstprinzipale sein.

Microsoft-365-Gruppe

Ist für Zusammenarbeit gedacht und bringt Postfach, Kalender und weitere gemeinsame Ablagen mit. Mitglieder können nur Benutzer sein.

Die Einschränkung der Microsoft-365-Gruppe ist der häufigste Stolperstein: Wer eine Gruppe für eine Zugriffsregel braucht, die Geräte enthalten soll, kann keine Microsoft-365-Gruppe nehmen. Eigentümer dürfen bei beiden Typen sowohl Benutzer als auch Dienstprinzipale sein.

Daneben gibt es Verteilerlisten und E-Mail-aktivierte Sicherheitsgruppen. Sie sind ein Altbestand aus der Exchange-Welt und lassen sich laut Dokumentation ausschließlich im Exchange- oder im Microsoft-365-Admin-Center verwalten — nicht im Entra-Portal. Wer sie im falschen Werkzeug sucht, findet sie nicht und hält sie für gelöscht.

Eigentümer einer Gruppe — Ein Prinzipal, der die Mitgliedschaft verwalten darf, ohne eine Verzeichnisrolle zu besitzen. Eigentümerschaft ist der übliche Weg, Gruppenpflege an eine Fachabteilung zu delegieren.

Drei Mitgliedschaftsarten

Unabhängig vom Typ legt die Mitgliedschaftsart fest, wie jemand in die Gruppe kommt.

• Zugewiesen — Mitglieder werden ausdrücklich hinzugefügt und entfernt.
• Dynamisch für Benutzer — eine Regel über Benutzerattribute entscheidet laufend über Aufnahme und Entfernung.
• Dynamisch für Geräte — dieselbe Mechanik, aber über Geräteattribute.

Eine Regel sieht etwa so aus: (user.department -eq "Vertrieb"). Ändert sich das Attribut einer Person, wertet das System die Regeln erneut aus und nimmt sie auf oder entfernt sie. Das ist der Reiz — und zugleich der Grund, warum eine dynamische Gruppe nie als Nachweis taugt, wer zu einem bestimmten Zeitpunkt Zugriff hatte: Die Mitgliedschaft ist eine Funktion der Attribute, kein Protokoll.

Daraus folgt eine Arbeitsteilung, die man bewusst treffen sollte. Die Regel verlagert die Entscheidung über den Zugriff von der Gruppenpflege in die Attributpflege — und damit oft in ein anderes Team oder ein Personalsystem. Das ist meist richtig, weil die Abteilung dort ohnehin gepflegt wird. Es heißt aber, dass ein Tippfehler im Quellsystem zur Zugriffsänderung wird, ohne dass jemand im Identitätsbetrieb etwas getan hat.

Zugewiesen

Nachvollziehbar und langsam. Jede Änderung hat einen Urheber und einen Zeitpunkt — der bessere Weg für kleine, sensible Gruppen.

Dynamisch

Selbstpflegend und schnell. Der bessere Weg für große Gruppen entlang einer Organisationsstruktur — solange die Attribute verlässlich gepflegt sind.

Verschachtelung tut nicht, was du erwartest

Sicherheitsgruppen lassen sich ineinander verschachteln. Die Erwartung ist, dass Rechte dabei nach unten durchschlagen. An zwei betrieblich wichtigen Stellen tun sie das nicht — und beide sind ausdrücklich dokumentiert.

Beim Zugriff: Wird eine bestehende Sicherheitsgruppe in eine andere aufgenommen, erhalten laut Dokumentation nur die Mitglieder der übergeordneten Gruppe Zugriff auf die gemeinsam genutzten Ressourcen und Anwendungen.

Bei der Lizenzierung: Die gruppenbasierte Lizenzierung unterstützt verschachtelte Gruppen derzeit nicht. Weist du einer Gruppe mit Untergruppen Lizenzen zu, bekommen ausschließlich die Mitglieder der ersten Ebene eine Lizenz. Alle darunter bleiben unlizenziert — ohne Fehlermeldung, denn aus Sicht des Systems ist nichts schiefgegangen.

Rollenfähige Gruppen: eine Entscheidung ohne Rückweg

Soll eine Gruppe eine Verzeichnisrolle tragen, reicht eine gewöhnliche Sicherheitsgruppe nicht. Sie muss beim Anlegen als rollenfähig markiert werden — über die Eigenschaft isAssignableToRole.

isAssignableToRole — Eigenschaft einer Gruppe, die sie berechtigt, Verzeichnisrollen zu tragen. Sie lässt sich ausschließlich beim Anlegen setzen und ist danach unveränderlich.

Unveränderlich heißt hier wörtlich: Eine bestehende Gruppe lässt sich nicht nachträglich rollenfähig machen. Wer es versäumt, legt eine neue Gruppe an und zieht die Mitglieder um. Pro Tenant sind höchstens 500 solcher Gruppen möglich, und das Anlegen setzt mindestens die Rolle Privileged Role Administrator voraus.

Die zweite Einschränkung ist die interessantere: Rollenfähige Gruppen müssen die Mitgliedschaftsart Zugewiesen haben. Eine dynamische Mitgliedschaft ist nicht zulässig, und die Dokumentation nennt den Grund — eine automatisch befüllte Gruppe könnte ein unerwünschtes Konto aufnehmen, das damit die Rolle bekäme.

Passend dazu genügt beim Zugriff über Microsoft Graph die Berechtigung Group.ReadWrite.All für die Mitgliedschaft solcher Gruppen ausdrücklich nicht; erforderlich ist RoleManagement.ReadWrite.Directory. Ein Automatisierungsskript, das andere Gruppen problemlos pflegt, scheitert an dieser einen Sorte — und die Fehlermeldung nennt nur die fehlende Berechtigung, nicht den Grund.

Gruppenbasierte Lizenzierung: das Modell

Lizenzen werden einer Gruppe zugewiesen, und jedes Mitglied erbt sie. Tritt jemand bei, bekommt er die Lizenz; verlässt er die Gruppe, wird sie entzogen. Das ersetzt die Einzelvergabe und ist der Normalfall in jeder Organisation, die nicht von Hand zählen will.

Zum Zuweisen genügt eine der Rollen Groups Administrator, License Administrator oder User Administrator — die Rolle Global Administrator ist dafür nicht nötig und wäre nach dem Prinzip aus dem ersten Modul die falsche Wahl. Per Skript übernimmt das Set-MgGroupLicense.

Die Dokumentation nennt dazu einige Grenzen des Admin-Centers, die bei größeren Umstellungen die Arbeitsweise bestimmen: Lizenzen lassen sich höchstens 20 Gruppen auf einmal zuweisen, und die Funktion zum erneuten Verarbeiten nimmt sich höchstens 20 Benutzer gleichzeitig vor. Wer eine Umstellung für tausende Konten plant, plant sie also in Wellen — nicht, weil das vorsichtiger wäre, sondern weil das Werkzeug es so vorgibt.

Der Standort entscheidet, ob eine Lizenz überhaupt zulässig ist

Nicht jeder Microsoft-Dienst ist in jedem Land verfügbar. Deshalb hängt an jedem Benutzerkonto eine Standortangabe, und ohne sie lässt sich eine Lizenz nicht regulär vergeben.

Für die gruppenbasierte Lizenzierung gilt laut Dokumentation eine Sonderregel: Benutzer ohne eigene Standortangabe erben den Standort des Tenants. Das klingt bequem und ist die eigentliche Falle — in einer Organisation mit Standorten in mehreren Ländern bekommen dann alle den Standort der Zentrale, und niemand merkt es, solange die Dienste zufällig überall zulässig sind.

Wenn die Lizenz nicht ankommt: fünf benannte Fehler

Schlägt eine Zuweisung für einen Benutzer fehl, trägt sein Lizenzzustand einen Fehlerwert. Diese Werte sind in der Graph-API dokumentiert, und jeder benennt eine andere Ursache — sie zu kennen ersetzt das Raten.

CountViolation

Es sind nicht genug Lizenzen vorhanden. Die Gruppe ist größer als der Bestand.

MutuallyExclusiveViolation

Zwei Dienstpläne schließen einander aus — typisch, wenn jemand dieselbe Leistung schon aus einer anderen Zuweisung hat.

DependencyViolation

Ein Dienstplan setzt einen anderen voraus, der abgeschaltet oder nicht zugewiesen ist.

ProhibitedInUsageLocationViolation

Der Dienst ist am Standort des Benutzers nicht zulässig — hier trifft der vorige Abschnitt auf die Wirklichkeit.

UniquenessViolation

Eine Angabe, die eindeutig sein muss, ist es nicht — etwa eine doppelte Proxy-Adresse.

Daneben steht der Zustand der Zuweisung selbst mit den Werten Active, ActiveWithError, Disabled und Error. Besonders ActiveWithError verdient Aufmerksamkeit: Die Lizenz wirkt, aber ein Teil davon nicht — ein Zustand, den eine reine Erfolgsprüfung übersieht.

Direkt oder geerbt: `assignedByGroup`

Ein Benutzer kann dieselbe Lizenz direkt zugewiesen bekommen und aus einer Gruppe erben. Im Portal sieht beides gleich aus, in der Graph-API nicht: Der Lizenzzustand trägt das Feld assignedByGroup. Ist es leer, war es eine Einzelvergabe; steht dort eine Gruppen-ID, stammt die Lizenz von dieser Gruppe.

Das ist das entscheidende Feld bei jeder Aufräumaktion. Wer die Mitgliedschaft in einer Gruppe entfernt und die Lizenz bleibt bestehen, hat keine Fehlfunktion gefunden, sondern eine zusätzliche Einzelvergabe, die schon vorher da war. Umgekehrt hat eine gelöschte Einzelvergabe keine Wirkung, wenn die Gruppe dieselbe Lizenz erneut vergibt.

disabledPlans — Liste der innerhalb einer Lizenz abgeschalteten Dienstpläne. Zwei Benutzer mit demselben Produkt können völlig verschiedene Dienste nutzen, wenn hier Unterschiedliches steht.

Aus diesen beiden Feldern entsteht die Frage, die bei jeder Lizenzprüfung zuerst gestellt gehört: Nicht Hat die Person das Produkt?, sondern Woher kommt es, und welche Teile davon sind abgeschaltet?. Zwei Personen mit derselben Lizenzbezeichnung können unterschiedlich ausgestattet sein, und die Ursache steht nie im Produktnamen.

Ein Produkt, drei Namen

Dasselbe Produkt heißt an drei Stellen verschieden, und Skripte scheitern regelmäßig an dieser Übersetzung.

Anzeigename

Office 365 E3 — was im Portal und im Admin-Center steht.

Zeichenkette

ENTERPRISEPACK — die Eigenschaft skuPartNumber der Graph-Ressource subscribedSku.

GUID

6fd2c87f-b296-42f0-b197-1e91e994b900 — die Eigenschaft skuId, der stabile Bezug für Automatisierung.

Für Skripte ist die GUID die belastbare Größe: Anzeigenamen ändern sich mit dem Marketing, und die Zeichenkette trägt historische Namen, die mit dem heutigen Produkt wenig zu tun haben. Der Preis ist Lesbarkeit — ein Skript voller GUIDs erklärt sich nicht selbst und braucht einen Kommentar, der sagt, welches Produkt gemeint ist.

Durchgerechnet: einen Benutzer zwischen lizenzierten Gruppen umziehen

Der Preis dieser Reihenfolge ist eine kurze Doppelbelegung: Für die Dauer der Überlappung zählt die Person in beiden Gruppen, und bei knappem Lizenzbestand kann genau das ein CountViolation auslösen. Wer sehr knapp kalkuliert, muss den Umzug entweder in kleinen Wellen fahren oder vorher Bestand schaffen.

Die Reihenfolge, die alles zusammenhält

Der letzte Schritt ist der, der in der Praxis am häufigsten fehlt. Eine Lizenzzuweisung an eine Gruppe gilt sofort als erledigt, weil sie im Portal grün aussieht. Ob sie bei jedem einzelnen Mitglied angekommen ist, steht woanders — im Lizenzzustand des Benutzers.