Active Directory: LDIF - eine Extraktion, um sie alle zu beherrschen

Das Extrahieren von Daten aus einem Active Directory, dem LDAP-Verzeichnis von Microsoft für Windows-Betriebssysteme, ermöglicht eine Vielzahl von Kontrollen, die einfach zu implementieren und automatisierbar sind und somit die primäre Verteidigung der Zugriffsverwaltung für Ihre Windows-Systeme darstellen.

Das Ziel dieses Artikels ist es, Sie mit der LDIF-Extraktion (LDAP Data Interchange Format) aus einem Active Directory (AD) vertraut zu machen, Ihnen zu zeigen, wie diese Extraktion erfolgt und Ihnen darüber hinaus eine Reihe von Kontrollen auf Grundlage von Empfehlungen der französischen Behörde für Informationssicherheit, dem ANSSI (Agence nationale de la sécurité des systèmes d’information) vorzustellen.

1 – LDIF-Extraktion: Welches Format für welche Daten? 

LDIF ist ein standardisiertes Format, das den Austausch von Daten aus einem LDAP-Verzeichnis erleichtern soll. Es stellt nicht nur Verzeichnisdaten dar, sondern ermöglicht auch Aktionen in einem Verzeichnis (Hinzufügen, Ändern, Löschen von Daten). Die LDIF-Extraktion ist eine Textdatei (mit der Erweiterung ldif oder ldf) und kann mit einem einfachen Texteditor gelesen oder bearbeitet werden.

2 – So erhalten Sie eine LDIF-Extraktion aus einem Active Directory 

Microsoft hat ein dediziertes Extraktionswerkzeug bereitgestellt. Sein vollständiger Name lautet „Lightweight Directory Access Protocol Data Interchange Format Directory Exchange“, ist jedoch allgemein als LDIFDE bekannt. Es handelt sich um ein Befehlszeilentool, das zur Importierung oder Exportierung von LDIF-Dateien verwendet wird. Dieses Tool ist auf Windows-Servern verfügbar, wenn die AD DS (Active Directory Domain Services) oder AD LDS (Active Directory Lightweight Directory Services) Serverrollen auf der Maschine installiert sind.

3 – Was ist mit meiner Extraktion zu tun? 

Nun, da wir eine ordnungsgemäße LDIF-Extraktion unseres AD haben, ist es an der Zeit, zu dem Teil überzugehen, der uns hier interessiert: die Kontrollen! Wir bieten Ihnen 23 Kontrollen an, die Sie bei Ihrer Extraktion durchführen können, um Anomalien in Ihrer Identitäts- und Zugriffsverwaltung zu identifizieren und Schwachstellen in Ihrem IT-System zu vermeiden.

Kontrolle 1: Eine bedeutende Anzahl privilegierter Gruppenmitglieder
Privilegierte Gruppen sind Administrations- und Betriebsgruppen, die alle Rechte und Privilegien auf der Domäne haben oder diese zuweisen können. Die folgenden Gruppen sind enthalten:

• Account-Betreiber
• Administratoren
• Backup-Betreiber
• Domänen-Administratoren
• Enterprise-Administratoren
• Druck-Operatoren
• Schema-Administratoren
• Server-Operatoren

Die Zuweisung dieser Gruppen sollte vermieden werden oder nur dann erfolgen, wenn alle Berechtigungen tatsächlich erforderlich sind. Es ist vorzuziehen, benutzerdefinierte Gruppen unter Anwendung des Prinzips des geringsten Privilegs zu verwenden.

Kontrolle 2: Inkonsistente Domänencontroller
Ein Domänencontroller ist ein Server, der einen Benutzer in der Domäne authentifiziert und seinen Netzwerkzugriff validiert. Es ist wichtig, dass die Benutzerkontensteuerungsattribute (User Account Control, UAC) richtig gesetzt sind. Daher ist es notwendig zu überprüfen, ob der Domänencontroller die Attribute SERVER_TRUST_ACCOUNT und TRUSTED_FOR_DELEGATION und keine anderen aufweist. Zusätzliche Attribute können für „Read Only Domain Controllers“ (RODC) gelten.

Kontrolle 3: Privilegierte Konten ohne Kerberos-Vorauthentifizierung
Kerberos ist ein Authentifizierungsprotokoll, das eine starke Authentifizierung unter Verwendung von Geheimschlüsseln ermöglicht. Privilegierte Konten (Konten mit allen oder potenziell allen Rechten in der Domäne) sollten nicht das Attribut “DONT_REQUIRE_PREAUTH“ haben.

