Mitarbeiter-Offboarding automatisieren: Zugänge, Lizenzen und Hardware sauber zurückgeben

Beim Mitarbeiter-Offboarding automatisiert n8n die Logistik zuverlässig: Gruppenmitgliedschaften entfernen, eine Checkliste für IT und Hardware-Rückgabe anstoßen, Fristen überwachen. Für die drei Schritte, die beim Austritt eigentlich zählen – Konto deaktivieren, Sitzungen widerrufen, Lizenz entziehen – dokumentiert der Microsoft-Entra-ID-Node selbst keine passenden Felder; verlässlich belegt ist nur der Weg über den HTTP-Request-Node direkt gegen Microsoft Graph.

Dieser Beitrag zeigt den technischen Aufbau für beide Wege und ein eigenes Werkzeug, mit dem Sie einordnen, welcher Zugang welche Behandlung braucht.

Was beim Austritt zusammenkommt

„Offboarding automatisieren” klingt nach einem einzigen Schritt. In Wirklichkeit treffen beim Austritt drei Arten von Zugang aufeinander, die unterschiedlich viel Vorsicht brauchen – und die ein Workflow, der „das Konto” als einen Gegenstand behandelt, leicht gleich behandelt.

Risikoklasse	Typische Beispiele	Was das für die Automatisierung bedeutet
1. Standard-Zugang	Benutzerkonto, Standard-Lizenz, Mitgliedschaft in normalen Teams/Gruppen	Vollständig automatisierbar: deaktivieren, Sitzungen widerrufen, Lizenz entziehen, aus Gruppen entfernen.
2. Privilegierter Zugriff	Administratorrollen, Freigaberechte in Finanz- oder Personalsystemen, Eigentümerschaft an Teams/Gruppen	Der Workflow kann den Entzug anstoßen, aber die Hürde steigt mit der Privilegierung des Zielkontos: Laut Microsofts eigener Tabelle „Who can perform sensitive actions” reicht für viele administrative Rollen weiterhin ein User Administrator als Akteur, für hoch privilegierte Zielkonten – etwa Global Administrator oder Privileged Authentication Administrator selbst – aber nur noch Privileged Authentication Administrator oder Global Administrator. Welche Rolle im Einzelfall reicht, hängt an der genauen Rolle des Zielkontos und gehört vor dem Bau geprüft, nicht angenommen. Eigentümerschaften (wer wird neuer Owner eines Teams?) sind ohnehin eine Entscheidung, kein Automatisierungsschritt.
3. Geteilte Konten und Tokens	Shared-Mailbox-Passwörter, Dienstkonten, persönliche API-Keys, Zugänge zu Tools außerhalb der Unternehmensanmeldung	Liegt außerhalb von Microsoft Entra ID. Kein Node sieht diese Zugänge – sie gehören auf eine eigene, von Menschen geführte Checkliste, die der Workflow allenfalls anstößt.

Die Falle sitzt zwischen Stufe 1 und Stufe 2: Eine einzelne „Austritts”-Tabelle, die Standardkonten und privilegierte Rollen in derselben Spalte führt, lässt einen Workflow, der die ganze Spalte liest, genauso mit einer Admin-Rolle verfahren wie mit einem Standardkonto. Prüfen Sie deshalb vor dem Bau, ob Ihre Quelle – HR-System, Austrittsformular, IT-Ticket – zwischen den drei Stufen unterscheidet.

Der technische Aufbau für Stufe 1

1. Auslöser

Wie beim Onboarding ist ein Webhook- oder ein Schedule-Trigger der naheliegende Start: ein Austrittsdatum aus dem HR-System, oder ein Formular, das die Personalabteilung am letzten Arbeitstag ausfüllt. Wichtig ist, dass nur Stufe-1-Felder ankommen – ein Austrittsdatensatz, der still auch eine Admin-Rolle mitträgt, zieht den Workflow in Stufe 2, ohne dass das jemand entschieden hat.

2. Konto deaktivieren

Der Microsoft-Entra-ID-Node selbst bietet dafür keinen dokumentierten Schalter: Seine Update-Operation ist laut n8n-Dokumentation ohne Feldliste beschrieben. Dokumentiert ist stattdessen der generische Weg, den auch unser Beitrag zu n8n und Microsoft 365 für fehlende Bausteine beschreibt: ein HTTP-Request-Node sendet eine PATCH-Anfrage an https://graph.microsoft.com/v1.0/users/{id} mit dem Body {"accountEnabled": false} und verwendet dabei dieselbe Microsoft-Zugangsberechtigung, die auch der Entra-ID-Node nutzt – n8n-Dokumentation und Microsoft Graph decken sich hier exakt: Was ein Node nicht abbildet, deckt der HTTP-Request-Node über dieselbe Berechtigung ab, und accountEnabled ist laut Microsoft Graph genau die Eigenschaft, die ein Konto sperrt. Eine Einschränkung gehört direkt dazu: Microsoft führt accountEnabled als sensible Eigenschaft. Weil die n8n-Entra-ID-Zugangsberechtigung laut Dokumentation ausschließlich delegiert läuft – im Namen eines angemeldeten Nutzers, nicht als eigenständige Anwendung –, gilt hier der delegierte Fall aus Microsofts eigener Unterscheidung: Die Person, deren Microsoft-Konto n8n für diesen Workflow verwendet, muss selbst eine der laut Microsoft Graph zugelassenen Administratorrollen tragen. Laut der Tabelle „Who can perform sensitive actions” reicht für ein Standardkonto als Zielkonto (Stufe 1) breit eine Rolle wie User Administrator; für ein hoch privilegiertes Zielkonto (etwa Global Administrator oder Privileged Authentication Administrator selbst, Stufe 2 unten) bleibt nur noch Privileged Authentication Administrator oder Global Administrator übrig – welche Rolle im Einzelfall reicht, hängt an der genauen Rolle des Zielkontos und ist vor dem Bau in der Tabelle nachzuschlagen. Ohne eine passende Rolle schlägt die Anfrage fehl, auch wenn der n8n-Verbindungstest zuvor grün war.

