Security – Seite 7 – Uwe Gradenegger

Bearbeiten des NTAuthCertificates Objektes im Active Directory

In der Standardkonfiguration befinden sich alle Zertifizierungsstellen-Zertifikate von ins Active Directory integrierten Zertifizierungsstellen (Enterprise Certification Authority) in einem Objekt vom Typ CertificationAuthority namens NTAuthCertificates innerhalb der Configuration Partition der Active Directory Gesamtstruktur.

Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus

Vereinfacht ausgedrückt kann man Public Key Kryptographie auf die Annahme reduzieren, dass der private Teil eines jeden Schlüsselpaares nur dessen Inhaber bekannt ist.

Eine Zertifizierungsstelle ist für die korrekte Identifikation von Benutzern, Computern oder Ressourcen zuständig. Ihren ausgestellten Zertifikaten wird deshalb ein Vertrauensstatus eingeräumt, weil alle Teilnehmer der Annahme sind, dass ihr privater Schlüssel nur ihr bekannt ist.

Gelingt es einem Angreifer, Kenntnis des privaten Schlüssels einer Zertifizierungsstelle zu erlangen, oder zumindest Signaturen mittels des privaten Schlüssels durchzuführen, ist die Integrität der Zertifizierungsstelle nicht länger gewährleistet.

Grundlagen: Einschränken der erweiterten Schlüsselverwendung (Extended Key Usage, EKU) in Zertifizierungsstellen-Zertifikaten

Eine sinnvolle Härtungsmaßnahme für Zertifizierungsstellen ist das Einschränken der Zertifizierungsstellen-Zertifikate, sodass diesen nur für die tatsächlich ausgestellten erweiterten Schlüsselverwendungen (Extended Key Usage) vertraut wird.

Im Fall einer Kompromittierung der Zertifizierungsstelle ist der Schaden dann (immerhin) auf die definierten Extended Key Usages beschränkt.

Das für viele Angriffe interessante Smart Card Logon Extended Key Usage (in Verbindung mit der Mitgliedschaft der Zertifizierungsstelle in NTAuthCertificates) wäre dann nur in dem Zertifizierungsstellen-Zertifikat derjenigen Zertifizierungsstelle, die auch tatsächlich solche Zertifikate ausstellt, vorhanden.

Welche Schlüssellängen sollten für Zertifizierungsstellen und Zertifikate verwendet werden?

Bei der Planung einer Public Key Infrastruktur kommt naturgemäß die Frage auf, welche Schlüssellängen für Zertifizierungsstellen- und Endzertifikate gewählt werden sollten.

Eigene Registration Authority (RA) Zertifikatvorlagen für den Registrierungsdienst für Netzwerkgeräte (NDES) verwenden

Der Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) verwendet zwei Zertifikatvorlagen für seine interne Funktion, um ihn als Registrierungsstelle (Registration Authority, RA) wirken zu lassen. Diese werden während der Rollenkonfiguration des NDES Dienstes auf der konfigurierten Zertifizierungsstelle veröffentlicht und Zertifikate werden beantragt:

CEP Encryption
Exchange Enrollment Agent (Offline Request)

Bei diesen Zertifikatvorlagen handelt es sich um Standardvorlagen aus der Windows 2000 Welt (Version 1 Vorlagen), d.h. sie können nicht bearbeitet werden. Darüber hinaus ist die Exchange Enrollment Agent (Offline Request) Vorlage als Benutzervorlage gekennzeichnet, d.h. während der NDES Rollenkonfiguration wird das Zertifikat im Kontext des installierenden Benutzers beantragt und anschließend in den Maschinenspeicher importiert. Spätestens, wenn die Zertifikate nach zwei Jahren erneuert werden sollen, wird es hier kompliziert.

Daher bietet es sich an, eigene Zertifikatvorlagen für NDES zu verwenden. Diese können beispielsweise in Hinsicht auf ihre Schlüssellänge angepasst werden. Auch die Verwendung von Hardware Security Modulen (HSM) ist auf diese Weise möglich. Sogar eine automatische Erneuerung kann konfiguriert werden.

Domänencontroller überprüfen erweiterte Schlüsselverwendung (Extended Key Usage) bei Smartcard Anmeldung nicht

Wer die Smartcard Logon Funktion im Unternehmen verwenden möchte, ist gut beraten, für eine möglichst starke Sicherheitshärtung seiner Zertifizierungsstelle zu sorgen. Hierzu zählen einige essentielle Maßnahmen:

Entfernen aller nicht notwendigen Zertifizierungsstellen-Zertifikate aus dem NTAuthCertificates Objekt im Active Directory: Jede Zertifizierungsstelle, welche sich in diesem Speicher befindet, ist im Active Directory für die komplette Gesamtstruktur für die Ausstellung von Smartcard Logon Zertifikaten berechtigt.
Verwenden von qualifizierter Subordinierung: Einschränken der Zertifizierungsstellen-Zertifikate, sodass diesen nur für die tatsächlich ausgestellten Extended Key Usages vertraut wird. Im Fall einer Kompromittierung der Zertifizierungsstelle ist der Schaden dann auf diese Extended Key Usages beschränkt. Das "Smart Card Logon" Extended Key Usage wäre dann nur in dem Zertifizierungsstellen-Zertifikat derjenigen Zertifizierungsstelle, die auch tatsächlich solche Zertifikate ausstellt, vorhanden.

Interessant bei diesen Gedanken ist jedoch, dass die Domänencontroller bei der Anmeldung via Smartcard die Extended Key Usages überhaupt nicht überprüfen.

Gefährdung der Active Directory Gesamtstruktur durch das Flag EDITF_ATTRIBUTESUBJECTALTNAME2

In Netz kursieren leider viel zu viele Anleitungen (auch die großen Player sind hiervon nicht ausgenommen, nicht einmal Microsoft selbst oder der Großmeister Komar), welche fatalerweise empfehlen, dass das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 auf der Zertifizierungsstelle gesetzt werden sollte – angeblich damit man in der Lage wäre, für manuell gestellte Zertifikatanforderungen Zertifikate mit Subject Alternative Name (SAN) Erweiterung ausstellen zu können.

Leider ist diese Vorgehensweise nicht nur unnötig, sie hat auch einige unangenehme Nebenwirkungen, welche einem Angreifer im schlechtesten Fall dazu verhelfen können, die gesamte Active Directory Gesamtstruktur zu übernehmen.

Benötigte Firewallregeln für Active Directory Certificate Services

Implementiert man eine Active Directory integrierte Zertifizierungsstelle, ist oft eine Planung der im Netzwerk zu erstellenden Firewallregeln erforderlich. Nachfolgend eine Aufstellung der benötigten Firewallregeln und eventueller Fallstricke.

Übersicht über die verschiedenen Generationen von Domänencontroller-Zertifikaten

Über die Generationen der Windows-Betriebssysteme wurden verschiedene Zertifikatvorlagen für Domänencontroller etabliert. In einem aktuellen Active Directory Verzeichnisdienst wird man drei verschiedene Vorlagen für diesen Zweck finden.

Domain Controller
Domain Controller Authentication
Kerberos Authentication

Nachfolgend eine Beschreibung der einzelnen Vorlagen und eine Empfehlung für die Konfiguration von Domänencontroller-Zertifikatvorlagen.

Warum Active Directory integrierte Zertifizierungsstellen Mitglieder der "Pre-Windows 2000 Compatible Access" Sicherheitsgruppe sind

Im Rahmen von Sicherheitshärtungsmaßnahmen gegen den Active Directory Verzeichnisdienst kommt des Öfteren die Frage auf, warum Active Directory integrierte Zertifizierungsstellen (Enterprise Certification Authority) Mitglieder der Sicherheitsgruppe Pre-Windows 2000 Compatible Access sind.

Übertragen der Zertifikatsperrlisten auf die Sperrlistenverteilpunkte mit SSH Secure Copy (SCP) mit Authentifizierung über öffentliche Schlüssel (Windows Server 2019)

Wenn sich die Server, welche die Sperrlistenverteilpunkte bereitstellen, beispielsweise in einer Demilitarisierten Zone (DMZ) befinden, oder aus anderen Gründen kein Datentransfer via Server Message Block (SMB) möglich ist, können die Sperrlisten mittels SSH Secure Copy (SCP) auf die Verteilpunkte übertragen werden. Seit Windows Server 2019 gibt es die OpenSSH Server und Client-Pakete. Nachfolgend wird die Einrichtung mit Authentifizierung über öffentliche Schlüssel (Public Key Authentication) anstelle von Passwörtern exemplarisch beschrieben

Die Beantragung eines Zertifikats schlägt fehl mit der Fehlermeldung "A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)"

Folgendes Szenario:

Ein Benutzer bentragt ein Zertifikat von einer Active Directory integrierten Zertifizierungsstelle (Enterprise Certification Authority).
Dem Zertifikat der Zertifizierungsstelle wird vertraut, d.h. sie befindet sich im Speicher für vertrauenswürdige Stammzertifizierungsstellen (Trusted Root Certification Authorities).
Die Beantragung des Zertifikats schlägt mit folgender Fehlermeldung fehl:

A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)

Benötigte Windows-Sicherheitsberechtigungen für den Registrierungsdienst für Netzwerkgeräte (NDES)

Angenommen, man implementiert das Active Directory-Verwaltungsebenenmodell (Administrative Tiering Model) von Microsoft, oder wendet vergleichbare Härtungsmaßnahmen auf seinen Servern an, hat dies Auswirkungen auf die NDES Komponenten.