Unabhängig davon, ob ein Unternehmen seine IT noch fest lokal verankert hat oder sich bereits auf dem Weg in die Cloud befindet, sind spätestens seit der Corona-Pandemie die meisten Verzeichnisdienste hybrid ausgelegt. Das klassische Active Directory (AD) stellt den primären Identitätsspeicher dar und die Benutzer, Gruppen und immer häufiger Computer-Accounts werden zu Entra ID (vormals Azure AD) oder anderen cloudbasierten Verzeichnissen synchronisiert, um nahtlosen Zugriff auf Anwendungen in der jeweiligen Cloud zu ermöglichen. Das Paradebeispiel hierfür ist Microsoft Teams, das viele Unternehmen in der Pandemie notfallmäßig einführen mussten. Doch auch weitere Dienste wie VPN, Microsoft Dynamics 365, Sales-Force oder Box funktionieren am besten mit einer Cloudidentität.

Die Kopplung des On-premises-Teils der hybriden Identität mit seinem Cloudpendant kann unterschiedlich eng ausfallen. Einige Organisationen möchten zwar eine Onlineidentität bereitstellen, den Authentifizierungsvorgang jedoch komplett vor Ort behalten, und setzen auf eine Pass-Through-Authentication (PTA) oder auf lokal installierte Instanzen der Active Directory Federation Services (ADFS). Andere synchronisieren das Passwort-Hash in die Cloud (PHS) oder machen sogar den Cloudaccount mittels Passwort-Rückschreiben führend. Dies ermöglicht weitreichendere Kennwortprüfungen als die im Active Directory mögliche Komplexitätsbedingung und stellt den Nutzern auf eine einfache Art und Weise ein Self Service Password Reset (SSPR) zur Verfügung. Mittels Cloud Trust ist sogar Kerberos-Authentifizierung eines Cloudaccounts gegenüber lokalen, an Active Directory angebundenen Ressourcen möglich.

Alle Spielarten der hybriden Identität sind relativ einfach einzurichten und die Anbieter stellen sowohl technische Hilfsmittel als auch sehr gute Anleitungen dafür bereit. Microsoft hat ein besonderes Interesse an einer möglichst schnellen und schmerzlosen Migration von Identitäten in die eigene Cloud, sieht doch die neue "Privileged Access Strategy" [1] die Cloud als die "Source of Security" vor. Allerdings offenbaren die erfolgreichen Cyberangriffe der letzten Jahre allzu deutlich auch die Schwächen des Konzeptes. Zum einen werden in einer hybriden Identitätslandschaft beide Komponenten – on premises und in der Cloud – benötigt, um den reibungslosen Betrieb aller Anwendungen zu ermöglichen. Zum anderen entstehen durch die Verzahnung der "Legacy-Identität" mit der "modernen" völlig neue Angriffspfade, die die Eigenarten und die funktionalen Schwächen beider Seiten ausnutzen.

Ein hybrides Identitätssystem lässt sich auf vielerlei Arten angreifen und ganz oder teilweise außer Gefecht setzen. Ebenso unterschiedlich sind die Maßnahmen, die Sie ergreifen müssen, um das System wieder einsatzfähig zu bekommen.

Ein klassisches Angriffsszenario konzentriert sich auf den lokalen Teil der Organisation. Hier bringt der Angreifer das Active Directory meist vollständig unter seine Kontrolle, um es letztendlich zu zerstören. Dies versetzt ihn in die Lage, den Cloudteil ebenfalls zu attackieren, denn durch die Übernahme des herkömmlichen AD erlangt er auch die Kontrolle über Azure AD Connect beziehungsweise die Cloud-Sync-Agenten und kann sich auf diesem Wege in die Cloud ausbreiten. Stellt er bei seiner Erkundung jedoch fest, dass Clouddienste lediglich rudimentär im Einsatz sind, beispielsweise nur für die Videotelefonie über Teams, wird er häufig keine Zeit für die Kompromittierung dieser Dienste verschwenden und lediglich die vor Ort betriebenen Anwendungen und Daten verschlüsseln oder zerstören. Ihr Cloudmandant bleibt also möglicherweise weitestgehend verschont.