3. Sitzungen widerrufen

Deaktivieren reicht nicht, um eine laufende Anmeldung zu beenden: Laut Microsoft Graph invalidiert erst ein separater Aufruf – POST /users/{id}/revokeSignInSessions – alle ausgestellten Refresh-Tokens und Sitzungs-Cookies der Person. Ein zweiter HTTP-Request-Node mit derselben Zugangsberechtigung erledigt das im selben Workflow, direkt im Anschluss an den Deaktivieren-Schritt.

4. Lizenz entziehen

Auch dafür gibt es keinen eigenen Baustein im Entra-ID-Node. Microsoft Graph bietet die Funktion assignLicense: POST /users/{id}/assignLicense mit einem leeren addLicenses-Feld und den zu entfernenden Lizenz-IDs unter removeLicenses. Ein dritter HTTP-Request-Node ruft das auf – der explizite, dokumentierte Weg, eine Lizenz gezielt zu entziehen (Abgrenzung zum bloßen Löschen des Kontos: siehe Abschnitt unten). Auch hier gilt dieselbe Rollen-Falle wie bei Schritt 2, nur mit einer anderen Rollenliste: Microsoft Graph verlangt für assignLicense in delegierten Szenarien ausdrücklich eine der Rollen Directory Writers, License Administrator oder User Administrator – unabhängig davon, welche Rolle für das Deaktivieren bereits geprüft wurde.

5. Aus Gruppen entfernen

Für das Entfernen selbst deckt der Entra-ID-Node ab, was gebraucht wird: Die Ressource User unterstützt laut Dokumentation die Operation Remove from Group – dieselbe Operation, die beim Onboarding in die andere Richtung läuft (Add to Group). Für die Liste der Gruppen selbst fehlt dem Node allerdings ein Baustein: Eine Operation, die die Mitgliedschaften eines Kontos ausliest, führt die Dokumentation nicht. Die Liste kommt stattdessen über einen vierten HTTP-Request-Node: GET /users/{id}/memberOf liefert laut Microsoft Graph die Gruppen, denen das Konto direkt angehört. Ein Schleifen-Schritt über das Ergebnis entfernt die Mitgliedschaften einzeln.

6. Hardware- und IT-Checkliste anstoßen

Für Equipment-Rückgabe, Zugangskarte und ähnliche Positionen gibt es ebenfalls keinen eigenen Node – wie beim Onboarding übernimmt ein Send-Email- oder HTTP-Request-Node, der ein Ticket in Ihrem IT- oder Facility-System anlegt, mit den offenen Positionen aus dem Austrittsdatensatz. Die Checkliste selbst (Laptop, Mobiltelefon, Zugangskarte, Schlüssel) bleibt eine Tabelle oder ein Ticket mit Fälligkeitsdatum, nach demselben Muster wie unser Beitrag zur Fristüberwachung es für Verträge beschreibt.

Löschen statt deaktivieren – was sich dabei wirklich ändert

Der Entra-ID-Node unterstützt neben Update auch die Operation Delete. Das wirkt nach dem endgültigeren Schritt, ist es aber unmittelbar nicht: Laut Microsoft bleibt ein gelöschtes Konto 30 Tage lang in einem Schwebezustand, aus dem es ein Administrator mit der passenden Rolle vollständig wiederherstellen kann – inklusive der Lizenzen, die zum Löschzeitpunkt zugewiesen waren. Erst danach beginnt die automatische endgültige Löschung, die laut Microsoft niemand mehr rückgängig machen kann, auch der Support nicht. Was mit einer Lizenz während dieser 30 Tage im laufenden Betrieb geschieht, dokumentiert Microsoft an dieser Stelle nicht – wer eine Lizenz gezielt und nachvollziehbar entziehen will, nutzt dafür den expliziten removeLicenses-Aufruf, unabhängig davon, ob das Konto zusätzlich gelöscht wird. Ein deaktiviertes statt gelöschtes Konto hat dafür einen anderen Vorteil: Es existiert weiter und lässt sich bei einem Irrtum ohne Wiederherstellungsschritt direkt zurückschalten. Deaktivieren plus Sitzungs-Widerruf plus expliziter Lizenzentzug ist deshalb der Weg, der sofort und nachvollziehbar wirkt; Löschen ist ein separater, späterer Entscheid, kein Ersatz dafür.