Kontrolle 4: Privilegierte Konten mit SPN
Das Attribut servicePrincipalName wird standardmäßig für Maschinenkonten festgelegt. Dieses Attribut sollte niemals für ein privilegiertes Konto festgelegt werden, da ein „Brute-Force“-Angriff das Passwort des privilegierten Kontos durch das von Kerberos ausgestellte Ticket abrufen könnte.

Kontrolle 5: Privilegierte Konten mit Passwörtern, die niemals ablaufen
Die zahlreichen mit dieser Anomalie verbundenen Risiken müssen nicht aufgelistet werden. Das Attribut „DONT_EXPIRE“ sollte niemals für ein privilegiertes Konto festgelegt werden. Das Kompromittieren der gesamten Domäne könnte dadurch erleichtert werden (z. B. durch einen ehemaligen Mitarbeiter).

Kontrolle 6: Privilegierte Konten mit unveränderten Passwörtern über längeren Zeitraum
Um die mit dem Diebstahl von Passwörtern verbundenen Risiken zu minimieren, ist es wichtig, häufige Passwortwechsel durchzuführen. Dies gilt für alle Benutzer, ist jedoch für privilegierte Konten noch kritischer.

Kontrolle 7: Domänencontroller mit unveränderten Computerkontopasswörtern über 45 Tage
Standardmäßig erfolgt alle 30 Tage eine Passwort-Rotation. Wenn dies nicht erreicht werden kann, ist es wichtig, die Ursache umgehend zu untersuchen.

Kontrolle 8: Inaktive Domänencontroller
Ein Domänencontroller stellt typischerweise alle 30 Tage eine Verbindung her, um sein Passwort zu ändern. Das Fehlen der Authentifizierung kann auf eine Desynchronisierung zurückzuführen sein. In solchen Fällen muss der Domänencontroller neu installiert oder entfernt werden.

Kontrolle 9: Konten mit einem primaryGroupId kleiner als 1.000
Dieses Attribut verknüpft einen Benutzer implizit mit einer Gruppe. Einige Schnittstellen zeigen diese Beziehung nicht in der Liste der Gruppenmitglieder an. Daher ist es wichtig, den Standardwert beizubehalten: 513 für einen Benutzer, 514 für einen Gast und 515 für einen Computer.

Kontrolle 10: Konten, die Mitglieder der DnsAdmins-Gruppe sind
Es wird empfohlen, die DnsAdmins-Gruppe nicht zu verwenden. Diese Gruppe ermöglicht die Ausführung von Code über den DNS-Dienst, der normalerweise auf dem Domänencontroller gehostet wird.

Kontrolle 11: Hohe Anzahl ungenutzter aktiver Konten
Ein inaktives Konto ist eines, das sich über einen bestimmten Zeitraum nicht in der Domäne angemeldet hat. Es kann sich um ein selten verwendetes Konto (oder dessen Besitzer befindet sich im Urlaub) oder ein veraltetes Konto (verbunden mit einem ehemaligen Mitarbeiter) handeln. Eine effiziente Kategorisierung inaktiver Konten ist wichtig, um veraltete Konten zu deaktivieren, die Angriffsfläche zu verringern und die Arbeitslast während Rechteprüfungen zu reduzieren.

Kontrolle 12: Uneingeschränkte Weitergabe von Authentifizierung
Das Attribut „TRUSTED_FOR_DELGATION“ sollte nur in Domänencontrollern vorhanden sein. Wenn ein anderes Konto dieses Attribut hat, könnte es sich bei einem Kerberos-Dienst mit der Identität eines anderen Kontos authentifizieren, das sich bei dem ersten Konto authentifiziert hat.

Kontrolle 13: Konten ohne Kerberos-Vorauthentifizierung
Das Attribut „DONT_REQUIRE_PREAUTH“ sollte in einem Konto nicht vorhanden sein.

Kontrolle 14: Benutzerkonten mit schwacher Kerberos-Verschlüsselung
Kerberos kann den DES-Verschlüsselungsalgorithmus zur Ausstellung von Tickets verwenden. Dieser Algorithmus gilt jedoch als veraltet, daher sollte das Attribut „USE_DES_KEY_ONLY“ von Konten im AD entfernt werden.