Allerdings sind Sie hier mit einer anderen Herausforderung konfrontiert: Da das AD im Hybridverbund der führende Identitätsspeicher ist, sind Benutzer und Gruppen in der Cloud zwar vorhanden, dort jedoch nicht verwaltbar. Haben Sie Password Hash Sync (PHS) aktiviert, können sich die Nutzer sogar mit dem letzten bekannten Kennwort an Clouddiensten anmelden. Sie können das Kennwort jedoch nicht ändern, falls nicht auch das Kennwort-Rückschreiben und/oder SSPR aktiviert wurde. Setzen Sie hingegen fest auf PTA oder ADFS, sind Ihre Clouduser nicht mehr anmeldefähig, da die primären Authentifizierungssysteme nicht mehr zur Verfügung stehen. Daher empfehlen sowohl Microsoft als auch die meisten Experten, PHS zumindest als zusätzliches Authentifizierungsverfahren zu aktivieren. Die häufig zitierte Angst, dass Passwörter in die Cloud synchronisiert werden, ist dabei unbegründet, denn das über 1000-fache Hashen macht die Rekonstruktion des Klartextkennworts in begrenzter Zeit selbst bei relativ schwachen Kennwörtern unwirtschaftlich.

Es sind allerdings Angriffe bekannt, wo die Hacker als letzte Amtshandlung die Kennwörter aller synchronisierten User zurücksetzen, bevor sie das Active Directory und Azure AD Connect zerstören. Die Daten in den Cloudanwendungen sind zwar noch intakt, der Zugriff darauf jedoch stark eingeschränkt beziehungsweise vorerst gar nicht möglich.

In anderen, komplexeren Szenarien dringt der Angreifer zuerst durch beispielsweise Phishing oder Manipulation der MFA-Verfahren in die Cloud ein und stellt erst dann fest, dass beispielsweise ein von ihm gekapertes synchronisiertes AD-Konto über weitreichende Rechte verfügt. Auf dem Wege kann er sich eine Identität verschaffen, die ihm erlaubt, den Cloudmandanten ebenfalls zu kompromittieren oder zumindest Daten wie E-Mails, Dokumente oder Chatverläufe aus Cloudanwendungen zu entwenden, um damit später weitere Nutzer zu phishen (CEO Fraud) oder dem Unternehmen einen Imageschaden anzudrohen und so Geld abzupressen.

In allen Fällen müssen Sie, während Sie die On-premises-Infrastruktur wiederherstellen, dafür sorgen, dass Ihre Clouddienste dem Angreifer kein Einfallstor mehr bieten, bevor Sie die beiden Teile der hybriden Umgebung wieder miteinander verknüpfen.

Obwohl zum Redaktionsschluss die PowerShell-Module "MSOnline" und "AzureAD" noch verfügbar und größtenteils unterstützt sind, steht das Datum für die Abschaltung des Dienste-Endpunkts, auf den sich diese Module beziehen, bereits fest. Es sind sogar schon die ersten Funktionen abgeschaltet, auf die Sie bei einer Internetrecherche zu diesem Thema viele Hinweise finden. Daher konzentrieren wir uns in diesem Artikel auf die Cmdlets aus der Microsoft-Graph-Suite [2], die zukünftig die einzige vom Hersteller supportete PowerShell-Schnittstelle zu M365 und insbesondere zu Entra ID darstellen sollen.

