Uwe Gradenegger – Seite 40

Übersicht über die von der Zertifizierungsstelle generierten Audit-Ereignisse

Nachfolgend eine Übersicht über die von der Zertifizierungsstelle erzeugten Audit-Ereignisse in der Windows-Ereignisanzeige.

Im Gegensatz zu betrieblichen Ereignissen, die oft unter dem Begriff "Monitoring" verstanden werden, handelt es sich bei der Auditierung für die Zertifizierungsstelle um die Konfiguration der Protokollierung von sicherheitsrelevanten Ereignissen.

Die Anmeldung via Smartcard über Remotedesktop (RDP) schlägt fehl mit Fehlermeldung "The requested key container does not exist on the smart card."

Folgendes Szenario angenommen:

Ein Benutzer meldet sich mittels Smartcard Logon Funktion auf einem Remote Desktop System an.
Der Benutzer verwendet einen Yubico Yubikey als Smartcard. Die benötigte Middleware ist sowohl auf dem lokalen als auch auf dem Remotesystem installiert.
Die Anmeldung schlägt mit folgender Fehlermeldung fehl:

The system could not log you on. The requested key container does not exist on the smart card.

Übersicht über die von der Zertifizierungsstelle generierten Windows-Ereignisse

Nachfolgend eine Übersicht über die von der Zertifizierungsstelle erzeugten Ereignisse in der Windows-Ereignisanzeige.

Übersicht über die vom Zertifikatregistrierungs-Richtliniendienst (CEP) generierten Windows-Ereignisse

Nachfolgend eine Übersicht über die vom Zertifikatregistrierungs-Richtliniendienst (CEP) erzeugten Ereignisse in der Windows-Ereignisanzeige.

Die Ereignisse des Zertifikatregistrierungs-Richtliniendienstes sind nicht offiziell dokumentiert. Die nachfolgende Liste wurde mit Hilfe des Tools Windows Event Log Messages (WELM) erzeugt.

Übersicht über die vom Zertifikatregistrierungs-Webdienst (CES) generierten Windows-Ereignisse

Nachfolgend eine Übersicht über die vom Zertifikatregistrierungs-Webdienst (CES) erzeugten Ereignisse in der Windows-Ereignisanzeige.

Die Ereignisse des Zertifikatregistrierungs-Webdienstes sind nicht offiziell dokumentiert. Die nachfolgende Liste wurde mit Hilfe des Tools Windows Event Log Messages (WELM) erzeugt.

Übersicht über die vom Registrierungsdienst für Netzwerkgeräte (NDES) generierten Windows-Ereignisse

Nachfolgend eine Übersicht über die vom Registrierungsdienst für Netzwerkgeräte (NDES) erzeugten Ereignisse in der Windows-Ereignisanzeige.

Die Ereignisse des Registrierungsdienst für Netzwerkgeräte sind nicht offiziell dokumentiert. Die nachfolgende Liste wurde mit Hilfe des Tools Windows Event Log Messages (WELM) erzeugt.

Übersicht über die vom Onlineresponder (OCSP) generierten Windows-Ereignisse

Nachfolgend eine Übersicht über die vom Onlineresponder (OCSP) erzeugten Ereignisse in der Windows-Ereignisanzeige.

Die Ereignisse des Onlineresponders sind nicht offiziell dokumentiert. Die nachfolgende Liste wurde mit Hilfe des Tools Windows Event Log Messages (WELM) erzeugt.

Kombination Onlineresponder (OCSP) mit Delta CRL und Sperrlistenverteilpunkt (CDP) ohne Deltasperrliste für gesteigerte Resilienz

OCSP Antworten eines Microsoft OCSP Resonders sind genau so lange gültig wie die zugrunde liegende Sperrliste. In manchen Szenarien möchte man die Gültigkeitszeiten von OCSP verringern, indem man Delta CRLs verwendet. Gleichzeitig soll aber bei den in den CDP Pfaden eingetragenen Sperrlisten keine Delta CRL verwendet werden, um einen Fallback auf eine länger gültige CRL zu ermöglichen.

Auswirkungen des Ausfalls des Onlineresponders (OCSP) auf die Überprüfung des Sperrstatus eines Zertifikats

Nachfolgend wird untersucht, wie sich die Überprüfung des Sperrstatus verhält, wenn der Onlineresponder ausfallen sollte. Je nach Konfiguration der ausgestellten Zertifikate kann es hier zu stark abweichendem Verhalten kommen.

Wie wird die Seriennummer eines Zertifikats gebildet?

Nachfolgend eine Erklärung, wie die Seriennummern ausgestellter Zertifikate gebildet werden, und wie das Verhalten der Zertifizierungsstellen angepasst werden kann.

Funktionstest durchführen für den Registrierungsdienst für Netzwerkgeräte (NDES)

Nach der Installation eines Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES), oder nach umfangreicheren Wartungsarbeiten sollte ein ausgiebiger Funktionstest erfolgen, um sicherzustellen, dass alle Komponenten wie gewünscht arbeiten.

Den Network Device Enrollment Service (NDES) für die Verwendung mit einem Alias konfigurieren

Nachfolgend wird beschrieben, welche Schritte erforderlich sind, um den Registrierungs dienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) für die Verwendung mit einem Alias zu konfigurieren.

Mit dem Begriff Alias ist gemeint, dass der Dienst nicht mit dem Namen des Servers, auf welchem er installiert ist, aufgerufen wird, sondern mit einem hierbon unabhängigen, generischen Namen. Die Verwendung eines Alias ermöglicht, dass der Dienst zu einem späteren Zeitpunkt auf ein anderes System umgezogen werden kann, ohne dass die neue Adresse allen Teilnehmern mitgeteilt werden muss.

Konfigurieren der Zertifizierungsstelle auf einen statischen Port (RPC-Endpunkt)

In der Standardkonfiguration ist die Zertifikatbeantragungs-Schnittstelle der Zertifizierungsstelle darauf konfiguriert, dynamische Ports für die eingehenden RPC/DCOM Verbindungen auszuhandeln (näheres siehe Artikel "Benötigte Firewallregeln für Active Directory Certificate Services").

Netzwerkprotokoll	Ziel-Port	Protokoll
TCP	135	RPC Endpoint Mapper
TCP	49152-65535	RPC dynamische Ports

Diese Konfiguration ist nicht in jeder Unternehmens-Umgebung realisierbar. Oftmals gibt es restriktive Firewallregeln, welche die Verwendung dynamischer Netzwerk-Ports nicht erlauben.

In einem solchen Fall muss die Zertifizierungsstelle auf einen statischen Port konfiguriert werden.

Abfrage der konfigurierten RPC-Endpunkte einer Zertifizierungsstelle

Es ist jedoch auch möglich, die Zertifizierungsstelle auf einen statischen Port zu konfigurieren (siehe Artikel "Konfigurieren der Zertifizierungsstelle auf einen statischen Port (RPC-Endpunkt)").

Nachfolgend wird beschrieben, wie die aktuelle Konfiguration der Zertifizierungsstelle überprüft werden kann.

Einordnung der ADCS-Komponenten in das administrative Schichtenmodell (Administrative Tiering Model)

Implementiert man neben den Active Directory Certificate Services auch das administrative Schichtenmodell (Administrative Tiering Model) für den Active Directory Verzeichnisdienst, stellt sich die Frage der Zuordnung der einzelnen PKI-Komponenten in dieses Modell, um eine zielgerichtete Sicherheitshärtung vornehmen zu können.