Für den Mittelstand heißt das

Der eigentliche Unterschied zwischen Onboarding und Offboarding ist nicht die Technik – es sind dieselben drei, vier Bausteine, nur in die andere Richtung. Der Unterschied ist, dass eine eingerichtete Person, die ihr Konto nicht bekommt, sofort auffällt, während eine ausgeschiedene Person, deren Konto nicht sauber deaktiviert wurde, niemandem auffällt, bis es jemand ausnutzt. Ein Workflow, der nur prüft, ob der Entra-ID-Node fehlerfrei durchläuft, prüft damit nicht, ob er das Richtige tut: Create, Update und Delete laufen alle grün durch, ohne dass eine der drei Eigenschaften, auf die es beim Austritt ankommt, tatsächlich gesetzt wurde. Die Prüfung, die sich lohnt, ist deshalb nicht „Läuft der Workflow durch?”, sondern „Steht accountEnabled danach wirklich auf false, und wurden die Sitzungen tatsächlich widerrufen?” – das lässt sich direkt gegen das Nutzerobjekt in Microsoft Graph nachsehen, unabhängig davon, was der n8n-Verbindungstest meldet.

FAQ

Kann n8n ein Mitarbeiterkonto beim Austritt automatisch deaktivieren?

Nicht über den Microsoft-Entra-ID-Node allein – seine Update-Operation ist laut n8n-Dokumentation ohne Feldliste dokumentiert, ein Deaktivieren-Schalter ist dort nicht ausgewiesen. Dokumentiert ist stattdessen der Weg über den HTTP-Request-Node: eine PATCH-Anfrage an Microsoft Graph mit der Eigenschaft accountEnabled auf false, mit derselben Zugangsberechtigung wie der Entra-ID-Node.

Reicht Deaktivieren, oder muss ich zusätzlich die Sitzungen widerrufen?

Beides gehört zusammen. Microsoft Graph behandelt das Deaktivieren eines Kontos (accountEnabled) und das Beenden bestehender Sitzungen als zwei getrennte, einzeln aufzurufende Funktionen: revokeSignInSessions entzieht laut Dokumentation alle ausgestellten Refresh-Tokens und Sitzungs-Cookies. Ein Workflow, der nur accountEnabled setzt, ruft diese zweite Funktion nicht automatisch mit auf.

Was passiert mit der Lizenz, wenn ich das Konto über den Entra-ID-Node lösche statt es zu deaktivieren?

Die Delete-Operation löst die reguläre Löschung aus. Laut Microsoft bleibt ein gelöschtes Konto 30 Tage in einem Schwebezustand, bevor die endgültige Löschung automatisch beginnt – und bei einer Wiederherstellung innerhalb dieser Frist werden auch die zum Löschzeitpunkt zugewiesenen Lizenzen wiederhergestellt. Was mit der Lizenz während dieser 30 Tage im laufenden Betrieb geschieht, dokumentiert Microsoft an dieser Stelle nicht. Wer eine Lizenz gezielt entziehen will, nutzt dafür den expliziten removeLicenses-Aufruf, unabhängig davon, ob das Konto zusätzlich gelöscht wird.

Welche Zugänge erreicht dieser Workflow nicht?

Alles, was außerhalb von Microsoft Entra ID liegt: geteilte Postfächer und Dienstkonten, deren Passwort die Person kannte, persönliche Zugriffstokens und API-Keys sowie Zugänge zu Werkzeugen, die nicht über die Unternehmensanmeldung laufen. Diese Liste gehört in eine eigene, manuell geprüfte Checkliste – ein Konto-Workflow in Entra ID sieht sie nicht.

Braucht die ausführende n8n-Zugangsberechtigung besondere Rechte für das Deaktivieren?

Ja, und zwar die Person, nicht die Anwendung. accountEnabled zählt laut Microsoft Graph zu den Eigenschaften mit eingeschränkten, sensiblen Aktionen. Weil die n8n-Entra-ID-Zugangsberechtigung delegiert läuft – im Namen eines angemeldeten Nutzers –, muss laut Microsofts eigener Unterscheidung zwischen delegierten und App-only-Szenarien die Person, deren Konto n8n dafür verwendet, selbst eine zugelassene Administratorrolle tragen. Für ein Standardkonto als Zielkonto reicht dafür laut Microsofts Tabelle „Who can perform sensitive actions“ breit eine Rolle wie User Administrator; für ein hoch privilegiertes Zielkonto bleibt nur noch Privileged Authentication Administrator oder Global Administrator übrig – welche Rolle im Einzelfall reicht, steht in der Tabelle. Ohne passende Rolle schlägt die PATCH-Anfrage fehl, unabhängig davon, ob der Verbindungstest zuvor grün war.