Active Directory (AD) ist ein Microsoft-Produkt, das Netzwerkadministratoren bei der Verwaltung von Benutzerberechtigungen innerhalb einer Organisation unterstützt. Es wird auf einem Windows-Server installiert und macht ihn zu einem Domänencontroller, der für die Verwaltung von Unternehmensumgebungen und die Durchführung von Aktionen wie das Speichern aller Benutzerkonten, ihre Passwörter und Berechtigungen sowie die Verwaltung der Benutzerauthentifizierung.
Im Laufe der Zeit bewegt sich die Welt immer mehr in Richtung Cloud-Einführung, und Microsoft hat auch Organisationen dazu gedrängt, auf Cloud-basierte Umgebungen umzusteigen, um rationalisiertere und modernere Identity Management. Die Lösung von Microsoft für Cloud-basierte Domänenumgebungen ist Entra ID. Es erweitert die Funktionen des lokalen AD auf die Cloud und bietet eine robuste Lösung für die Verwaltung von Identitäten und Zugriffen für Cloud-basierte Anwendungen. Um eine nahtlose Integration mit unterstützenden Legacy-Systemen zu ermöglichen, führte Microsoft Entra ID Verbinden. Mit diesem Tool können Organisationen ihre lokalen Active Directory (AD) Umgebung mit Entra ID, wodurch eine „hybride, verbundene Umgebung“ entsteht.
Durch Entra ID Mit Connect können Organisationen Benutzer und Verzeichnisdaten von ihrem lokalen AD mit der Cloud synchronisieren. Dadurch können Benutzer auf Cloud-Dienste zugreifen und dabei dieselben Anmeldeinformationen wie für ihre lokalen Systeme verwenden. Eine interessante Funktion Entra ID Connect unterstützt das Passwort-Writeback, bei dem in der Cloud vorgenommene Passwortänderungen mit dem lokalen AD synchronisiert werden, wodurch eine konsistente Identitätsverwaltung in beiden Umgebungen gewährleistet wird. Dieses Hybridmodell stellt sicher, dass Unternehmen ein einheitliches Identitätssystem aufrechterhalten können, während sie sowohl in Cloud- als auch in lokalen Infrastrukturen arbeiten.
Die Unterschiede im Berechtigungsmanagement zwischen Legacy Active Directory und Entra ID kann zu Sicherheitslücken im Synchronisierungsprozess zwischen den beiden Produkten führen.
Detaillierte Informationen zur Berechtigungsverwaltung
Berechtigungsverwaltung in Active Directory funktioniert so, dass es in jeder Umgebung mehrere standardmäßige privilegierte Sicherheitsgruppen mit erhöhten Berechtigungen zum Vornehmen von Änderungen gibt. Wenn wir einem bestimmten Benutzer diese Berechtigungen erteilen möchten, fügen wir ihn einfach der Gruppe hinzu. Beispielsweise erteilt die Gruppe „Domänenadministrator“ allen Benutzern in ihr Berechtigungen. Eine andere Methode zum Definieren von Berechtigungen für Benutzer oder Gruppen ist die ACL (Access Control List). Diese Liste existiert für jedes Objekt in AD und gibt die Berechtigungen für jede Entität an. Dieser Mechanismus ermöglicht die Zuweisung von Berechtigungen an einen normalen Benutzer zum Vornehmen von Änderungen, sogar an Objekten, die Benutzern mit hochrangigen Berechtigungen gehören, wie z. B. Domänenadministratoren.
Jedoch in Entra ID (früher Azure AD) gibt es standardmäßig keine Sicherheitsgruppen. Stattdessen wird ein RBAC-Mechanismus (Role-Based Access Control) verwendet. Das bedeutet, dass es viele Arten von Rollen gibt, die jeweils unterschiedliche Benutzerberechtigungen definieren. Sie können einer Gruppe auch eine Rolle zuweisen, und alle Mitglieder dieser Gruppe erben dieselben Berechtigungen. Diese Option umfasst jedoch keine standardmäßig definierten Gruppen, wie Active Directory.
Was ist also der Unterschied zwischen den beiden Mechanismen? In Entra wird ein Änderungsschutz bereitgestellt, wenn ein Benutzer privilegierte Berechtigungen durch Rollen- oder Gruppenzuweisung erhält. Im Legacy-AD haben wir festgestellt, dass nicht alle sensiblen Gruppen vor Änderungen geschützt sind. Tatsächlich werden bestimmte sensible Gruppen als schwach behandelt, wenn es um Entra ID Synchronisierung verbinden.
Wenn ein Benutzer in Entra eine privilegierte Rolle erhält, wird ihm automatisch Änderungsschutz gewährt. Nur ein Benutzer mit höheren Berechtigungen oder einer gleichwertigen Rolle kann Änderungen vornehmen, was jedem anderen Benutzer mit einer niedrigeren Rolle verwehrt bleibt. Das bedeutet, dass der Benutzer kein Mitglied einer Sicherheitsgruppe sein muss, um geschützt zu sein – anders als in AD reicht es aus, ihm einfach eine privilegierte Rolle zuzuweisen, um ihm ein gewisses Maß an Schutz zu bieten.
Zum Beispiel in der Hierarchie der Administratorrollen . Entra ID, hat das Kennwort-Administrator Rolle gewährt Benutzern die Möglichkeit, Passwörter zurückzusetzen. Obwohl diese Rolle als Administrator eingestuft wird, gilt sie als eine der niedrigsten in der Administratorhierarchie. Daher können Passwortadministratoren Passwörter nur für regelmäßige Benutzer oder Benutzer, die dieselbe Administratorrolle innehaben. Sie haben nicht die Berechtigung, Passwörter für Benutzer auf höherer Ebene zurückzusetzen. Administratorrollen, wie globale Administratoren oder andere privilegierten Konten, wodurch eine klare Sicherheitsgrenze zwischen verschiedenen Administratorrollen aufrechterhalten wird. Diese hierarchische Struktur stellt sicher, dass sensiblere Rollen vor unbefugten Kennwortänderungen geschützt sind.
Wie erfolgt die Synchronisierung?
Der Synchronisierungsprozess zwischen lokalem AD und Entra ID kann in zwei Hauptteile unterteilt werden:
- Synchronisieren von Identitäten von On-Premises zu Entra ID
- Kennwortrückschreiben von Entra ID zu On-Premises
Teil 1: Synchronisieren von On-Premises zu Entra ID
Entra ID Connect erstellt eine Dienstkonto Benutzer namens MSOL nach den ersten 8 Bytes der Installationskennung. Dieser Benutzer verfügt über leistungsstarke Funktionen, die denen eines Domänencontrollers entsprechen können. Die Berechtigung „Alle Verzeichnisänderungen replizieren“ ermöglicht es dem Benutzer, eine DC-Synchronisierung durchzuführen und alle Attribute des Objekts einschließlich der Anmeldeinformationen des Clients zu extrahieren – mit anderen Worten seinen NT-Hash. Aufgrund der umfassenden Berechtigungen, die diesem Benutzer im gesamten Verzeichnis gewährt wurden, kann er auf Informationen über Benutzer in geschützten Gruppen zugreifen und diese lesen. Dies liegt daran, dass die bereitgestellten Berechtigungen es dem Benutzer ermöglichen, mit Domänencontroller-ähnlichen Berechtigungen zu arbeiten. Selbst wenn der Benutzer nicht explizit in der ACL einer Gruppe aufgeführt ist, behält er daher die Möglichkeit, den NT-Hash der Gruppenmitglieder abzurufen. Diese Berechtigung ermöglicht die lokale Seite des Synchronisierungsprozesses und wird mithilfe des Remoteprotokolls des Verzeichnisreplikationsdienstes verwaltet, das über RPC-Transport betrieben wird. Dasselbe Protokoll wird verwendet, um den DCSync-Angriff durchzuführen. Der lokale Synchronisierungsagent sendet alle Benutzerinformationen und Attribute an Entra ID über Port 443. Sobald Entra diese Daten empfängt, verarbeitet und füllt es die erforderlichen Details in seiner Umgebung aus und schließt so den ersten Synchronisierungsprozess ab.
Teil 2: Passwortrückschreiben von Entra ID zu On-Premises
Der zweite Teil des Synchronisierungsprozesses findet statt, wenn Password Writeback in Entra AD Connect aktiviert ist. Diese Funktion ermöglicht die Kennwortsynchronisierung von der Cloud in die lokale Umgebung. Wenn ein Benutzer also sein Kennwort in der Cloud ändert, wird die Änderung auch vor Ort übernommen. Dies gewährleistet eine genaue Synchronisierung zwischen den beiden Umgebungen, was einer der Hauptgründe für die Verbindung ist: Damit können sich Benutzer in allen Anwendungen und Umgebungen der Organisation mit demselben Kennwort anmelden.
Wenn eine Aktion zum Zurücksetzen des Passworts für einen Benutzer in Entra IDsucht das System zunächst nach dem Benutzernamen, um zu überprüfen, ob dieser in Entra ID. Wenn der Benutzer erkannt wird, wird eine Berechtigungsprüfung durchgeführt, um festzustellen, ob die Person, die das Kennwort zurücksetzen möchte, eine Rolle hat, die es ihr erlaubt, diese Aktion durchzuführen. Wenn der Benutzer über die erforderlichen Berechtigungen verfügt, Entra ID sendet den Benutzernamen und das neue Passwort an den Entra Service Bus.
Der vor Ort ausgeführte Synchronisierungsagent ruft diese Informationen ab. Da der von Entra Connect erstellte MSOL-Benutzer zwar DS Sync-Berechtigungen hat, jedoch nur zum Lesen, verwendet er nicht das RPC-Protokoll, um das Kennwort zurückzusetzen. Stattdessen führt er eine LDAP-Anfrage aus, um den entsprechenden Benutzer in Active Directory und versucht mit der Anfrage das Passwort über die Operation „IADsUser.ChangePassword“ zu aktualisieren.
In dieser Phase wird eine wichtige Sicherheitsüberprüfung durchgeführt: Wenn die LDAP-Anforderung vom Domänencontroller (DC) empfangen wird, Active Directory Das Berechtigungssystem prüft, ob der Benutzer, der versucht, das Passwort zu ändern, über die erforderlichen Berechtigungen verfügt, um das Passwort für den Zielbenutzer zurückzusetzen. Dies geschieht durch die Prüfung der ACL des Zielbenutzers. Wenn der MSOL-Benutzer nicht über die Berechtigung „Passwort zurücksetzen“ für die Entität verfügt, wird ein Fehler an Entra ID, was darauf hinweist, dass die Kennwortaktualisierung aufgrund unzureichender Berechtigungen fehlgeschlagen ist. Wenn die Berechtigung „Kennwort zurücksetzen“ vorhanden ist, wurde die Kennwortänderung erfolgreich abgeschlossen.
Die Sicherheitslücke
Während des Synchronisierungsvorgangs fiel mir auf, dass nicht vollständig erfasst ist, welche Benutzer zu privilegierten Gruppen gehören oder über höhere Berechtigungen verfügen. Folglich erhalten diese Benutzer in der Entra-Umgebung nicht automatisch denselben privilegierten Status wie vor Ort. Standardmäßig erhalten Hybridbenutzer bei der ersten Synchronisierung nicht denselben Schutz wie privilegierte Rollen in Entra, es sei denn, der Netzwerkadministrator weist diese Berechtigungen und Schutzmaßnahmen manuell innerhalb von Entra ID.
Wenn man die Synchronisierungsfunktionen zwischen den beiden Umgebungen und die Möglichkeit versteht, Anmeldeinformationen von Entra zurück in die lokale Umgebung zu synchronisieren, stellt sich die Frage: Welche potenziellen Risiken sind damit verbunden?
Das Hauptrisiko besteht darin, durch eine schwache Administratorrolle in Entra erhöhte Berechtigungen im lokalen AD zu erhalten. In AD kann ein Benutzer privilegierte Berechtigungen erhalten, muss aber nicht unbedingt zu einer geschützten Gruppe gehören, was ihn Angriffen aussetzt. Das gleiche Risiko besteht bei diesem Angriffsablauf hier:
Sobald ein Angreifer die Kontrolle über ein Entra ID Benutzer mit der Rolle „Passwortadministrator“ können dessen Berechtigung zum Zurücksetzen des Passworts nutzen, um ihre Berechtigungen zu erhöhen, auch wenn der Benutzer möglicherweise keinen lokalen Benutzer hat. Durch das Zurücksetzen des Passworts eines Benutzers mit erhöhten AD-Berechtigungen, z. B. eines Benutzers aus der Gruppe „DNS-Administratoren“, können sie die Kontrolle über das Konto erlangen und möglicherweise die Berechtigungen innerhalb der lokalen Domäne erhöhen.
Der Angreifer muss sich lediglich mit dem richtigen Benutzerkonto anmelden, das mindestens über die Rolle des Kennwortadministrators verfügt, um Entra ID. Es spielt keine Rolle, ob sie die Schnittstelle verwenden bei https://entra.microsoft.com or https://portal.azure.com. Nach der Anmeldung wählen sie den Zielbenutzer vor Ort aus und setzen einfach dessen Kennwort zurück. Dadurch kann sich der Angreifer mit dem Konto, dessen Kennwort er geändert hat, bei der lokalen Umgebung anmelden.
Es ist wichtig zu beachten, dass der Angriff fehlschlägt, wenn der Zielbenutzer Teil einer geschützten Gruppe in der lokalen Umgebung ist.
Dies liegt daran, dass die Berechtigungsverwaltung für geschützte Benutzer vor Ort Änderungen durch einen Entra ID Verbinden Sie das Konto mit Benutzern in diesen geschützten Gruppen. In einer lokalen Umgebung können geschützte Gruppen identifiziert werden, indem Sie die AdministratorenAnzahl Attribut der Gruppe. Wenn das AdministratorenAnzahl Attribut auf „1“ gesetzt ist, bedeutet dies, dass die Gruppe als geschützt gilt. Diese geschützten Gruppen folgen einer festen Berechtigungsvorlage, die regelmäßig durchgesetzt wird. Jede Stunde wird ein Schutzmechanismus in Active Directory führt einen Prozess aus, der überprüft, ob die Berechtigungen der Gruppe im ACL mit den in der Vorlage definierten Berechtigungen übereinstimmen. Wenn eine Diskrepanz besteht, setzt der Prozess die Berechtigungen zurück, damit sie mit der Vorlage übereinstimmen.
Dieser Prozess wird durch einen Mechanismus namens SDProp (Security Descriptor Propagator), und die Berechtigungsvorlage heißt AdminSDHolder.
Angriffsszenarien, die diese Schwäche ausnutzen
Schattenadministratoren
Schattenadministratoren sind Benutzer, die das Passwort eines Administrators zurücksetzen können, aber keiner Administratorgruppe angehören. Da sowohl lokale Active Directory und Entra ID Behandeln Sie diese Shadow Admins als normale Benutzer (ohne besonderen Schutz durch privilegierte Benutzergruppen), kann ein Angreifer ihre Fähigkeit ausnutzen, das Passwort eines privilegierten Benutzers in Entra zurückzusetzen. Dies bedeutet, dass der Angreifer das Passwort dieses Benutzers auch in der lokalen Umgebung zurücksetzen kann.
Dieses Szenario bietet Angreifern eine klare Möglichkeit, ihre Privilegien zu erhöhen und ihre Kontrolle über das gesamte Netzwerk auszudehnen, indem sie die erhöhten Berechtigungen des kompromittierten Benutzers ausnutzen.
DNS-Administratorgruppe
Ein weiteres Beispiel ist die DNS-Admin-Gruppe. DNS-Admins verwalten kritische Netzwerkinfrastrukturkomponenten, insbesondere DNS-Server. Da die DNS-Admin-Gruppe als privilegierte Gruppe ohne zusätzlichen Schutz vor Ort eingerichtet ist, könnte ein Angreifer das Passwort eines Mitglieds der DNS-Admin-Gruppe problemlos über Entra zurücksetzen. Dies würde ihm die vollständige Kontrolle über dieses Konto in der lokalen Umgebung geben.
Mit der Kontrolle über ein DNS-Administratorkonto könnte der Angreifer den Netzwerkbetrieb erheblich stören. Er könnte DNS-Einträge ändern, um den internen Netzwerkverkehr umzuleiten, Man-in-the-Middle (MITM) Angriffe, indem sie den Datenverkehr über von ihnen kontrollierte Server umleiten oder DNS-Einstellungen ändern, um Benutzer auf bösartige Websites umzuleiten.
Gruppenrichtlinien-Ersteller-Besitzer
Besitzer von Gruppenrichtlinienerstellern sind ein weiteres Beispiel für eine Gruppe, die ohne zusätzlichen Schutz eine privilegierte Gruppe sein könnte. Mitglieder dieser Gruppe können von ihnen erstellte Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) ändern. Wenn ein Angreifer Zugriff auf ein Konto in dieser Gruppe erhält, kann er die Berechtigungen ausnutzen, um vorhandene erzwungene GPOs zu ändern, die möglicherweise schädliche Skripts oder Einstellungen enthalten, z. B. Skripts, die Anmeldeinformationen stehlen oder Malware installieren könnten.
Cert Publishers Gruppe
Cert-Verleger ist ein weiteres Beispiel für eine privilegierte Gruppe, die in Bezug auf Sicherheit möglicherweise nicht immer die erforderliche Aufmerksamkeit erhält. Mitglieder dieser Gruppe erhalten die Möglichkeit, Zertifikate zu veröffentlichen, um Active Directory, die eine Schlüsselrolle in der Organisation spielt Public-Key-Infrastruktur (PKI)Wenn ein Angreifer Zugriff auf ein Konto erhält, das Teil des Cert-Verleger Gruppe, können sie Zertifikate ausstellen oder manipulieren, was zu ernsthaften Sicherheitsrisiken führt.
Beispielsweise könnte der Angreifer eine bösartiges oder betrügerisches Zertifikat um sich als vertrauenswürdige Benutzer oder Dienste auszugeben und so MITM-Angriffe durchzuführen, sichere Kommunikation zu entschlüsseln oder AD-Authentifizierung Kontrollen. Der Angreifer könnte auch die Berechtigungen erhöhen, indem er Zertifikate für Konten mit hohen Berechtigungen wie Domänenadministratoren ausstellt, was zu einer vollständigen Kompromittierung der Domäne führen würde.
Angriffsminderung
1. Wenn Sie ein hybrides Joined Identity-Setup verwenden, vergleichen Sie immer die Berechtigungen zwischen Ihrer lokalen Umgebung und Entra. Stellen Sie außerdem sicher, dass privilegierte Benutzer, die nur in Entra vorhanden sind und keine entsprechenden Konten vor Ort haben, keine Berechtigungen zum Zurücksetzen von Passwörtern erhalten. Dies hilft, unbefugten externen Zugriff und Kontrolle über Ihre Umgebung zu verhindern.
2. Beim Einrichten der Synchronisierung zwischen lokalen Active Directory (AD) und Entra IDist es wichtig, immer die Berechtigungen zu überprüfen, die privilegierten Gruppen in Ihrer lokalen Umgebung zugewiesen sind. Insbesondere sollten Sie sicherstellen, dass diese Gruppen keine unnötigen Berechtigungen zum Ändern von Passwörtern haben.
Wenn Sie feststellen, dass Mitglieder privilegierter Gruppen Passwörter ändern können, haben Sie zwei Möglichkeiten, dies zu beheben:
- Berechtigungen manuell entfernen: Sie können die Berechtigungen für jede privilegierte Gruppe manuell anpassen, um die Möglichkeit zum Ändern von Passwörtern zu entfernen.
- Nutzen Sie die Vorlage AdminSDHolder: Alternativ können Sie die AdministratorenAnzahl Attribut der privilegierten Gruppen gleich „1“ zu sein und sie so zu schützen.
Der AdminSDHolder ist eine Sicherheitsvorlage in Active Directory das Sicherheitsberechtigungen für Mitglieder geschützter Gruppen definiert und durchsetzt. Indem Sie die privilegierten Gruppen zu dieser Vorlage hinzufügen, können Sie deren Berechtigungen zum Ändern von Passwörtern automatisch entfernen.
