AD Query hat lange gedient und sollte asap mit Identity Collector (IDC) abgelöst werden. Erstens hat IDC einige Vorteile gegenüber AD Query und zweitens wird es aufgrund einer Vulnerability von Microsoft Anpassungen an Windows DCOM geben, welche weitere Nachteile für AD Query bringen. Aber alles der Reihe nach.
Warum AD Query ablösen?
Die Vulnerability «Windows DCOM Server Security Feature Bypass» (CVE-2021-26414) zwingt Microsoft zu schrittweisem Hardening ihres DCOM Services. Das CVSS Severity Rating liegt bei 6.5, und ist somit als Medium Severity einzustufen. Bis jetzt konnte man dieses Hardening per Registry Key deaktivieren, macht aber den DC verwundbar für die Vulnerability. Ein zu hohes Risiko für den Domänen Controller (DC) würde ich meinen.
Ab 14. März 2023 wird es nicht mehr möglich sein, das Hardening zu umgehen und es werden relativ hohe Rechte an den DCOM Client gefordert. Die meisten werden der Einfachheit halber einen Domänen Admin verwenden, was per se keine gute Idee ist.
Check Point und AVANTEC empfehlen IDC zu verwenden, um für Identity Awareness relevante Events von den DC’s zu erhalten. Im Gegensatz zu AD Query funktioniert der IDC nicht per WMI sondern per Windows Event Log API.
Die Vorteile von Identity Collector (IDC)
-
- IDC benötigt weniger hohe Rechte auf dem DC, read-only Zugriff auf domain security logs genügt. Damit kann das «least privilege» Prinzip angewandt werden. Dies ist der eigentliche Hauptgrund, warum man von AD Query wegkommen sollte.
- Verringert die Last auf dem PDP Gateway
- Verringert die Last auf den DC’s, die verwendete native Windows API verbraucht weniger Ressourcen.
- Der IDC abonniert die Events vom DC und erreicht damit realtime identity assurance.
- Es können weitere Identity Sourcen angebunden werden, wie zum Beispiel
- Cisco ISE
- Syslog
- NetIQ eDirectory 8.8
Wie migrieren?
Nachfolgend eine Kurzanleitung zur Migration von AD Query zu IDC.
- IDC installieren und konfigurieren
Um die Verfügbarkeit zu gewährleisten, den IDC auf (mindestens) zwei Windows Servern installieren. Idealerweise stehen die Windows Server im Netzwerk möglichst nah an den DC’s. Theoretisch wäre es möglich den IDC auf den DC’s zu installieren. Das würde ich aber nicht empfehlen. Details zu Anforderungen stehen im Technical Overview (sk108235). Im IA Admin Guide werden Installation, Konfiguration und Optimierung beschrieben. Die DC’s und Exceptions analog zu AD Query konfigurieren.
- IDC als Identity Source, zusätzlich zu AD Query anbinden
Nachdem man IDC installiert und konfiguriert hat, am nächsten Morgen auf dem PDP prüfen, ob die Identities zusätzlich vom IDC gelernt wurden. Mit folgendem Befehl auf dem PDP:
pdp monitor ip <ip adresse>
Wenn man im Schritt eins alles richtig gemacht hat, sollte nun in der Machine und User Session bei «Client Type» zusätzlich zu AD Query auch ein Eintrag für IDC ersichtlich sein.
- AD Query als Identity Source entfernen
Falls die Identities korrekt durch IDC gelernt wurden, kann AD Query als Identity Source vom PDP Gateway entfernt werden. Ebenfalls sollte von der LDAP Account Unit der Haken für «Active Directory Query» entfernt werden.
- Credentials anpassen
Auf der Account Unit kann nun ein User verwendet werden, welcher die Rechte read only auf die domain security logs besitzt.
Details inkl. Lernvideos von Peter Elmer zu der oben angeführten Prozedur können unter sk179544 abgerufen werden.
Falls Hilfe bei der Umsetzung benötigt wird, unterstützen wir Sie gerne bei dem Vorhaben.
Weiterführende Links
Check Point response to CVE-2021-26414 – „Windows DCOM Server Security Feature Bypass“
sk93938
ID Collector – Technical Overview
sk108235
Identity-Based Access Control and Threat Prevention – Design Guidelines – Identity Collector
sk179544
Identity Awareness AD Query
sk60301
Identity Awareness R81.10 Administration Guide
ID Collector
IDC Configuration
IDC Installation
IDC Optimization