Kontrolle 15: Konten mit Passwörtern, die niemals ablaufen
Eine zweite Kontrolle zur Passwortablaufzeit, diesmal gilt das Kriterium für alle Benutzer im AD, nicht nur für privilegierte Konten.

Kontrolle 16: Falsche Version des Active Directory
In bestimmten Versionen des Active Directory haben die Key Admins und Enterprise Key Admins-Gruppen übermäßig berechtigte Zugriffssteuereinträge (ACE). Die Versionen Windows Server 1709 beheben dieses Problem, daher ist ein Update wichtig. Überprüfen Sie den Wert „ActiveDirectoryUpdate“ in der LDIF-Datei. Wenn die Version 15 ist, wird empfohlen, das Update durchzuführen.

Kontrolle 17: Die Gruppe „Pre-Windows 2000 Compatible Access“ enthält „Anonymous“
Diese Gruppe sollte nur „Authenticated Users“ (S-1-5-11) und nicht „Anonymous“ (S-1-5-7) enthalten. Andernfalls ist die anonyme Enumeration bestimmter Elemente vom Domänencontroller aus möglich.

Kontrolle 18: Passwort des krbtgt-Kontos seit über einem Jahr unverändert
Die Kompromittierung des „krbtgt“-Kontos würde einem Angreifer ermöglichen, Kerberos-Tickets zu fälschen und sich mit administrativen Rechten in der gesamten Domäne zu authentifizieren.

Kontrolle 19: Konto mit geänderter primaryGroupID
Früher haben wir empfohlen, primaryGroupIDs kleiner als 1.000 (außer dem Standardwert) zu verbieten. Jetzt raten wir davon ab, dieses Attribut zu ändern, da dies eine implizite Gruppenmitgliedschaft bedeutet. Eine explizite Deklaration über das „MemberOf“-Attribut wird bevorzugt.

Kontrolle 20: Konten oder Gruppen, die Mitglieder der „Pre-Windows 2000 Compatible Access“ sind
Gleiche Erklärungen wie bei Kontrolle 17, aber dieses Mal erweitern wir den Kontrollumfang, um zu verhindern, dass Anonymous über einen Vermittler Mitglied dieser Gruppe wird.

Kontrolle 21: Privilegierte Konten, die keine Mitglieder der „Protected Users“ Gruppe sind
Die „Protected Users“ Gruppe schafft Barrieren für Mitgliederbenutzer:

• Erzwingen der Kerberos-Authentifizierung
• Verringerung der Lebensdauer von Kerberos-Tickets
• Durchsetzung der Verwendung starker Verschlüsselungsalgorithmen (z. B. AES)
• Deaktivierung des Passwortspeicherns auf Arbeitsstationen
• Verbot jeglicher Form der Delegation

Kontrolle 22: Konten mit umkehrbarer Passwortspeicherung
Wenn das Attribut „ENCRYPTED_TEXT_PASSWORD_ALLOWED“ für ein Konto festgelegt ist, kann das Passwort für dieses Konto im Klartext abgerufen werden.

Kontrolle 23: Konten oder Gruppen mit SID-History
Das sIDHistory-Attribut muss bei allen Benutzern und Gruppen in der Domäne leer sein. Wenn es gefüllt ist, generiert es Protokolle, die Ereignisprotokolle überfluten können und von einem Angreifer genutzt werden können, um unbefugte Rechte für Ressourcen zu erlangen.

Abschluss 

Wir haben gerade einige Kontrollen aufgelistet, die leicht durchgeführt werden können, um einen Überblick über die Einhaltung der ANSSI-Best Practices Ihres Active Directory zu erhalten. Darüber hinaus können diese Kontrollen mithilfe von PowerShell-Skripten problemlos automatisiert werden. Sobald die Kontrollen implementiert sind, müssen Anomalien klar gemeldet werden, damit sie schnell verwaltet werden können. WALLIX bietet einen „One Shot“-Ansatz zur Durchführung dieser Kontrollen für einen schnellen Überblick über erste Maßnahmen oder zur Integration dieser Kontrollen in eine umfassendere Identitäts- und Zugriffsverwaltungspolitik, die das gesamte IT-System abdeckt. Dies kann alles über eine Web-Schnittstelle für präzise und klare Berichte eingesehen werden.