Was ein Joiner-Mover-Leaver-Prozess tatsächlich automatisiert

„JML“ klingt nach drei gleichwertigen Fällen. In der Umsetzung sind es drei sehr verschiedene Probleme, und nur eines davon ist wirklich schwer.

Joiner: das gelöste Problem

Der Eintritt ist der Fall, den fast jede Organisation im Griff hat, weil er sofort auffällt, wenn er fehlschlägt. Jemand sitzt am ersten Tag da und kommt nicht rein: Das eskaliert von selbst.

• —Konto anlegen, mit einem Namensschema, das auch beim zweiten Schmidt noch funktioniert
• —Attribute setzen: Abteilung, Vorgesetzter, Position, Standort, die spätere Grundlage jeder dynamischen Gruppe
• —Gruppenmitgliedschaften aus der Rolle ableiten statt einzeln zuweisen
• —Lizenz zuweisen, idealerweise gruppenbasiert statt direkt
• —Startanmeldeinformationen ausgeben, ohne ein Passwort über einen ungesicherten Kanal zu schicken

Die einzige echte Entscheidung hier ist, wie viel man direkt zuweist und wie viel über Gruppenmitgliedschaft nachläuft. Alles, was direkt zugewiesen wird, muss später einzeln wieder eingesammelt werden. Alles, was an einer Gruppe hängt, verschwindet, wenn die Mitgliedschaft endet. Diese Entscheidung bestimmt, wie schwer der Leaver später wird.

Mover: das unterschätzte Problem

Der Wechsel ist der Fall, bei dem still etwas kaputtgeht. Jemand wechselt aus dem Vertrieb in die Buchhaltung, bekommt die neuen Berechtigungen und behält die alten. Nichts bricht, niemand beschwert sich, und genau deshalb fällt es nicht auf.

Technisch ist ein Wechsel keine Änderung, sondern zwei: eine Zuweisung und ein Entzug. Automatisiert wird fast immer nur die erste Hälfte. Nach drei Wechseln in fünf Jahren hat eine Person die Zugriffsrechte von vier Abteilungen. In der Access Review erscheint das dann als „gewachsen“. Dabei ist es schlicht nie aufgeräumt worden.

Der sauberste Hebel dagegen ist, Mitgliedschaften nicht zu verwalten, sondern abzuleiten. Wenn eine dynamische Gruppe auf department gefiltert ist, erledigt eine einzige Attributänderung beide Hälften: Die alte Mitgliedschaft endet, die neue beginnt. Voraussetzung ist allerdings, dass das Attribut überhaupt gepflegt wird, und dass klar ist, welches System es besitzt.

Leaver: das Problem, das bricht

Der Austritt bricht in der Praxis am häufigsten, und zwar aus einem unspektakulären Grund: Es fehlt der Auslöser. Beim Eintritt gibt es einen Termin, an dem jemand vor der Tür steht. Beim Austritt gibt es ein Datum in einem System, das nicht mit der IT spricht.

Der Rest ist eine Reihenfolge, die man einmal festlegen und dann einhalten muss:

1. 1.Konto deaktivieren, der schnelle und umkehrbare Schritt
2. 2.Aktive Sitzungen widerrufen, sonst laufen bestehende Token weiter
3. 3.Gruppenmitgliedschaften entfernen und Lizenzen einsammeln
4. 4.Postfach und Dateien übergeben, bevor irgendetwas gelöscht wird
5. 5.Owner-Rollen prüfen: verwaiste Gruppen, Apps und Teams
6. 6.Löschen, deutlich später als es sich anfühlt

Zwei Punkte daraus sind es, die in Skripten regelmäßig fehlen. Der erste: Deaktivieren beendet keine Sitzung. Ein ausgestelltes Refresh-Token bleibt gültig, bis es abläuft. Das Konto ist gesperrt, der Zugriff läuft weiter.

Der zweite: Ownership. Wenn die einzige besitzende Person einer Gruppe geht, hat diese Gruppe niemanden mehr, der sie verwaltet. Das merkt man erst Monate später, wenn jemand eine Mitgliedschaft ändern möchte und es niemanden gibt, der das darf.

Was ich daraus mitgenommen habe

Als ich den Ablauf im Lab einmal komplett von Hand über Graph PowerShell durchgebaut habe, war die eigentliche Erkenntnis nicht technisch. Die Schritte sind einzeln unspektakulär. Der Aufwand steckt darin, sie in die richtige Reihenfolge zu bringen, jeden Schritt so zu schreiben, dass er ein zweites Mal ohne Schaden laufen kann, und überhaupt erst zu wissen, dass jemand das Unternehmen verlassen hat.