Zero Trust ist ein sehr wichtiger Aspekt der modernen IT-Welt und der Schutz insbesondere einer hybriden Infrastruktur ist dabei entscheidender denn je. Alles auf den Prüfstand stellen, was gestattet sein soll, in einem Umfeld, in dem erst einmal nichts erlaubt ist. Das fängt an bei der Sicherheit für Rechenzentren und geht hin bis zur Absicherung von Endgeräten der Benutzer.

Irgendwo dazwischen befindet sich ein sehr wichtiger Baustein im Zero-Trust-Puzzle, nämlich "Identity and Access". Eine Strategie für den verantwortungsvollen und zeitgemäßen Umgang mit Identitäten ist wichtiger denn je. Das ist nicht immer einfach in einer Welt, in der jahrzehntelang Verzeichnisdienste Benutzerkonten und alles. was dazugehört, ausschließlich auf Domänencontrollern (DC) speicherten. DCs, die nach wie vor gut behütet hinter Firewalls ihren Dienst verrichten.

Mittlerweile sind wir in der "Public Cloud" angekommen und hybride Setups in Verbindung mit dem Azure Active Directory (AAD) sind nichts Besonderes mehr. Administratoren müssen dabei ein Auge sowohl auf die lokalen Verzeichnisdaten werfen sowie das Azure AD in den Aktionsradius einbeziehen. Das AAD bietet dabei neue Funktionen, von denen Admins im lokalen AD nur träumen können. Das ist alles wunderbar und Microsoft hat seit der Einführung des Azure AD großartige Funktionen bereitgestellt.

Für Administratoren ist es jedoch nicht immer einfach, mit diesem Werkzeugkasten zu arbeiten. Ein großer Teil der Funktionen befindet sich in den Dashboards des AAD und diverse Tools liegen zusätzlich in eigenständigen Bereichen im Azure-Portal, etwa Identity Protection (IdP) oder auch Privileged Identity Management (PIM). Entra [1] vereint diese Funktionen und versteht sich als Werkzeugfamilie, die bisherige Technologien in einem Portal bündelt und mit Neuerungen ergänzt. In diesem Workshop öffnen wir die Werkzeugkiste und schauen uns an, welche Möglichkeiten es gibt, den Lebenszyklus von Benutzerkonten zu automatisieren. Und da "Hybrid" ein wichtiges Thema für Administratoren ist, werfen wir zudem einen Blick auf die Erfordernisse im Zusammenspiel mit der Infrastruktur vor Ort, die einen reibungslosen Ablauf gewährleisten.

Herzstück einer IT-Infrastruktur sind Benutzerkonten und ein wichtiger Aspekt dabei ist das Drumherum, wenn Admins Benutzerkonten initial anlegen oder entfernen. Mitarbeiter kommen neu ins Unternehmen, verlassen es oder nehmen neue Rollen ein. Das verlangt von IT-Verantwortlichen routinemäßige Arbeiten im Verzeichnisdienst, die sich für eine Automatisierung anbieten: Hinzufügen und Entfernen von Benutzern aus Gruppen, Berechtigen, Zuweisen von Lizenzen, Versenden von E-Mails an Manager oder den betroffenen Mitarbeiter, um nur ein paar Möglichkeiten zu nennen. Die Antwort von Microsoft auf diese Routinearbeiten aus der Entra-Familie lautet "Lifecycle Workflows".

Es handelt sich hierbei um eine relativ neue Funktion und der Funktionsradius beschränkt sich derzeit auf "Joiner"- und "Leaver"-Funktionen. Mit anderen Worten, Reaktionen erfolgen, wenn Benutzerkonten zum Azure AD hinzugefügt oder in absehbarer Zeit entfernt werden. In der aktuellen "Public Preview"-Version der Lifecycle Workflows gibt es noch keine "Mover"-Aktionen. Das heißt, derzeit lässt sich noch keine automatische Reaktion gestalten, wenn Personen von Abteilung A nach Abteilung B wechseln. Es dürfte aber wohl nur eine Frage der Zeit sein, bis Microsoft hier nachlegt. Sie finden Lifecycle Workflows im Entra Admin Center unter "Identity Governance".

