Tags: Active Directory, Authentifizierung, Sicherheit, Verschlüsselung
Im August 2020 wurde die Schwachstelle CVE-2020-1472 im Netlogon Remote Protocol publiziert. Microsofts Patch erzwingt ab dem 9. Februar die Kommunikation über einen Secure RPC. Inkompatible Geräte können sich ab sofort nur mehr an einem DC authentifizieren, wenn man sie über ein GPO zulässt.
Ursache für die entdeckte Sicherheitslücke ist die schwache AES-Verschlüsselung in einem Netlogon Secure Channel. Sie ermöglicht einem nicht authentifizierten Angreifer, die Identität eines PCs in der Domäne oder eines DCs anzunehmen und so administrative Privilegien zu erhalten.
Patch mit dem August-Update
Microsoft reagierte bereits mit dem kumulativen Update im August (KB4571694) und brachte eine Lösung für dieses Problem. Sie erfordert einen Secure RPC für Netlogon-Verbindungen. Der Patch sollte auf allen Domänen-Controllern, inklusive der RODCs, installiert werden.
Während der ersten Phase erzwingen DCs die Verschlüsselung und Signierung nur bei der Anmeldung von Windows-Rechnern. Andere Geräte können weiterhin das weniger sichere Verfahren nutzen, wobei der DC dann das Ereignis 5829 in das Eventlog schreibt. Diese Einträge könnte man mit
Get-EventLog -LogName System -InstanceId 5829 -Source NETLOGON | Format-List
anzeigen.
Sie sollten Admins helfen, Geräte zu identifizieren, die bei einer vollständigen Durchsetzung des sicheren RPC Probleme hätten, sich zu authentifizieren. Das trifft insbesondere auf Rechner zu, die Samba nutzen. Auch dafür existieren bereits Patches (zum Beispiel hier für Ubuntu), die dringend auf Linux-Maschinen angewandt werden müssen, wenn sie als DCs fungieren.
Umschalten in den Enforcement Mode
Wenn kein Client eine unsichere Netlogon-Verbindung mit einem Domänen-Controller herstellen will, dann kann man auf DCs den Registry-Schlüssel FullSecureChannelProtection unter
HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
auf den Wert 1 setzen und so ausschließlich Netlogon Secure Channel über Secure RPC zulassen.
Wenn man diese Maßnahme nicht ergreift, dann ist das Risiko dennoch geringer als bei der Entdeckung der Schwachstelle. Das Update bessert nämlich auf bei der Verschlüsselung nach.
Phase des Enforcement
Mit dem 9. Februar 2021 schaltet Microsoft die Domänen-Controller in den Modus, in den sie der oben genannte Registrierschlüssel versetzt. Der Key verliert dann jedoch seine Wirkung, ein Zurück zu unsicheren Verbindungen über die Zuweisung des Werts 0 ist jetzt nicht mehr möglich.
Außerdem hören DCs mit diesem Datum auf, den Log-Eintrag 5829 zu schreiben, so dass Admins entsprechende Geräte bis dahin bereits identifiziert haben sollten. Weiterhin aufgezeichnet werden jedoch die Events 5827 und 5828, wenn Domänen-Controller unsichere Verbindungen ablehnen.
Sollten sich immer noch Geräte im Netz befinden, die sich an der Domäne anmelden müssen, aber sich nicht aktualisieren lassen, um das abgesicherte Netlogon zu nutzen, dann kann man für sie eine Ausnahme einrichten.
Microsoft sieht dafür eine neue Einstellung in der Gruppenrichtlinien unter Computerkonfiguration => Richtlinien => Windows-Einstellungen => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen vor. Sie heißt Domain controller: Allow vulnerable Netlogon secure channel connections ("Domänen-Controller: Sichere Verbindungen mit verwundbaren Kanäle über den Anmeldedienst (Netlogon) zulassen").
Nach Aktivieren der Richtlinie weist man ihr die Computer- oder Service-Konten zu, die sich über eine unsichere Verbindung anmelden dürfen. Dabei sollte es sich natürlich um keine dauerhafte Lösung handeln, sondern sie soll nur dazu dienen, um die Zeit bis zur Aktualisierung der betreffenden Geräte zu überbrücken.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- KrbRelayUp: Domänen-Controller gegen Angriffe auf Resource-based constrained Delegation absichern
- AD-Zertifikatsdienste (AD CS) von SHA-1 auf SHA-2 migrieren: Gründe und Hindernisse
- Domain Controller mit LDAP Channel Binding und LDAP Signing absichern
- Im Test: AD-Passwörter im Self Service zurücksetzen mit Specops uReset
- SpecOps Password Policy: Sichere Passwörter für das Active Directory
Weitere Links