Was User Provisioning Automation für Active-Directory-Teams bedeutet
User Provisioning Automation bezeichnet die automatisierte Erstellung, Änderung und Deaktivierung von Benutzerkonten und Zugriffsrechten auf Basis definierter Daten – per Skript oder Workflow statt durch manuelle Klicks in Administrationskonsolen. Die drei Phasen heißen Joiner, Mover und Leaver: Eintritt, Rollenwechsel und Austritt. Zusammen bilden sie den Benutzerlebenszyklus.
Überlege, wie viel Aufwand ein neuer Mitarbeitender heute verursacht: ein oft unvollständiges HR-Ticket, die manuelle Auswahl der richtigen Organisationseinheit (OU) in Active Directory, kopierte Gruppenmitgliedschaften eines Kollegen, Postfach, Lizenz, persönliches Laufwerk und Willkommens-E-Mail. Zwölf bis zwanzig Klicks in vier Konsolen – und jeder Administrator macht es etwas anders. Dazu kommen Abteilungswechsel und Austritte, für die oft gar kein Ticket erstellt wird.
Ziel ist ein einheitlicher Prozess mit drei Einstiegspunkten. Jeder Durchlauf beginnt mit validierten Daten, wendet dieselben Regeln an, nutzt eine Identität mit genau den erforderlichen Rechten und protokolliert, wer was angefordert hat. Dieser Beitrag behandelt die drei Phasen, die möglichen Automatisierungsansätze und die häufig übersehene Frage: Wer startet den Prozess, wenn HR und Teamleitungen keine Administratorrechte besitzen? Die kurze Antwort lautet: eine Self-Service-Ebene wie das au2mator Self-Service Portal vor den bereits vorhandenen Skripten. Die ausführliche Antwort folgt.
Joiner: Onboarding mit einer Anfrage statt zwölf Tickets
Automatisiertes Onboarding beginnt mit einem klar definierten Datenmodell. Lege fest, welche Angaben die Anfrage enthalten muss (Name, Abteilung, Position, Führungskraft, Startdatum, Standort) und welche Werte sich aus Regeln ableiten lassen: etwa die OU aus dem Standort, Gruppen aus Abteilung und Position, die Lizenz aus der Rolle sowie Anzeigename und User Principal Name (UPN) aus einer Namenskonvention. Je weniger Freitextfelder, desto weniger Tickets wegen falscher Gruppenzuordnungen.
Das Skript muss nicht kompliziert sein. New-ADUser auf Microsoft Learn erstellt das Konto mit allen Attributen, Add-ADGroupMember weist Gruppen zu, Exchange- und Microsoft-Graph-Cmdlets richten Postfach und Lizenz ein, und einige zusätzliche Zeilen erzeugen das Benutzerverzeichnis. Aus einem Hilfsskript wird eine echte Onboarding-Automatisierung, wenn der umgebende Workflow vorhandene Konten prüft, jeden Schritt protokolliert, die Führungskraft informiert und ein verständliches Ergebnis zurückgibt.
Ein Detail zahlt sich später aus: Speichere die Anfrageparameter beim Benutzerkonto, damit der Leaver-Prozess rückgängig machen kann, was beim Eintritt eingerichtet wurde. In au2mator werden die Parameter jeder Anfrage ohnehin gespeichert.
Mover: die Phase, die viele Teams übersehen
Für neue Mitarbeitende gibt es ein Ticket, weil sie ohne Benutzerkonto nicht arbeiten können. Bei Austritten wird häufig ein Ticket angelegt, weil HR den Vorgang dokumentiert. Bei internen Wechseln kommt dagegen bestenfalls eine E-Mail: „Anna arbeitet jetzt im Vertrieb.“ Das Konto behält die Gruppen aus der Finanzabteilung und bekommt die Vertriebsgruppen dazu. Nach drei Wechseln besitzt Anna womöglich Zugriffe auf die halbe Organisation.
Der Mover-Prozess nutzt dieselbe Automatisierungslogik, aber mit anderen Eingaben: dem Benutzer und den neuen Stammdaten. Er berechnet die Zielgruppen aus Abteilung und Position, vergleicht sie mit den aktuellen Mitgliedschaften, entfernt überholte und ergänzt fehlende Berechtigungen. Anschließend werden Führungskraft, Position und Lizenz aktualisiert sowie beide Führungskräfte informiert.
Wenn du nach dem Onboarding nur eine weitere Phase automatisierst, wähle diese. Hier entsteht schleichend die Ansammlung unnötiger Berechtigungen (Permission Creep).
Leaver: Offboarding, das tatsächlich abgeschlossen wird
Manuelles Offboarding folgt oft einem bekannten Muster: Am letzten Arbeitstag wird das Konto deaktiviert, alles Weitere passiert „später“. Verwaiste Postfächer behalten ihre Lizenzen, und externe Mitarbeitende haben Monate nach ihrem Austritt noch Gastkonten.
Ein automatisierter Leaver-Prozess arbeitet nach einem festen Zeitplan. Am letzten Arbeitstag deaktiviert er das Konto, setzt das Passwort zurück, widerruft Sitzungen in Entra ID, entfernt Gruppenmitgliedschaften, verschiebt das Konto in eine Austritts-OU und richtet eine E-Mail-Weiterleitung an die Führungskraft ein. Nach der Übergabephase – beispielsweise 30 Tagen – wird das Postfach in ein freigegebenes Postfach umgewandelt, die Lizenz entfernt, OneDrive übergeben und das persönliche Laufwerk gesichert und gelöscht. Nach Ablauf der Aufbewahrungsfrist wird das Konto gelöscht. Jeder Schritt läuft geplant anhand des gespeicherten Austrittsdatums, auch wenn sich niemand mehr aktiv darum kümmert.
Derselbe Ablauf kann mit einem zukünftigen Datum geplante Austritte und Vertragsenden abdecken. Eines kann er allerdings nicht ersetzen: den Auslöser. Jemand muss den Austritt melden – und diese Person arbeitet meist in HR, nicht in der IT. Genau hier ersetzt eine „Leaver“-Anfrage in au2mator das klassische Ticket.
Vier Wege zur User Provisioning Automation
Viele Vergleiche von User-Provisioning-Software listen zahlreiche Produkte auf und übersehen dabei die Lösungen, die bereits im Unternehmen vorhanden sind. Grundsätzlich gibt es vier Ansätze. Welcher am besten passt, hängt von Umfang, Lizenzen und dem führenden Quellsystem für Personaldaten ab.
| Ansatz | Funktionsweise | Voraussetzungen | Geeignet für |
|---|---|---|---|
| Eigene Skripte | PowerShell, Azure Automation oder System Center Orchestrator – die drei von au2mator unterstützten Engines – mit parametrisierten Runbooks für Joiner, Mover und Leaver | Skriptkenntnisse, Hybrid Runbook Worker für lokales AD, ein Dienstkonto pro Aufgabe | Hybride AD-Umgebungen, die volle Kontrolle über Regeln und Attribute behalten möchten |
| Microsoft-Entra-Lebenszyklusfunktionen | HR-gesteuerte Bereitstellung übernimmt Benutzer aus Workday, SuccessFactors oder einer API-Quelle; Lifecycle Workflows führen Joiner- und Leaver-Aufgaben für Entra-ID-Konten aus | Entra ID Governance oder Entra Suite, unterstütztes HR-System bzw. API-Quelle sowie Eintritts- und Austrittsdaten im Verzeichnis | Cloudorientierte Umgebungen mit angebundenem HR-System und entsprechender Governance-Lizenz |
| Eigene Skripte mit au2mator Self-Service Portal | Vorhandene Runbooks erhalten ein Webformular: HR und Teamleitungen starten Dienste, ein Dienstkonto führt sie aus und jeder Lauf wird protokolliert | Vorhandene Skripte, au2mator, ein Dienstkonto pro Aufgabe | Hybride AD-Teams, in denen HR und Führungskräfte Prozesse ohne Administratorrechte starten sollen |
| IGA- und User-Provisioning-Suiten | Okta, SailPoint, Saviynt, One Identity, Adaxes oder ADManager Plus bündeln Konnektoren, Richtlinien, Workflows und Zugriffsüberprüfungen auf einer Plattform | Plattformprojekt, Konnektor-Lizenzen und Übertragung vorhandener Regeln in die Richtlinien-Engine | Große, regulierte Organisationen mit vielen Zielsystemen und Audit-Anforderungen |
Zwei Punkte aus der Microsoft-Dokumentation sind für die Entscheidung wichtig: Die HR-gesteuerte Bereitstellung laut Microsoft Learn kann Konten im lokalen Active Directory erstellen, benötigt dafür jedoch ein unterstütztes HR-System oder eine API-basierte Datenquelle als führendes System. Lifecycle Workflows setzen Entra ID Governance oder Entra Suite voraus und arbeiten mit Entra-ID-Konten. Das lokale Konto muss deshalb bereits über Synchronisierung oder einen anderen Provisionierungsweg existieren. Fehlt ein HR-Konnektor oder endet die Lizenzierung bei P1, bleiben eigene Skripte eine wichtige Ausführungsbasis.
Das Skript zur Benutzeranlage bleibt dasselbe – unabhängig davon, ob es eine Suite, ein Zeitplan oder ein Mensch startet. Entscheidend ist, wer den Ablauf auslösen darf und welche Berechtigungen dafür nötig sind.
Die fehlende Ebene: So verbindet au2mator HR mit deinen Provisioning-Skripten
Hier liegt die Lücke vieler Anleitungen: Das Onboarding-Runbook braucht mehrere Werte, die nur HR und die einstellende Führungskraft kennen. Beide können das Runbook aber nicht starten. Also erstellen sie ein Ticket, ein Administrator überträgt die Angaben in die Parameter und die Automatisierung spart zwar Klicks, nicht aber Wartezeit. Bei internen Wechseln und Austritten ist das Problem größer, weil teilweise gar kein Ticket angelegt wird.
Das au2mator Self-Service Portal schließt diese Lücke – ohne eine eigene Automatisierungs-Engine einzuführen. Deine Dienste bleiben PowerShell-Skripte, Azure-Automation-Runbooks oder Orchestrator-Runbooks. Du behältst die bestehende Logik und ergänzt ein Formular. HR öffnet das Portal und findet etwa den Dienst „Neuer Mitarbeiter“ mit geprüften Eingabefeldern und Auswahllisten statt kritischer Freitexte. Falls nötig, genehmigt die Führungskraft den Vorgang mit einem Klick. Danach führt ein Dienstkonto mit genau den notwendigen Rechten das Skript aus. Die Anfrage wird mit anfordernder Person, Parametern, Genehmigung und Ergebnis protokolliert. HR braucht keine Verzeichnisrechte, und Administratoren müssen keine Werte mehr aus Tickets übertragen.
So sieht ein Onboarding-Dienst in au2mator aus
Der Dienst ist dein vorhandenes Onboarding-Skript, das einmalig mit seinen Parametern in au2mator registriert wird. Das Formular macht aus jedem Parameter ein Feld; Abteilung, Führungskraft und Standort können als Auswahllisten aus Active Directory kommen. Berechtigungen bestimmen, wer welchen Dienst sieht: HR etwa „Neuer Mitarbeiter“, Teamleitungen „Abteilung wechseln“ – niemand benötigt eine Konsole. Genehmigungen sind je Dienst optional und können durch Führungskräfte oder Gruppenverantwortliche erfolgen. Zur Ausführung startet au2mator das Skript über PowerShell, Azure Automation oder System Center Orchestrator mit einem Dienstkonto. Am Skript selbst muss nichts geändert werden; Ergebnisse lassen sich an dein Ticketsystem zurückgeben. Das Audit-Protokoll speichert Antragsteller, Parameter, Genehmigung und Ergebnis. Das Muster funktioniert genauso für Mover-Anfragen aus den Fachabteilungen und Leaver-Anfragen aus HR. Unser Beitrag über Active-Directory-Delegation beschreibt denselben Grundsatz für Helpdesk-Aufgaben: Nicht die Berechtigung wird delegiert, sondern die konkrete Aufgabe.
Probiere es mit deinem vorhandenen Onboarding-Skript aus. Die au2mator Community Edition lässt sich kostenlos herunterladen und installieren. Damit kannst du deine ersten zwei Dienste veröffentlichen, etwa „Neuer Mitarbeiter“ für HR und „Abteilung wechseln“ für Teamleitungen – mit deinem bestehenden PowerShell-, Azure-Automation- oder Orchestrator-System.
In fünf Schritten zum ersten automatisierten Provisioning-Workflow
Prozess dokumentieren. Begleite die Person, die das Onboarding durchführt, und notiere jeden Klick, jede Konsole und jeden benötigten Wert samt Quelle. Daraus entstehen dein Datenmodell und ein Testfall.
In ein Skript überführen. Parameter rein, Ergebnis raus. Das Skript sollte bei wiederholter Ausführung keine unerwünschten Änderungen erzeugen (idempotent), jeden Schritt protokollieren und mit einem Dienstkonto laufen, das Benutzer nur in den vorgesehenen OUs anlegen darf.
Datenmodell festlegen. Entscheide, welche Angaben Antragsteller liefern, welche sich aus Regeln ableiten und welche Active Directory bereitstellt. Jedes automatisch ermittelte statt frei eingegebene Feld verhindert eine weitere Fehlerquelle.
Formular davor setzen. Stelle HR und Teamleitungen einen au2mator-Dienst mit teambezogenen Zugriffsrechten und bei Bedarf Genehmigung bereit. Genau dadurch sinkt die Ticketanzahl: Die Personen mit den nötigen Informationen starten den Prozess selbst.
Messen und erweitern. Beobachte die Dauer pro Onboarding, Tickets je Neueinstellung und monatliche Korrekturen. Wenn der Joiner-Prozess zuverlässig läuft, ergänze Mover- und Leaver-Dienste. So wird aus drei unterschiedlichen Routinen ein einheitliches Benutzerlebenszyklus-Management.
FAQ: User Provisioning Automation
User Provisioning Automation erstellt, verändert und entfernt Benutzerkonten und deren Zugriffsrechte anhand definierter Eingaben per Skript oder Workflow statt durch manuelle Konsolenarbeit. Sie umfasst den gesamten Lebenszyklus – Onboarding (Joiner), Rollenwechsel (Mover) und Offboarding (Leaver) – mit einheitlichen Regeln, ausführendem Dienstkonto und Protokollierung jedes Durchlaufs.
Joiner, Mover und Leaver sind die drei Ereignisse im Benutzerlebenszyklus: Eine Person tritt ein und braucht ein Konto samt Berechtigungen, wechselt die Rolle und benötigt andere Zugriffe oder verlässt das Unternehmen und muss zeitgesteuert alle Zugriffe verlieren. Ein Joiner-Mover-Leaver-Prozess definiert die Schritte und Verantwortlichen für jedes Ereignis.
Ja. Wenn HR keine Daten direkt in einen Provisioning-Dienst übertragen kann, kann die Personalabteilung die Anfrage selbst starten. Ein Formular in einem Self-Service-Portal wie au2mator ersetzt die HR-Schnittstelle; im Hintergrund laufen dieselben Skripte. Eine HR-Integration kann später ergänzt werden.
Nicht unbedingt. Lifecycle Workflows und HR-gesteuerte Bereitstellung erfordern entsprechende Entra-ID-Governance- oder Entra-Suite-Lizenzen und eine unterstützte HR-Datenquelle; IGA-Suiten bedeuten meist ein eigenes Plattformprojekt. au2mator nutzt die bereits vorhandene PowerShell-, Azure-Automation- oder Orchestrator-Umgebung und kann damit Joiner, Mover und Leaver in hybriden Active-Directory-Umgebungen abbilden.
Am letzten Arbeitstag sollten das Konto deaktiviert, das Passwort zurückgesetzt, Sitzungen widerrufen, Gruppenmitgliedschaften entfernt, das Konto in eine Austritts-OU verschoben und E-Mails weitergeleitet werden. Nach der Übergabe folgen die Umwandlung in ein freigegebenes Postfach, die Lizenzentfernung, OneDrive-Übergabe sowie Sicherung und Löschung des persönlichen Laufwerks. Nach Ablauf der Aufbewahrungsfrist wird das Konto gelöscht. Alle Schritte orientieren sich am gespeicherten Austrittsdatum.
Über ein Self-Service-Portal wie au2mator. HR füllt ein Formular mit validierten Feldern aus, bei Bedarf genehmigt die Führungskraft, und ein Dienstkonto mit begrenzten Rechten führt das Provisioning-Skript aus. HR erhält keine Active-Directory-Administratorrechte; jede Anfrage wird mit Antragsteller, Parametern und Ergebnis protokolliert.
Fazit: Ein Prozess, drei Phasen, keine Administratorrechte für Antragsteller
User Provisioning Automation ist keine Produktkategorie, für die du zwingend eine neue Suite kaufen musst. Es ist ein Prozess mit drei Einstiegspunkten: definierten Eingaben, einem ausführenden Skript, einem Dienstkonto und nachvollziehbaren Protokollen. Beim Onboarding lohnt sich der Einstieg, weil dort bereits Tickets entstehen. Den größten zusätzlichen Nutzen bieten häufig Mover und Leaver, weil diese Änderungen sonst untergehen. au2mator ergänzt die Ebene, über die HR und Teamleitungen getestete Runbooks selbst starten können – ohne Verzeichnisrechte zu erhalten.
Wenn du deine Onboarding-Schritte auf diesen Ablauf übertragen und herausfinden möchtest, welche bestehenden Skripte sich als Dienste anbieten, vereinbare ein 30-minütiges Gespräch mit Michael Seidl, Microsoft MVP und Gründer von au2mator. Bring am besten die Schritte deines letzten Onboardings mit.
Bereit für das 30-minütige Gespräch? Bring deine aktuelle Onboarding-Checkliste mit und finde heraus, welche Skripte sich zuerst in Joiner-, Mover- und Leaver-Dienste umwandeln lassen.
Gespräch vereinbaren oder die kostenlose Community Edition herunterladen