Ein erster Blick zeigt ein intuitives Dashboard, über das Sie mit wenigen Handgriffen schnell loslegen können. Erst wenn Sie einen tieferen Blick unter die Haube werfen möchten, kommen Sie ohne die gut sortierten Docs-Artikel nicht mehr aus – zum Einstieg sei [2] empfohlen.

Die grundlegende Arbeitsweise bezieht sich ausschließlich auf Benutzerkonten im Azure AD. Lifecycle Workflows liefert keinerlei direkte Connectoren, zum Beispiel für die Active Directory Domain Services oder für andere HR-Dienste wie Workday, die Identitäten in das AAD provisionieren. Das heißt, die notwendigen Auslöser (Trigger) liegen beim AAD-Benutzerkonto. Das ist keine Einschränkung, sondern ein Vorteil, weil die Funktionsvielfalt erhalten bleibt und zum Beispiel vorhandene On-premises-Prozesse rund um das Benutzermanagement bestehen bleiben. Hierzu verfügen Benutzerkonten im Azure AD über zwei Attribute: "EmployeeHireDate" und "EmployeeLeaveDateTime".

Beide werden nicht automatisch mit Inhalten versorgt, dies muss der Administrator in Eigenregie bewerkstelligen, wenn er die Konten anlegt. Das ist wichtig, da die Auslöser für Workflows sich an den Zeitstempeln dieser Attribute orientieren. Besonders in einer hybriden Landschaft, in der Benutzerkonten lokal entstehen, gibt es hier einiges zu beachten. Welche Herausforderungen Sie dabei erwarten, schauen wir uns später an, vorerst bleiben wir im Azure AD bei den Identitäten.

Möchten Sie einen neuen Workflow erstellen, fordert das System Sie auf, aus vordefinierten Vorlagen eine Wahl zu treffen. Es handelt sich dabei um "Joiner"- und "Leaver"-Templates. Eigene Templates werden nicht unterstützt, das dürfte auch zu viel des Guten sein. Außer in einer Testphase ist es wohl eher nicht erforderlich, regelmäßig neue Szenarien zu integrieren, die dies rechtfertigen.

Die beiden "Joiner"-Workflow-Vorlagen decken zweierlei Anforderungen ab: Zum einen Aktionen, die eine festgelegte Zeitspanne lang laufen, bevor ein Mitarbeiter seine Arbeit aufnimmt, während das zweite Template Workflows dient, die unmittelbar starten. Ein Leaver-Prozess ist vielschichtiger und daher bieten sich Ihnen hier vier Vorlagen für das Erstellen der Workflows. Auch die Namen dieser Templates sprechen für sich und lassen darauf schließen, für was sie sich eignen. Bereits in der aktuellen Preview-Version von Entra finden Sie hier eine umfassende Auswahl an Einstellmöglichkeiten für individuelle Workflows.

Nach der Auswahl des Templates definieren Sie allgemeine Parameter. Der Wichtigste dabei dürfte der Trigger sein und dessen Details gestatten aktuell das Festlegen eines Zeitraums in Tagen, bevor oder nachdem der Zeitpunkt eingetreten ist. Ein Bereich (Scope) lässt sich im Assistenten konfigurieren, ist aber optional. Entscheiden Sie sich hier für einen Scope, besteht an dieser Stelle die gleiche Flexibilität, die Sie eventuell von der Administration dynamischer Gruppen kennen.

Das heißt, über Ausdrücke (Expressions) lassen sich Regeln kreieren, die eine Teilmenge an Benutzerkonten liefern. Mehrere logisch verknüpfte Ausdrücke gestatten es, basierend auf den Benutzerattributen, den Kreis der Identitäten für den Workflow einzugrenzen – "Location" oder beispielsweise auch "Department" wären zwei typische Attribute für einen Filter. Hier können Sie aber mit einer Vielzahl von Benutzerinformationen arbeiten und es lassen sich umfangreiche firmeninterne Szenarien abbilden, indem mehrere Workflows für diverse Zielgruppen ihren Dienst verrichten.