Die Graph-Module bringen eine extrem große Anzahl von Cmdlets mit. Sie sollten daher nach Möglichkeit PowerShell 7 verwenden, um mit der Graph-PowerShell zu arbeiten. Selbst dort dauert der Import des gesamten Graph-Moduls inklusive aller Abhängigkeiten mehrere Minuten und lässt den RAM-Verbrauch der PowerShell-Umgebung auf 2 bis 5 GByte ansteigen. Wenn Sie bereits Erfahrung mit Graph haben, sollten Sie daher gezielt nur die Module laden, die Sie benötigen. Für grundlegende Entra-ID-Aufgaben sind beispielsweise lediglich zwei Submodule erforderlich, die Sie zügig mit

laden. Sind Sie auf PowerShell 5.1 angewiesen und wollen viele Graph-Module oder gar die gesamte Suite laden, müssen Sie in jedem Fall die Anzahl innerhalb der Sitzung verfügbaren Funktionen von dem Standardwert "4096" auf einen höheren Wert, etwa auf das Maximum von "32.768" setzen ($MaximumFunctionCount = 32768).

Der Rahmen dieses Artikels erlaubt keine umfassende Anleitung dafür, wie Sie die kompromittierten Dienste wieder unter Ihre Kontrolle bringen. Allerdings ist das Verfahren, das Sie dafür verwenden, für die weiteren Schritte entscheidend. Das Wiederherstellen von On-premises-Diensten nach Zerstörung oder Kompromittierung hat eine lange Geschichte. Für viele Anwendungen – einschließlich Active Directory – existieren spezialisierte Werkzeuge, die das Wiederherstellen zu einem relativ aktuellen Zeitpunkt erlauben. Und dies ohne die Gefahr, die durch den Angreifer eingebrachte Malware wieder zu aktivieren. Steht Ihnen eine solche Möglichkeit nicht zur Verfügung, stehen Sie in den meisten Fällen vor der Wahl:

- Ein mehr oder weniger frisches Backup zu verwenden und der Wiederherstellung (die zwingend in einem isolierten Netzwerk erfolgen muss) eine umfangreiche Analyse folgen zu lassen.

- Auf eine etwas weiter zurückliegende Sicherung zurückzugreifen und zu hoffen, dass diese noch nicht kompromittiert war, und die seit dem Backup erfolgten Änderungen anschließend nachzuarbeiten.

- Den Verzeichnisdienst komplett neu aufzubauen, weil alle Backups durch den Angriff in Mitleidenschaft gezogen sind.

In allen genannten Fällen können Sie relativ sicher sein, dass Sie die wiederaufgebaute AD-Umgebung hinreichend kontrollieren, solange sie vom Internet isoliert bleibt, also auch selbst keine Verbindungen nach außen aufbauen kann.

Der Notfallwiederherstellung der Clouddienste sind deutlich engere Grenzen gesetzt, da der Betreiber nur auf bestimmte Daten Zugriff erlaubt, und dies teilweise auch nur lesend. Hier befassen wir uns mit der Wiederherstellung der hybriden Identität, gehen also davon aus, dass Sie die Anwendungsdaten wie Exchange-Mails, SharePoint-Dokumente, Azure-SQL-Datenbanken und so weiter mit anderen Mitteln gesichert haben und sie wieder in die jeweilige Anwendung einbringen können, sobald die Identität wieder funktioniert.

Die meisten Disaster-Recovery-Szenarien hier fallen in eine der folgenden Kategorien: Im ersten Szenario sind die Cloud-identitäten zwar möglicherweise kompromittiert, jedoch augenscheinlich nicht zerstört, und Sie haben noch Zugriff auf ein Global-Administrator-Account, der aktiv ist und nach wie vor der GA-Rolle zugewiesen ist. Der zweite Fall ist dadurch gekennzeichnet, dass einige Cloudidentitäten zwar zerstört oder zumindest derart verändert sind, dass die Nutzer sich nicht mehr anmelden können – Sie haben jedoch nach wie vor administrativen Zugriff auf den Mandanten. Im dritten Fall haben Sie gar keinen Zugriff mehr auf den Cloudmandanten, wissen also im ersten Moment gar nicht, wie groß die Zerstörung dort ist. Die Nutzer melden jedoch, dass sie sich nicht mehr an Cloud- diensten anmelden können.

