Uwe Gradenegger – Seite 51

Die Rollenkonfiguration für den Registrierungsdienst für Netzwerkgeräte (NDES) schlägt fehl mit Fehlermeldung "CMSCEPSetup::Install: The system cannot find the path specified. 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND)"

Folgendes Szenario angenommen:

Man installiert einen Network Device Enrollment Service (NDES) Server.
Die Rollenkonfiguration schlägt mit folgender Fehlermeldung fehl:

CMSCEPSetup::Install: The system cannot find the path specified. 0x80070003 (WIN32: 3 ERROR_PATH_NOT_FOUND)

Die Network Device Enrollment Service (NDES) Administrations-Webseite (certsrv/mscep_admin) meldet "The password cache is full."

Folgendes Szenario angenommen:

Ein NDES Server ist im Netzwerk konfiguriert.
Bei Aufruf der Administrations-Webseite (certsrv/mscep_admin) kommt folgende Meldung:

The password cache is full.

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.

Erzeugen einer RFC 2818 konformen Zertifikatanforderung für SSL Zertifikate

Google ist mit dem Chromium Projekt und darauf basierenden Produkten wie Google Chrome und Microsoft Edge dazu übergegangen, das im Jahr 2000 verabschiedete RFC 2818 zu erzwingen und Zertifikaten nicht mehr zu vertrauen, welche das RFC nicht mehr erfüllen.

Für uns ist folgender Satz von großer Brisanz:

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead
https://tools.ietf.org/html/rfc2818

Gerätevorlage für den Registrierungsdienst für Netzwerkgeräte (NDES) konfigurieren

In der Standardeinstellung beantragt der Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) Zertifikate von der Vorlage "IPsec (Offline Request)". Diese Zertifikatvorlage stammt aus Windows 2000 Zeiten und kann nicht bearbeitet werden. Darum ist es empfehlenswert, die Standardeinstellungen zu verändern und eigene Zertifikatvorlagen zu verwenden, die die persönlichen Anforderungen bedienen.

Secure Sockets Layer (SSL) für den Registrierungsdienst für Netzwerkgeräte (NDES) aktivieren

In der Standardkonfiguration nimmt der Network Device Enrollment Service (NDES) nur unverschlüsselte Verbindungen via HTTP an. Es ist angeraten, dass zumindest die Administrations-Webseite von NDES für HTTP über TLS (HTTPS) konfiguriert wird, um Mitschnitte des Netzwerkverkehrs zu erschweren. Nachfolgend eine Anleitung.

Für eine nähere Betrachtung zur Notwendigkeit der Verwendung von SSL siehe Artikel "Sollte HTTPS für den Registrierungsdienst für Netzwerkgeräte (NDES) verwendet werden?".

Network Device Enrollment Service (NDES) auf eine andere Zertifizierungsstelle umziehen

Folgendes Szenario angenommen:

Es ist eine NDES-Instanz im Netzwerk installiert.
Die an NDES ausstellende Zertifizierungsstelle soll geändert werden.

Die offizielle Aussage hierzu ist, dass NDES in diesem Fall neu installiert und konfiguriert werden muss. Dies ist jedoch nicht erforderlich. Nachfolgend sind die notwendigen Schritte beschrieben.

Den Registrierungsdienst für Netzwerkgeräte (NDES) ohne Enterprise Administrator Berechtigungen installieren

Folgendes Szenario angenommen:

Man installiert einen Network Device Enrollment Service (NDES) Server.
Die Rollenkonfiguration schlägt mit folgender Fehlermeldung fehl:

Insufficient access rights to perform this operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS

Üblicherweise erfordert die NDES-Rollenkonfiguration, dass der installierende Benutzer Mitglied der Gruppe "Enterprise Admins" ist. Dies ist technisch jedoch nicht notwendig und widerspricht den Sicherheits-Härtungs-Empfehlungen von Microsoft, da es sich bei NDES nicht (unbedingt) um ein System handelt, welches der höchsten Sicherheitsschicht (Tier-0) zugeordnet wird.

Nachfolgend wird ein Weg beschrieben, wie man die NDES-Rolle auch ohne die geforderten Rechte konfigurieren kann.

Die Rollenkonfiguration für den Registrierungsdienst für Netzwerkgeräte (NDES) schlägt fehl mit Fehlermeldung "CMSCEPSetup::SetMSCEPSetupProperty: Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)"

Folgendes Szenario angenommen

Man installiert einen Network Device Enrollment Service (NDES) Server
Die Rollenkonfiguration schlägt mit folgender Fehlermeldung fehl:

CMSCEPSetup::SetMSCEPSetupProperty: Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)

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.

Bei der Installation eines neuen Zertifizierungsstellenzertifikats erhält man die Fehlermeldung "The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614 CRYPT_E_NO_REVOCATION_CHECK)"

Folgendes Szenario angenommen:

Man installiert ein neues Zertifizierungsstellen-Zertifikat auf der Zertifizierungsstelle, entweder weil die Zertifizierungsstelle neu installiert wurde, oder weil das Zertifizierungsstellen-Zertifikat erneuert wurde.
Bei der Installation erhält man folgende Fehlermeldung:

Cannot verify certificate chain. Do you wish to ignore the error and continue? The revocation function was unable to check revocation for the certificate. 0x80092012 (-2146885614 CRYPT_E_NO_REVOCATION_CHECK)

Die Veröffentlichtung einer Zertifikatsperrliste (CRL) schlägt fehl mit der Fehlermeldung "Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)"

Folgendes Szenario angenommen:

Man versucht, auf einer Zertifizierungsstelle eine neue Zertifikatsperrliste (CRL) zu veröffentlichen
Die Zertifizierungsstelle ist für die Veröffentlichung der Zertifikatsperrlisten ins Active Directory (LDAP CDP) konfiguriert.
Die Veröffentlichung der Zertifikatsperrliste schlägt mit folgender Fehlermeldung fehl:

Insufficient access rights to perform the operation. 0x80072098 (WIN32: 8344 ERROR_DS_INSUFF_ACCESS_RIGHTS)

Die Veröffentlichtung einer Zertifikatsperrliste (CRL) schlägt fehl mit der Fehlermeldung "Directory object not found. 0x8007208d (WIN32: 8333 ERROR_DS_OBJ_NOT_FOUND)"

Folgendes Szenario angenommen:

Man versucht, auf einer Zertifizierungsstelle eine neue Zertifikatsperrliste (CRL) zu veröffentlichen.
Die Zertifizierungsstelle ist für die Veröffentlichung der Zertifikatsperrlisten ins Active Directory (LDAP CDP) konfiguriert.
Die Veröffentlichung der Zertifikatsperrliste schlägt mit folgender Fehlermeldung fehl:

Directory object not found. 0x8007208d (WIN32: 8333 ERROR_DS_OBJ_NOT_FOUND)

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.