Jedes Template kommt mit einer Liste vordefinierter Aufgaben (Tasks) daher. Erweitern Sie hier die Liste durch das Hinzufügen eines weiteren Tasks, wird dieser als zusätzlicher Schritt in der Liste abzuarbeitender Aufgaben hinzugefügt. Dort lässt er sich noch anpassen, je nachdem, um was es sich konkret handelt: Sie möchten eine Willkommens-E-Mail verschicken, ein Benutzerkonto zu einem Zeitpunkt bestimmten Gruppen hinzufügen oder einen Manager darüber informieren, dass ein Benutzerkonto eines neuen Mitarbeiters bereitsteht? In diesem Zusammenhang lässt sich direkt ein TAP (Temporary Access Pass) an den Manager per E-Mail senden, der wiederum kann dem Mitarbeiter dieses einmalige Passwort für eine Erstanmeldung aushändigen. Die Liste der vordefinierten Aufgaben ist überschaubar, dürfte aber die meisten Anforderungen bei den Prozessen für das On- oder Offboarding von Benutzern unterstützen.

Sollten Sie bei den zur Auswahl stehenden Tasks für ihre Anforderung nicht fündig werden, haben Sie die Möglichkeit, eigene zu ergänzen. Hierzu kommt eine "Logic App" ins Spiel und diese wiederum bietet alle erdenklichen Möglichkeiten, die Infrastruktur zu administrieren. Fügen Sie eine "Custom Extension" hinzu, können Sie entweder eine existierende Logic App auswählen oder eine neue erstellen.

Sollten Sie sich für Letzteres entscheiden, bietet es sich an, die "Logic App" an dieser Stelle einzurichten. Das garantiert, dass die App den richtigen Body erhält und alle Parameter berücksichtigt sind. So erhält die Logic App zum Beispiel den Benutzernamen oder auch den Namen des Managers als Parameter. Microsoft hat hier mitgedacht und je nachdem, wie komplex die Logic App am Ende ist, können Sie angeben, was nach Ausführen der Aufgaben geschehen soll: Fortfahren mit dem nächsten Task oder darauf warten, dass dieser abgeschlossen ist.

Wenn Sie die Möglichkeit nutzen möchten, dass Manager einen TAP per E-Mail erhalten und diesen an die Mitarbeiter weitergeben, sollten Sie das in der "TAP Policy" berücksichtigen. Diese finden Sie im AAD-Dashboard im Bereich "Security / Authentication Methods". Standardmäßig ist ein Passcode nämlich nur eine Stunde gültig und das dürfte in diesem Szenario nicht ausreichen. Die maximale "Lifetime" darf 30 Tage betragen, was hinsichtlich der Sicherheit einen vergleichsweise langen Zeitraum darstellt. Hier sollten Sie die optimale Einstellung der Dauer gut überlegen – Microsoft empfiehlt 24 Stunden.

Einige Aufgaben bei den Workflows gestatten es, einem Benutzerkonto Gruppenmitgliedschaften zuzuweisen. Da kannes sinnvoll sein, Benutzer je nach Einsatzgebiet direkt mit Lizenzen auszustatten, die wiederum an Gruppen geheftet sind. Letztendlich ist das eine Frage der Strategie, aber hier ergibt es bestimmt mehr Sinn, über dynamische Gruppen nachzudenken, die diesen Zweck viel eleganter erfüllen. Denn derzeit gibt es keine "Mover"-Workflow-Templates und die Arbeiten, die ein "Joiner"-Vorgang ermöglicht, sind eher statischer und initialer Art. Was wenn ein Benutzer die Abteilung wechselt und andere Lizenzen oder Anwendungen benötigt? Hier sind Sie mit dynamischen Gruppen besser bedient. Vergessen Sie nicht, dass Lifecycle Workflows nur ein Tool aus der Entra-Werkzeugkiste sind. Manchmal ist es besser, bei bestimmten Anforderungen, wie dem Zuweisen von Lizenzen oder Anwendungen, auf ein anderes Toolset, wie in dem Fall auf die dynamischen Gruppen, auszuweichen.