Wenn Ihre üblichen Administrator-Accounts (inklusive des Break-Glass-Accounts) nicht mehr funktionieren, sollten Sie Ihre Dokumentation nach Anwendungen durchforsten, deren Identitäten möglicherweise über genug Berechtigungen verfügen, um einen neuen Administrator zu erzeugen oder das Kennwort eines bestehenden zurückzusetzen. Finden Sie eine solche Anwendung, kann sie Ihre beste Chance sein, die Kontrolle über Ihren Mandanten wiederzuerlangen. Gleichzeitig haben Sie vermutlich den Weg gefunden, über den der Angreifer Ihren Mandanten übernehmen konnte. Hier besteht also dringender Handlungsbedarf, denn diesen Angriffspfad müssen Sie unbedingt wieder schließen, bevor Sie mit der Wiederherstellung der Funktionalität fortfahren.

Sind alle administrativen Zugänge verloren, hilft nur eine Supportanfrage mit höchster Priorität bei Microsoft. Seien Sie darauf vorbereitet, die Eigentümerschaft des Tenants mithilfe von Dokumenten wie Rechnungen oder Zahlungsbelege nachweisen zu müssen und nicht nur beispielsweise durch die Fähigkeit, DNS-Records in benutzerdefinierten Domains zu erzeugen, was für deren Registrierung ausreichend war. Sie sind deshalb auf die Unterstützung Ihrer Geschäftsleitung oder der kaufmännischen Abteilung angewiesen – deren Handlungsfähigkeit durch den Angriff stark eingeschränkt ist und deren Nerven blank liegen. Es lohnt sich daher, zumindest einen Teil dieser Unterlagen in Papierform in Ihre Notfallmappe aufzunehmen.

Manchmal haben die angegriffenen Organisationen Glück und deren Cloudidentität bleibt mehr oder weniger verschont. Stehen Sie vor einer solchen Situation, und haben Sie vielleicht sogar ein aktuelles sauberes Backup Ihres lokalen AD, sind Sie unter Umständen mit einem blauen Auge davongekommen. Entfernen Sie das alte Synchronisierungskonto aus dem Entra-ID-Verzeichnis, denn sein Kennwort könnte kompromittiert sein. Bauen Sie die Azure-AD-Connect-Synchronisation wieder auf, erlangen Sie so zumindest wieder die Kontrolle über die Aktivierung und die Kennwörter Ihrer Identitäten. Hatten Sie ursprünglich PTA im Einsatz, funktioniert dieses ebenfalls, sobald Sie es einrichten. Die Wiederherstellung von ADFS, falls dies Ihre vorherige Authentifizierungsmethode war, ist schon deutlich aufwendiger.

In einer Situation hingegen, in der Sie den Zugriff auf die Clouddienste dringend benötigen, ein Restore der On-premises-Infrastruktur jedoch Zeit in Anspruch nimmt, müssen Sie Ihr IT-Team zumindest in die Lage versetzen, Cloudidentitäten vollständig zu kontrollieren. Dafür ist es allerdings notwendig, die Verknüpfung zu den On-premises-Diensten zunächst aufzubrechen.

Die Synchronisation schalten Sie mittels Graph-API und der PowerShell ab. Bedenken Sie, dass dies zum Zeitpunkt des Verfassens nur über den Beta-Graph-Endpoint möglich ist. Verbinden Sie sich zum Graph-API mit

Ab hier setzen Sie entweder einen REST-PATCH-Request gegen den Beta Endpoint ab:

oder Sie verwenden das Microsoft-Graph-Beta-Modul, das aber dennoch das Graph-Modul für die Authentifizierung und den Verbindungsaufbau erfordert:

In beiden Fällen kann es laut Microsoft bis zu 72 Stunden dauern, bis der Status der Synchronisierung vollständig auf "Cloud Only" zurückgesetzt ist. In der Praxis vollzieht sich diese Änderung meistens binnen 12 Stunden, erfolgt jedoch auf keinen Fall auch nur annähernd in Echtzeit. Dass der Befehl gegriffen hat, können Sie allerdings bereits nach wenigen Minuten im Portal nachvollziehen, denn der Status von Azure AD Connect beziehungsweise Cloud Sync wechselt sehr schnell auf "noch nie durchgeführt". Falls Password Hash Sync aktiviert war, behalten alle User-Accounts auch nach der Abschaltung der Synchronisierung ihr letztes Kennwort, sodass die User – aber auch der Angreifer – sich nach wie vor anmelden können.

Doch aufgepasst: Verschiedene Portale und Endpunkte ändern den angezeigten Status von Benutzern und Gruppen möglicherweise unterschiedlich schnell von "Synchronisiert" auf "Cloud-Managed". Wenn Ihr Disaster-Recovery-Plan es zulässt, sollten Sie mit weiteren Aktionen warten, bis der Status überall einheitlich dargestellt wird.

Arbeiten Sie mit ADFS, müssen Sie den Authentifizierungstyp aller föderierten Domains von "Federated" auf "Managed" ändern. Dies erledigen Sie über

Und für jede Domain mit dem "AuthenticationType" namens "Federated" gehen Sie wie folgt vor:

Von nun an können und müssen Sie Ihren Entra-ID-Mandanten unabhängig von der lokalen Infrastruktur verwalten. Ist das Active Directory wiederhergestellt, ist es erforderlich, die beiden Verzeichnisse wieder miteinander zu verbinden. Die Vorgehensweise hängt davon ab, ob Sie das AD tatsächlich aus einer Sicherung des angegriffenen AD wiederhergestellt oder mit den bekannten Account-Daten neu aufgebaut haben. Bevor Sie fortfahren, gilt es sicherzustellen, dass das Sicherheitsfeature "Block Hard Match Takeover" deaktiviert ist. Führen Sie dafür den folgenden Befehl aus:

Halten Sie dabei nach "BlockCloudObjectTakeoverThroughHardMatchEnabled" Ausschau. Ist der Wert auf "true" gesetzt, müssen Sie es mit dem entsprechenden PATCH-Request gegen denselben Endpoint deaktivieren, damit das Matching durchgeführt werden kann.

Damit alles optimal funktioniert, ist es natürlich wichtig zu wissen, nach welchem Attribut das Matching ursprünglich konfiguriert war – wohl dem, der seine Azure-AD-Connect-Konfiguration dokumentiert hat. Ist das nicht der Fall, können Sie das Attribut "OnPremisesImmu-tableID" Ihrer Clouduser auslesen und versuchen, es per Skript in eine GUID oder einen String zu konvertieren:

Ist der ausgegebene String klar les- und auswertbar, können Sie versuchen zu erraten, zu welchem Attribut er einen validen Wert darstellt. Oft sind es UPNs oder E-Mail-Adressen, es können aber auch weitere eindeutige Attribute sein. Ist der String eine unlesbare Zeichenfolge, finden Sie vermutlich eine GUID als zweite Zeile. Dies ist die objectGUID des dazugehörigen AD-Objektes. Sander Berkouwer hat in seinem Blog [3] das Matching im Detail beschrieben. In einem anderen Blog-Beitrag [4] geht er auch darauf ein, wie das Matching in einem neuen Forest etabliert werden kann – für den Fall, dass Sie Ihr AD komplett verloren haben und neu aufbauen mussten.