Ein weiterer wichtiger Punkt ist das Attribut "Manager" zu einem Benutzerkonto. Dies ist bei einigen Workflows von Bedeutung, jedoch ist "Manager" kein Pflichtattribut und somit bei einem neuen Benutzerkonto leer, egal wo das Benutzerkonto angelegt wird (lokal oder als Cloud-Only-Konto im AAD). Bevor Sie mit Workflows starten, sollten Sie sicherstellen, dass das "Manager"-Attribut bestückt ist. Erwähnenswert in diesem Zusammenhang ist auch, dass das Benutzerkonto des Managers gleichfalls im Azure AD vorliegt, was je nach Filterung und Setup in der Synchronisation nicht unbedingt der Fall sein muss. Fehlt das Manager-Benutzerkonto, scheitert die Ausführung, wenn im Zuge eines Workflows eine entsprechende Person eine E-Mail erhalten soll.

Fast alle Unternehmen haben Prozesse rund um die Administration von Benutzerkonten. Diese können auf einfachen Excel-Tabellen in Verbindung mit der PowerShell basieren oder sie stützen sich auf komplexe HR-Systeme, die für ein durchgängiges Benutzermanagement sorgen. Egal, wie Sie Benutzerkonten etablieren, liegen diese meist lokal im Active Directory. Doch in Verbindung mit dem Azure AD sehen Sie sich mit den Herausforderungen eines hybriden Setups konfrontiert. Die beiden für die Workflows wichtigen Attribute "EmployeeHireDate" und "EmployeeLeaveDateTime" hängen am Benutzerobjekt in Azure und sind in den AD Domain Services nicht bekannt. Über ein Mapping der Attribute müssen Sie nun dafür sorgen, dass die Benutzerkonten lokal im AD diese Informationen erhalten und diese dann in Richtung AAD synchronisieren.

Microsoft bietet derzeit zwei Technologien an, um in einem hybriden Umfeld die Synchronisation zu gewährleisten: Den lange etablierten "Azure AD Connect Server" und die neue Variante "Azure AD Connect Cloud Sync" mit der Administration im Azure-Portal. Beide Technologien sind unterstützt und Sie müssen dafür sorgen, dass für die beiden Attribute im Azure AD "EmployeeHireDate" und "EmployeeLeaveDateTime" jeweils im lokalen AD eines der Extension-Attribute reserviert wird, in das die Zeitangaben fließen. Über ein Mapping sorgen Sie bei der Synchronisation dafür, dass das AAD-Konto die Informationen erhält und der nachgelagerte Lifecycle Workflow darauf reagieren kann.

Azure AD Connect Cloud Sync ist sehr einfach im Azure AD zu administrieren, hier sind die Attribut-Mappings schnell eingerichtet. Etwas aufwendiger ist der Regeleditor auf dem AAD-Connect-Server, wo Sie Mappings als sogenannte Transformationen umsetzen. Beides ist relativ gut in den Microsoft Docs beschrieben [3] und der Beitrag geht auch darauf ein, in welchem Format das Datum und die Zeit für die Attribute vorliegen müssen. Allerdings wird dort nicht erwähnt, dass der Connect-Server standardmäßig nicht die sogenannten Extension-Attribute synchronisiert. Das müssen Sie bei den "Exported Attributes" im Installationsassistenten des Connect-Servers aktivieren.

Übrigens muss der Lebenszyklus einer Identität nicht im lokalen Active Directory beginnen oder gleich im Azure AD. Es gibt zwischenzeitlich auch die Möglichkeit, über HR-Provisioning aus einem anderen System heraus Identitäten direkt in das AAD zu synchronisieren. Aber auch hierbei müssen Sie die Attribute zuordnen. Microsoft beschreibt am Beispiel von Workday und SAP SuccessFactors, wie IT-Verantwortliche die Mappings in den Systemen konfigurieren. Zusammenfassend lässt sich sagen, dass, egal wie ein Benutzerkonto in das Azure AD gelangt, die AAD-Attribute müssen für die Lifecycle Workflows befüllt sein.

Haben Sie Benutzerkonten ausschließlich in der Cloud, fällt der hybride Aspekt natürlich weg, nicht aber die Administration der beiden Attribute. Im Fall von "EmployeeHireDate" ist das relativ einfach, denn es lässt sich über die PowerShell füllen oder auch direkt in den Eigenschaften eines Benutzerkontos. Letzteres ist übrigens gut geeignet, um Workflows direkt für einen Test auszuführen.

Etwas schwieriger wird es beim Attribut "EmployeeLeaveDateTime", das suchen Sie in den Eigenschaften eines Benutzerkontos im AAD-Dashboard vergebens. Um dieses in Azure mit Inhalt zu versehen, müssen Sie sich der Microsoft Graph-API bedienen [4].