Entra ID speichert einige wichtige Attribute des synchronisierten AD-Users, mit deren Hilfe sowohl eine nachträgliche Zuordnung möglich ist und sich auch das On-premises-Verzeichnis originalgetreu neu aufbauen lässt. Die Eigenschaften tragen alle das Präfix "OnPremises" und schließen die SID, den Distinguished- Name (wovon auch die OU-Struktur ableitbar ist), den sAMAccountName, den UPN und sogar ein komplexes Attribut "OnPremisesExtensionAttributes", das die ExtensionAttributes 1 bis 15 enthält. Weniger lokale Attribute erhalten Sie dagegen für Gruppen, hier fehlen der Distinguished Name und die ExtensionAttributes. Dennoch ist in einer Situation, in der das lokale Verzeichnis unwiederbringlich verloren ist, der Entra-ID-Mandant hingegen unversehrt geblieben ist, die Cloudidentität sehr gut geeignet, um das Active Directory wieder aufzubauen.

Abschließend ein wichtiger Hinweis: Sobald Sie die Synchronisierung wieder eingerichtet haben und Azure AD Connect beziehungsweise Cloud Sync das Matching abgeschlossen hat, hat das lokale AD wieder die Hoheit über das Kennwort, den Aktivierungsstatus und Gruppenmitgliedschaften der Benutzer. Setzen Sie Ihre Nutzer früh genug davon in Kenntnis, sodass sie ihre lokalen Kennwörter ändern können, bevor die Synchronisierung aktiviert wird.

Schwieriger wird es freilich dann, wenn zwischen dem Aufbrechen der Synchronisation und dem Wiederaufbau der hybriden Identität nicht Tage, sondern Wochen vergehen und die beiden Umgebungen sich unabhängig voneinander weiterentwickeln. Ähnlich groß sind die Herausforderungen, wenn der Backupzeitpunkt, auf den Sie im lokalen AD zurückfallen müssen, relativ lange in der Vergangenheit liegt – schlimmstenfalls vor der ursprünglichen Aktivierung der Synchronisierung.

Sind Sie mit einer solchen Situation konfrontiert, hilft es nur, einen kühlen Kopf zu bewahren und sich so viel Zeit für den initialen Abgleich der Informationen in beiden Verzeichnissen zu nehmen wie nötig. Sie müssen erreichen, dass bis zum Wiedereinschalten der Synchronisation sowohl die Benutzerdaten als auch die Matching-Attribute, aber auch Gruppenmitgliedschaften und die oft damit einhergehenden Lizenzzuweisungen in der Cloud genau übereinstimmen. Hier kommen Ihnen die vielen oben beschriebenen Attribute zugute, die Entra ID über die lokalen Objekte speichert.

Sie sollten hier keine Abkürzungen nehmen und keine Annahmen tätigen. Nutzen Sie die vielfältigen Möglichkeiten der PowerShell, um einen Abgleich so präzise wie möglich durchzuführen, die fehlenden Objekte und Bezüge zu erstellen und die Änderungen an Objekt-Metadaten, die seit dem Angriff aufgelaufen sind, im jeweils anderen Verzeichnis nachzuführen.

Die Gefahr eines Cyberangriffs gehört heutzutage für die meisten vernetzten IT-Umgebungen dazu. Welche Auswirkungen eine Attacke auf eine hybride Identitätslandschaft hat, hängt unter anderem davon ab, wie gut Sie auf die verschiedenen Szenarien vorbereitet sind. Wenn Entra ID ein wichtiger Bestandteil Ihrer hybriden Identität ist, müssen Sie sich zwingend mit der Graph-API und ihrer PowerShell-Implementierung beschäftigen. Spielen Sie die in diesem Artikel beschrieben Szenarien am besten einmal in einem Test-AD, gekoppelt an einen Testmandanten, durch. Und denken Sie daran: Das Wiederherstellen der Identität ist zwar ein wichtiger Bestandteil des Disaster Recovery, doch eigentlich ist es nur der erste Schritt in Richtung Normalität und Regelbetrieb.