Noch einige andere Aspekte sind zu beachten, wenn Sie Lifecycle Workflows planen. Eine Unterstützung für mehrere Sprachen gibt es beispielsweise bislang nicht. Das ist bestimmt kein gravierender Mangel, aber ein Benutzerkonto verfügt über das Attribut "preferredLanguage" und warum nicht situativ auf die Sprache reagieren und E-Mails in der Landesprache versenden? Die Konfiguration von Conditional Access Policies und den Nutzungsbedingungen handhabt es ähnlich und zeigt entsprechend der Sprache im Browser die passende Seite an.

Etwas, das bei unseren Tests zu diesem Beitrag ebenfalls aufgefallen ist, sind die Bereichsregeln. Bei einem neuen Workflow ist bei der Definition des Scopes eine Regel mit der Expression "Department equals Marketing" definiert. Dies dürfte in den seltensten Fällen gewünscht sein und lässt sich leider in der Entra-Preview nicht einfach entfernen, weil immer eine Expression vorhanden sein muss. Hier können Sie sich helfen, indem Sie zuerst eine neue Expression hinzufügen, zum Beispiel "AccountEnabled equals true" und dann den anderen Ausdruck mit "Department" entfernen.

Lifecycle Workflows führen umfangreiche Schreibvorgänge im Azure AD aus, bis hin zum Entfernen von Benutzerkonten. Dies erfordert ausgiebige Tests, bevor Sie einen Workflow als produktionsreif einstufen. Zwar orientieren sich die Workflows an dem Attribut, das das Datum enthält, zu dem ein Mitarbeiter ausscheidet, aber sorgfältige Planung und Qualitätssicherung sind hier wichtiger denn je.

Der Wirkungsgrad der Automatismen kann hoch sein und hier kann es schnell zu unerwünschten Nebeneffekten kommen. In einem Cloudsetup, also wenn das Management der Benutzer komplett in Azure liegt, ist zu überlegen, ob es nicht sinnvoller ist, ein Benutzerkonto zu deaktivieren, anstatt es zu löschen. Zwar landen gelöschte Konten erst einmal im Papierkorb, aber das ist nur ein Zwischenschritt, denn nach 30 Tagen werden sie endgültig entfernt.

Sie sollten auch die Reihenfolge der Aufgaben gut planen. Besonders unter dem Aspekt, was im Fehlerfall passiert. Dadurch kommt der gesamte Workflow zu einem abrupten Ende und somit hat ein Benutzerkonto im Fehlerfall nur teilweise den Prozess für das Onboarding durchlaufen. In einer verteilten und komplexen Infrastruktur hat der Administrator nicht unbedingt Kenntnis über jeden neuen Benutzer. Häufige Probleme mit den Workflows werden hier schnell zum Ärgernis.

Es gibt zwei Protokolle für die Lifecycle Workflows: Zum einen die Auditlogs, die Änderungen an der Infrastruktur aufzeigen. Hier werden Sie fündig, wenn Sie Grundlegendes suchen. Wer hat was an einem Workflow geändert und andere administrative Aktivitäten. Das zweite Log liefert Details zu einzelnen Workflows. Um diese zu untersuchen, wechseln Sie im Bereich "Activity" zu "Workflow History". Hier sehen Sie, bei welchem Schritt ein Workflow abgebrochen wurde und was der Grund dafür war.

Microsoft hat begonnen, Identity-Werkzeuge aus dem Azure- in das Entra-Portal zu verlagern. Zwar befinden sich bekannte Technologien immer noch zusätzlich dort, aber mit Entra haben die Redmonder auch neue Funktionen etabliert, die genau richtig sind, um den Admin zu entlasten und durch programmierte Automation Fehler zu eliminieren.

Funktional ist jedoch noch Spielraum nach oben: mehrsprachige Benutzerkommunikation, weitere Aufgaben, besseres Fehlerhandling oder Ähnliches. Aber aktuell ist es noch die Public Preview von Microsoft Entra, also noch nicht einmal produktionsreif. Es bleibt spannend abzuwarten, welche Funktionen noch hinzukommen.