Active Directory-Zertifikatdienste-Container verstehen

Wenn Sie jemals eine Windows-Umgebung verwaltet und sich gefragt haben, wo genau die Konfiguration Ihrer Zertifizierungsstelle innerhalb von Active Directory gespeichert ist, sind Sie nicht allein. Die meisten Fachleute wissen, dass Active Directory Certificate Services (AD CS) die Zertifikatsausstellung übernimmt, doch die zugrundeliegende Infrastruktur, insbesondere die spezialisierten Container, die die PKI-Konfiguration in Ihrer Gesamtstruktur speichern, bleibt oft ein Rätsel.

Dieser Leitfaden führt Sie durch alle wichtigen Container, die AD CS verwendet, erklärt, was darin gespeichert wird, warum das wichtig ist, wie man es anzeigt und was schiefgehen kann, wenn es falsch konfiguriert oder vernachlässigt wird.

Kurzantwort: Was sind AD CS-Container?

AD CS-Container Es handelt sich um spezialisierte Objekte in Active Directory, die die gesamte PKI-Konfiguration für eine Windows-Gesamtstruktur speichern. Sie befinden sich unter CN=Public Key Services, CN=Services, CN=Configuration und werden auf jeden Domänencontroller repliziert. Sie enthalten vertrauenswürdige Stammzertifizierungsstellen, Zwischenzertifizierungsstellenzertifikate, CRLs, Zertifikatvorlagen, Registrierungen für den Registrierungsdienst, NTAuth-Vertrauensstellungen, KRA-Zertifikate und OID-Definitionen.

Wichtige Erkenntnisse

• Die gesamte AD CS-Konfiguration wird im Konfigurationsnamenskontext unter gespeichert. CN=Public Key Services Die Änderungen werden gesamtstrukturweit auf alle Domänencontroller repliziert. Eine Änderung an einer Zertifikatvorlage oder einem CRL-Verteilungspunkt auf einem Domänencontroller wirkt sich schließlich auf alle Domänencontroller in jeder Domäne der Gesamtstruktur aus. Dieser gesamtstrukturweite Geltungsbereich bedeutet, dass jede Fehlkonfiguration ein gesamtstrukturweites Sicherheitsereignis darstellt und nicht nur ein domänenspezifisches.
• Die acht Container erfüllen jeweils eine spezifische Rolle im Zertifikatslebenszyklus: Zertifizierungsstellen (vertrauenswürdige Stammzertifizierungsstellen), AIA (Zwischenzertifizierungsstellenzertifikate für den Aufbau der Zertifikatskette), CDP (CRLs für die Sperrprüfung), Registrierungsdienste (Zertifizierungsstellenerkennung für die automatische Registrierung), Zertifikatvorlagen (Bauplan für jeden Zertifikatstyp), NTAuthCertificates (für die Smartcard-Anmeldung autorisierte Zertifizierungsstellen), KRA (Schlüsselwiederherstellungsagentenzertifikate) und OID (benutzerdefinierte Richtlinienkennungen). Die Kenntnis der jeweiligen Funktion der Container ist Voraussetzung für die Diagnose von PKI-Fehlern.
• Zertifikatvorlagen stellen das höchste Risiko dar. Die von SpecterOps dokumentierte Angriffsklassifizierung ESC1 bis ESC16 zeigt, dass falsch konfigurierte Vorlagen es Benutzern ohne Administratorrechte ermöglichen können, innerhalb von 60 Sekunden Domänenadministratorrechte zu erlangen. NTAuthCertificates und der Container „Zertifizierungsstellen“ stellen das zweithöchste Risiko dar: Das Hinzufügen eines unbefugten Eintrags etabliert entweder eine vertrauenswürdige Zertifizierungsstelle oder ermöglicht die unautorisierte Anmeldung mit Smartcards für die gesamte Gesamtstruktur.
• Abgelaufene oder fehlende CRL-Daten im CDP-Container führen dazu, dass alle von der betroffenen Zertifizierungsstelle ausgestellten Zertifikate in jeder Anwendung und jeder Domäne der Gesamtstruktur nicht validiert werden können. Laut der DigiCert Trust Pulse Survey (Juli 2025) verzeichneten 45 Prozent der Unternehmen im Vorjahr Ausfallzeiten aufgrund von Zertifikatsproblemen. Die meisten operativen PKI-Fehler lassen sich auf veraltete, fehlende oder abgelaufene Daten in einem dieser Container zurückführen.
• PKIView (pkiview.msc), ADSI Edit (adsiedit.msc) und certutil.exe sind drei sich ergänzende Tools zur Untersuchung und Verwaltung von AD CS-Containern. PKIView bietet Einblick in den Zustand der Container, ADSI Edit ermöglicht den Zugriff auf Rohattribute und certutil bietet Befehlszeilenfunktionen für die Veröffentlichung und Überprüfung. Keines dieser Tools allein deckt jedoch alle Funktionen ab.

Für wen sind AD CS-Container relevant?

AD CS-Container fallen in erster Linie in die Verantwortung des PKI-Administrators, doch die Auswirkungen auf Sicherheit und Compliance erstrecken sich auf jedes Team, das auf zertifikatsbasierte Authentifizierung, Verschlüsselung oder Codesignierung angewiesen ist.

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI-Administratoren	Eigene tägliche Containeroperationen: Veröffentlichung von CA-Zertifikaten und CRLs, Überwachung des CRL-Ablaufs mit PKIView, Verwaltung von Zertifikatvorlagenkonfigurationen, Diagnose von Registrierungsfehlern aufgrund veralteter Enrollment-Services-Objekte und Überprüfung der Kettenbildung mit certutil -verify -urlfetch	Richten Sie ein vierteljährliches Container-Audit mit certutil -store -enterprise Root, certutil -store -enterprise NTAuth und certutil -v -dstemplate für alle veröffentlichten Vorlagen ein; verbinden Sie die Container-Integritätsüberwachung mit CertSecure Manager zur automatisierten Benachrichtigung über bevorstehendes Ablaufdatum und zur Lebenszyklusverfolgung aller ausgestellten Zertifikate
Sicherheitsarchitekten	Verantwortlich für die Zugriffskontrollrichtlinie für jeden Container und die Überprüfung der ESC-Angriffsfläche für Zertifikatvorlagen; nicht autorisierte Einträge in NTAuthCertificates oder Zertifizierungsstellen etablieren eine betrügerische CA-Vertrauensstellung für die gesamte Gesamtstruktur; falsch konfigurierte Vorlagen sind der Hauptvektor für die Eskalation von AD CS-Berechtigungen (ESC1 bis ESC16).	Führen Sie Locksmith oder PSPKIAudit vierteljährlich für den Zertifikatvorlagencontainer aus, um ESC-Fehlkonfigurationen aufzulisten; fordern Sie SIEM-Benachrichtigungen bei Änderungsereignissen für CN=NTAuthCertificates und CN=Certification Authorities an; überprüfen Sie CBOM Secure Kryptografische Bestandsaufnahme zusammen mit den Ergebnissen der Containerprüfung, um zu bestätigen, dass keine unautorisierten Zertifikate im Zertifikatsbestand des Unternehmens vorhanden sind.
Active Directory-Teams	Sie sind verantwortlich für die zugrunde liegenden Objektberechtigungen und den Replikationsstatus im Konfigurationsnamenskontext; Verzögerungen bei der AD-Replikation können dazu führen, dass PKIView eine gerade veröffentlichte CRL rot anzeigt; Berechtigungsänderungen an PKI-Containerobjekten können die CA-Veröffentlichung oder die automatische Registrierung unbemerkt unterbrechen.	Beziehen Sie CN=Public Key Services in die AD-Replikationsüberwachung ein; fordern Sie die Genehmigung des AD-Teams an, bevor Änderungen an den ACLs der PKI-Container im Konfigurationsnamenskontext vorgenommen werden; stellen Sie sicher, dass das CA-Dienstkonto Schreibberechtigungen für die CDP- und AIA-Container besitzt und dass keine Fehler bei der Berechtigungsvererbung aufgetreten sind.
Compliance-Teams	Es muss nachgewiesen werden, dass Containeränderungen protokolliert und überprüft werden; CA-Ereignis-IDs 4899 und 4900 (Vorlage geändert, Vorlagensicherheit aktualisiert) sowie AD-Objektänderungsereignisse auf NTAuthCertificates und Zertifizierungsstellen sind die primären Prüfnachweise für PKI-bezogene Kontrollen gemäß SOC 2, ISO 27001, NIST SP 800-53 SC-12 und SC-17 sowie FedRAMP.	Stellen Sie sicher, dass die CA-Audit-Protokollierung aktiviert ist (certutil -setreg ca\auditfilter 127) und an das SIEM weitergeleitet wird. Fügen Sie die vierteljährlichen Container-Audit-Ergebnisse (certutil -store -enterprise Root-Ausgabe im Vergleich zum genehmigten CA-Inventar) den Compliance-Nachweispaketen bei. Dokumentieren Sie alle Containeränderungen mit Vorher-/Nachher-Status in den Änderungsmanagement-Aufzeichnungen.
CISOS	AD CS-Container repräsentieren die gesamtstrukturweite Vertrauensinfrastruktur. Ein einziger unautorisierter Eintrag in NTAuthCertificates oder Zertifizierungsstellen kann jede Domäne in der Gesamtstruktur gefährden. Der Ablauf von Zertifikaten zählt zu den drei größten Sorgen von CISOs (56.6 Prozent, DigiCert Trust Pulse Survey, Juli 2025). Da die CA/Browser Forum-Abstimmung SC-081v3 die Gültigkeitsdauer öffentlicher TLS-Zertifikate bis März 2029 auf 47 Tage reduziert, werden Betriebsausfälle aufgrund veralteter Containerdaten häufiger auftreten.	Eine formale Richtlinie zur Containerverwaltung von AD CS als Teil der PKI-Programmdokumentation vorschreiben; vierteljährliche ESC-Vorlagenprüfungen und SIEM-Integration zur Benachrichtigung über Containeränderungen finanzieren; bewerten, ob der operative Aufwand für selbstverwaltetes AD CS einen Wechsel zu einem verwaltetes PKI-Modell mit automatisierter Containerzustandsüberwachung

Container-Operationsreferenz: Befehle, Validierungsprüfungen, häufige Fehler und Rollback

Verwenden Sie diese Tabelle, bevor Sie in einer Produktionsumgebung einen Containervorgang durchführen. Jede Zeile ordnet eine Containeraufgabe ihrer Voraussetzung, dem genauen Befehl, der Validierungsprüfung zur Bestätigung der korrekten Ausführung, dem häufigsten Fehler, auf den zu achten ist, und der Rollback-Aktion zu.

Aufgabe	Voraussetzung	Befehl	Validierungsprüfung	Häufiger Fehler	Rollback
Veröffentlichung des Root-CA-Zertifikats bei Zertifizierungsstellen	Administratorrechte im Unternehmen; CA-Zertifikatsdatei (.cer) von der Management-Workstation aus zugänglich; Test außerhalb der Produktionsumgebung abgeschlossen	certutil -dsPublish -f RootCA.cer RootCA	certutil -store -enterprise Root Die neue Zertifizierungsstelle wird angezeigt; PKIView zeigt Grün für die Stammzertifizierungsstelle an; Clients in allen Domänen vertrauen den von der Zertifizierungsstelle ausgestellten Zertifikaten nach der Aktualisierung der Gruppenrichtlinie.	Zugriff verweigert: Benutzer ist kein Unternehmensadministrator; falsche Zertifikatsdatei: Die Veröffentlichung eines SubCA-Zertifikats im Root-Container schlägt ohne Fehlermeldung fehl; beheben Sie das Problem, indem Sie den Zertifikatstyp vor der Veröffentlichung mit certutil -dump überprüfen.	Entfernen Sie den fehlerhaften Eintrag in ADSI Edit unter CN=Zertifizierungsstellen; oder verwenden Sie certutil -dsDel, um das veraltete Objekt zu entfernen.
Veröffentlichung des Zwischenzertifikats für CA an AIA	Unternehmensadministratorrechte; Zwischenzertifizierungsstellenzertifikatsdatei (.cer); Domänenkonnektivität	certutil -dsPublish -f SubCA.cer SubCA	certutil -store -enterprise SubCA zeigt das Zertifikat an; certutil -verify -urlfetch cert.cer Auf einem Clientrechner wird der Kettenaufbau fehlerfrei abgeschlossen.	Fehler beim Aufbau der Replikationskette in domänenübergreifenden Szenarien nach der Veröffentlichung: Verzögerung bei der AD-Replikation; warten Sie, bis die Replikation abgeschlossen ist, oder führen Sie `repadmin /syncall` aus; falls der Fehler weiterhin besteht, überprüfen Sie, ob die AIA-URL in den ausgestellten Zertifikaten auf diesen Container verweist.	Löschen Sie den fehlerhaften AIA-Eintrag in ADSI Edit unter CN=AIA; veröffentlichen Sie das korrekte Zertifikat erneut.
CRL-Veröffentlichung im CDP-Container erzwingen	Führen Sie den Befehl auf dem CA-Server selbst aus; das CA-Dienstkonto muss Schreibberechtigungen für CN=CDP in AD besitzen.	certutil -crl (auf dem CA-Server)	PKIView zeigt für alle CRL-Verteilungspunkte Grün an; certutil -store -enterprise ldap:///CN=<CA Name>,CN=CDP,... Gibt die aktuelle CRL mit einem zukünftigen Ablaufdatum zurück	Die CRL-Veröffentlichung schlägt ohne Fehlermeldung fehl: Das CA-Dienstkonto hat keine Schreibberechtigung für den CDP-Container; überprüfen Sie dies mit certutil -getreg ca\DSPublish; der Eintrag 22 im CA-Ereignisprotokoll meldet einen verweigerten Zugriff, was auf ein Berechtigungsproblem für das CDP-AD-Objekt hinweist.	Ein Fehler bei der CRL-Veröffentlichung ist nicht destruktiv; beheben Sie das Berechtigungsproblem und führen Sie certutil -crl erneut aus; ein Rollback ist nicht erforderlich, da CRLs nur angehängt werden.
Fügen Sie eine Zertifizierungsstelle zu NTAuthCertificates hinzu.	Unternehmensadministratorrechte; CA-Zertifikatsdatei (.cer); Genehmigung der Änderungskontrolle; Test außerhalb der Produktionsumgebung abgeschlossen	certutil -dsPublish -f CA.cer NTAuthCA	certutil -store -enterprise NTAuth Die neue Zertifizierungsstelle wird aufgelistet; nach Ausführung von certutil -pulse auf den Domänencontrollern ist die Anmeldung mit Smartcards unter Verwendung von Zertifikaten dieser Zertifizierungsstelle erfolgreich.	Zugriff verweigert: NTAuthCertificates erfordert Unternehmensadministratorrechte, nicht Domänenadministratorrechte. Nach dem Hinzufügen schlägt die Smartcard-Anmeldung weiterhin fehl: certutil -pulse wurde noch nicht auf allen Domänencontrollern ausgeführt; erzwingen Sie die Aktualisierung der Gruppenrichtlinie auf dem Domänencontroller mit gpupdate /force.	Entfernen Sie den Eintrag mithilfe von ADSI Edit: Suchen Sie nach CN=NTAuthCertificates, bearbeiten Sie das Attribut cACertificate und entfernen Sie den entsprechenden Zertifikatsbinärwert. Führen Sie anschließend auf den Domänencontrollern certutil -pulse aus.
Prüfzertifikatvorlagen für ESC-Fehlkonfigurationen	Domänenbenutzer mit Lesezugriff auf AD-PKI-Container; certutil verfügbar; Überprüfung in einer Nicht-Produktionsumgebung vor jeglicher Fehlerbehebung empfohlen.	certutil -v -dstemplate (alle Vorlagen) oder certutil -v -dstemplate <TemplateName> (Einzelvorlage)	Die Ausgabe zeigt die Werte für msPKI-Certificate-Name-Flag, msPKI-Private-Key-Flag, pKIExtendedKeyUsage und msPKI-Enrollment-Flag an; überprüfen Sie diese anhand der Checkliste ESC1 bis ESC16; Locksmith oder PSPKIAudit generieren für jeden Befund ein Skript zur Behebung der Mängel.	Zugriff verweigert: Dem Benutzer fehlen die Leserechte für CN=Zertifikatvorlagen; erforderlich ist mindestens ein Domänenbenutzer mit Leseberechtigung für den Vorlagencontainer; certutil -dstemplate liefert keine Ausgabe: Es sind keine Vorlagen auf einer Zertifizierungsstelle veröffentlicht.	Fehlkonfigurationen von Vorlagen werden durch Ändern der Vorlageneigenschaften in certtmpl.msc behoben; ein direktes Rollback über certutil ist nicht möglich; der Vorlagenzustand vor Änderungen an ACLs oder Flags muss stets dokumentiert werden.
Überprüfen Sie den PKI-Integritätszustand über alle Container hinweg.	RSAT- oder AD CS-Tools installiert; Domänenkonnektivität; PKIView.msc verfügbar	Führen Sie pkiview.mscKlicken Sie mit der rechten Maustaste auf Enterprise PKI und wählen Sie „AD-Container verwalten“.	Alle CA-Knoten zeigen grüne Häkchen an; keine gelben oder roten Symbole auf CRL- oder AIA-URLs; Containerobjekte für jede CA werden in den Registrierungsdiensten, AIA, CDP und Zertifizierungsstellen angezeigt.	PKIView zeigt Rot für eine kürzlich veröffentlichte CRL an: AD-Replikationsverzögerung; führen Sie repadmin /showrepl aus, um den Replikationsstatus zu überprüfen; warten Sie auf die Replikation oder erzwingen Sie sie mit repadmin /syncall /Ade	Nicht zutreffend: PKIView ist schreibgeschützt; die Behebung des Problems erfolgt über certutil oder ADSI Edit, je nach dem identifizierten Problem.

Was ist AD CS und warum sind Container wichtig?

Active Directory Certificate Services (AD CS) ist eine in Microsoft integrierte Public-Key-Infrastruktur (PKI) . Sie ermöglicht es Unternehmen, digitale Zertifikate für Anwendungen wie Benutzerauthentifizierung, Computerauthentifizierung, verschlüsselte E-Mails, SSL/TLS, Smartcard-Anmeldung und Codesignierung auszustellen und zu verwalten.

AD CS nutzt Active Directory intensiv, um Konfigurationen zu speichern, Zertifikate zu veröffentlichen, Sperrinformationen zu verteilen und Clientcomputern mitzuteilen, welchen Zertifizierungsstellen sie vertrauen können. Die Container, die wir untersuchen werden, sind die spezifischen Bereiche innerhalb von Active Directory, in denen all diese Informationen gespeichert sind.

Der Konfigurationsbenennungskontext

Alle AD CS-Konfigurationsdaten werden im Konfigurationsnamenskontext unter dem Container „Dienste für öffentliche Schlüssel“ gespeichert und auf jeden Domänencontroller in der gesamten Gesamtstruktur repliziert. Dies ist ein wichtiger Punkt. Im Gegensatz zum Domänennamenskontext (der auf eine einzelne Domäne beschränkt ist) gelten Konfigurationsdaten für die gesamte Gesamtstruktur. Das bedeutet, dass eine Änderung an einer Zertifikatvorlage oder einem CRL-Verteilungspunkt auf einem Domänencontroller schließlich auf allen Domänencontrollern der Gesamtstruktur sichtbar wird.

CN=Public Key Services, CN=Services, CN=Configuration, DC={Gesamtstruktur-Stammdomäne}

Alles, was in diesem Artikel besprochen wird, liegt irgendwo unterhalb dieses Pfades. Warum also ist der Blick auf das gesamte Waldgebiet von Bedeutung?

• Jede Fehlkonfiguration in AD CS-Containern wirkt sich auf alle Domänen in der Gesamtstruktur aus.
• Die Berechtigungen für diese Container werden von Unternehmensadministratoren auf Gesamtstrukturebene festgelegt.
• Eine kompromittierte Zertifizierungsstelle oder eine bösartige Zertifikatsvorlage kann die Berechtigungen über Domänengrenzen hinweg ausweiten.
• Aus diesem Grund ist die Härtung von AD CS-Containern ein Sicherheitsanliegen für die gesamte Gesamtstruktur und nicht nur ein Problem einzelner Domänen.

Die wichtigsten AD CS-Container, einer nach dem anderen

Lassen Sie uns jeden Container im Detail durchgehen.

Zertifizierungsstellen-Container

Dieser Container enthält die Zertifikate aller Stammzertifizierungsstellen, denen Ihre Organisation vertraut. Bei der Installation einer Enterprise- Stammzertifizierungsstelle veröffentlicht der Installationsassistent das Zertifikat automatisch hier. Windows-Clients lesen diesen Container dann beim Erstellen von Zertifikatsketten. Dadurch erkennen sie, ob sie einem von Ihrer internen Zertifizierungsstelle ausgestellten Zertifikat vertrauen können.

Sie können das Stammzertifikat der Zertifizierungsstelle manuell in diesem Container installieren, indem Sie den folgenden Befehl certutil.exe ausführen:

certutil -dspublish -f RootCA

Ersetzen Sie <PathToCertFile.cer> durch den tatsächlichen Pfad und Dateinamen des Zertifikats. Beachten Sie, dass eine Kopie des Stammzertifikats der Zertifizierungsstelle ebenfalls im AIA-Container installiert ist.

Man kann es sich als die offizielle Liste vertrauenswürdiger Zertifizierungsstellen vorstellen, die die gesamte Gesamtstruktur erbt. Wenn ein Benutzer ein von Ihrer internen Zertifizierungsstelle signiertes Zertifikat erhält, überprüft Windows diesen Container (neben anderen Speicherorten), um zu bestätigen, dass die ausstellende Zertifizierungsstelle vertrauenswürdig ist.

Sicherheitshinweis
Standardmäßig können hier nur Unternehmensadministratoren Objekte hinzufügen oder entfernen.
Achten Sie auf das Hinzufügen nicht autorisierter Root-CA-Zertifikate; dies ist ein klassischer Angriffsversuch, um eine betrügerische vertrauenswürdige CA zu etablieren.
Verwenden Sie den Befehl: Verwenden Sie certutil -store -enterprise Root, um die aktuell vertrauenswürdigen Stammzertifizierungsstellen aufzulisten und mit den erwarteten Zertifizierungsstellen zu vergleichen.

Registrierungsdienstecontainer

Dies ist einer der betrieblich wichtigsten Container. Jede Unternehmenszertifizierungsstelle, die Ihrer Gesamtstruktur beitritt, veröffentlicht hier ein Objekt. Wenn ein Windows-Client ein Zertifikat beantragen möchte, fragt er diesen Container ab, um zu ermitteln, welche Zertifizierungsstellen verfügbar sind und welche Vorlagen jede Zertifizierungsstelle unterstützt.

Dieser Erkennungsprozess ist die Grundlage für die automatische Zertifikatsregistrierung. Wenn eine Gruppenrichtlinie die automatische Zertifikatsregistrierung auslöst, prüft Windows den Container „Registrierungsdienste“, um die zu kontaktierende Zertifizierungsstelle und die anzufordernden Vorlagen zu ermitteln. Fehlt hier ein gültiges Objekt, funktioniert die automatische Registrierung nicht.

Das pKIEnrollmentService-Objekt enthält außerdem ein Attribut namens certificateTemplates, das eine Liste der von der jeweiligen Zertifizierungsstelle veröffentlichten Vorlagen enthält. Wenn Sie also genau wissen möchten, welche Vorlagen eine bestimmte Zertifizierungsstelle aktuell anbietet, müssen Sie hier nachsehen.

Anzeige in PKIView.msc

Überprüfen Sie Registrierungsdiensteobjekte mit dem Enterprise PKI MMC-Snap-In.

• Öffnen Sie PKIView.msc (starten Sie pkiview.msc über das Startmenü).
• Die Baumansicht links zeigt Ihre Enterprise-PKI-Hierarchie.
• Jeder CA-Knoten repräsentiert ein Objekt im Enrollment Services-Container.
• Klicken Sie mit der rechten Maustaste auf eine CA und wählen Sie „Eigenschaften“, um deren Attribute anzuzeigen.
• Rechtsklick auf Enterprise PKI und wählen Sie AD-Container verwalten, um einen tiefergehenden Zugriff zu erhalten.

Zertifikatvorlagen-Container

Zertifikatvorlagen definieren die Baupläne für jeden Zertifikatstyp, den Ihre PKI ausstellen kann. Die Vorlage legt die Schlüsselverwendung, die Gültigkeitsdauer, die kryptografischen Algorithmen, das Format des Antragstellernamens, die erweiterte Schlüsselverwendung, die Einstellungen für die automatische Registrierung und die Berechtigung zur Anforderung dieses Zertifikatstyps fest.

Alle Vorlagen, unabhängig davon, ob sie aktuell auf einer Zertifizierungsstelle veröffentlicht sind oder nicht, befinden sich in diesem Container. Die Unterscheidung zwischen „Vorlage vorhanden“ und „Vorlage veröffentlicht“ ist wichtig: Eine Vorlage kann sich in diesem Container befinden, ohne dass sie von einer Zertifizierungsstelle aktiv angeboten wird. Erst wenn ein Administrator einer Zertifizierungsstelle die Vorlage veröffentlicht, wird sie im Registrierungsdienstobjekt für diese Zertifizierungsstelle aufgeführt.

Warum Vorlagen ein Sicherheitsrisiko darstellen

Zertifikatvorlagen stellen in den meisten AD CS-Bereitstellungen die größte Angriffsfläche dar. Untersuchungen von Sicherheitsunternehmen (insbesondere die von SpecterOps dokumentierten Schwachstellenklassen ESC1 bis ESC16 ) haben gezeigt, dass falsch konfigurierte Vorlagen es Benutzern ohne Administratorrechte ermöglichen, Zertifikate anzufordern, die Domänenadministratorrechte gewähren.

Zu den gefährlichsten Fehlkonfigurationen gehören:

• Authentifizierten Benutzern die Registrierung für eine Vorlage ermöglichen, bei der die Genehmigung durch den Manager deaktiviert ist.
• Der Weg zu Alternative Subjektnamen (SANs) vom Antragsteller in sensiblen Vorlagen bereitgestellt
• Gewährung von Einschreibungsrechten an zu breite Gruppen
• Das Aktivieren des Mark-Privatschlüssels als exportierbares Flag ist unnötig.
• Verwendung von Zertifikatvorlagen mit dem Flag ENROLLEE_SUPPLIES_SUBJECT auf Vorlagen mit hohen Berechtigungen

Wichtiger Sicherheitshinweis: Authentifizierte Benutzer sollten niemals die Berechtigung zum Registrieren für Vorlagen erhalten, die nicht von einem Manager genehmigt wurden.

AIA-Container (Zugriff auf behördliche Informationen)

Der AIA-Container speichert die Zertifikate untergeordneter (Zwischen-)Zertifizierungsstellen sowie alle von Ihrer Organisation eingerichteten Kreuzzertifikate. Wenn ein Clientrechner ein Zertifikat empfängt und dieses validieren muss, erstellt er eine Zertifikatskette vom Endbenutzerzertifikat bis zu einer vertrauenswürdigen Stammzertifizierungsstelle. Falls der Client das Zertifikat der Zwischenzertifizierungsstelle nicht bereits lokal zwischengespeichert hat, verwendet er die im Zertifikat eingebettete AIA-URL, um es abzurufen.

Die LDAP-URL, die auf diesen Container verweist, ist üblicherweise in der AIA-Erweiterung jedes Zertifikats eingebettet, das Ihre untergeordnete Zertifizierungsstelle ausstellt. Wenn also ein Rechner anfragt, wo er das Zertifikat der ausstellenden Zertifizierungsstelle findet, folgt er dieser LDAP- URL und landet in diesem Container.

Überprüfen Sie AIA mit certutil: Prüfen Sie über die Befehlszeile, was im AIA-Container veröffentlicht ist.

• Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten
• Run: certutil -store -enterprise SubCA
• Hier werden alle Zertifikate im AD-basierten AIA-Container aufgelistet.
• Vergleichen Sie die Ausgabe mit Ihren erwarteten Zwischenergebnissen.
• So veröffentlichen Sie ein fehlendes Zertifikat: certutil -dsPublish -f SubCA.cer SubCA

Ein häufiges Problem: Fehlt dem AIA-Container das Zwischenzertifikat der Zertifizierungsstelle, schlägt die Zertifikatskettenvalidierung bei Clients in anderen Domänen oder Gesamtstrukturen fehl, die das Zertifikat nicht zwischengespeichert haben. Dies äußert sich oft in SSL-Fehlern auf Websites oder Authentifizierungsfehlern in domänenübergreifenden Szenarien.

Testkettenaufbau
Nach der Veröffentlichung in AIA sollte die Validierung der Kette immer von einem Client-Rechner aus getestet werden:
certutil -verify -urlfetch
Dieser Befehl simuliert den kompletten Aufbau der Kette einschließlich des Abrufs von AIA- und CDP-URLs, sodass Sie überprüfen können, ob alles korrekt aufgelöst wird.

CDP (CRL-Verteilungspunkt) Container

Der CDP-Container ist der Speicherort Ihrer Zertifikatssperrlisten (CRLs) innerhalb von Active Directory. Eine CRL ist eine signierte Liste mit Seriennummern von Zertifikaten, die vor ihrem Ablaufdatum widerrufen wurden. Wenn eine Clientanwendung ein Zertifikat validiert, prüft sie unter anderem, ob dieses Zertifikat widerrufen wurde. Dazu lädt sie die CRL von einer CDP-URL herunter.

Active Directory ist einer von mehreren unterstützten CDP-Speicherorten (HTTP ist ein weiterer gängiger). Die LDAP-URL, die auf diesen Container verweist, ist in der CDP-Erweiterung jedes ausgestellten Zertifikats eingebettet. Bei der Zertifikatsvalidierung folgt der Client dieser URL und ruft die CRL ab, um zu prüfen, ob das Zertifikat widerrufen wurde.

Jede Zertifizierungsstelle erhält einen eigenen Untercontainer innerhalb von CN=CDP. In diesem Untercontainer finden Sie Folgendes:

• Basis-CRL: Die vollständige Liste der widerrufenen Zertifikate, die regelmäßig veröffentlicht wird.
• Delta CRL: Eine kleinere, inkrementelle Liste der Änderungen seit der letzten Basis-CRL

Manuelles Veröffentlichen einer CRL: Erzwingen der CRL-Veröffentlichung im AD CDP-Container.

• Öffnen Sie auf dem CA-Server eine Eingabeaufforderung mit Administratorrechten.
• Run: certutil -crl um die CRL-Veröffentlichung zu erzwingen
• Dadurch werden sowohl die Basis- als auch die Delta-CRL an alle konfigurierten CDP-Standorte veröffentlicht.
• Bitte überprüfen Sie mit: certutil -store -enterprise ldap:///CN=<CA Name>,CN=CDP,...
• In PKIView.msc zeigt ein gelbes Symbol neben einer Zertifizierungsstelle an, dass die Gültigkeit der Sperrliste bald abläuft.

Ansicht aus ADSI Edit:

Abgelaufene CRLs machen alles kaputt.
Eine abgelaufene oder fehlende CRL führt dazu, dass alle von dieser Zertifizierungsstelle ausgestellten Zertifikate bei der Validierung fehlschlagen.
Anwendungen interpretieren das Nichtabrufen einer CRL als einen schwerwiegenden Fehler, es sei denn, sie sind so konfiguriert, dass Fehler bei der Widerrufsprüfung zugelassen werden.
Überwachen Sie den Ablauf von CRLs proaktiv. Typische Konfiguration: Basisgültigkeit der CRL 7 Tage, Gültigkeit der Delta-CRL 1 Tag, Veröffentlichung alle 12 Stunden.
Richten Sie Überwachungsalarme ein, die ausgelöst werden, wenn das CRL-Ablaufen innerhalb von 24 Stunden bevorsteht.

NTAuthCertificates Store

Obwohl NTAuthCertificates wie ein Container klingt, handelt es sich tatsächlich um ein einzelnes AD-Objekt mit einem mehrwertigen Attribut. Es enthält die CA-Zertifikate für jede Zertifizierungsstelle, die zur Ausstellung von Zertifikaten für die Smartcard-Anmeldung und die Schlüsselarchivierung berechtigt ist.

Das ist aus folgendem Grund wichtig: Wenn sich ein Benutzer mit einer Smartcard bei Windows anmeldet, prüft der Domänencontroller nicht nur, ob das Zertifikat auf der Karte gültig und vertrauenswürdig ist. Er prüft auch, ob die ausstellende Zertifizierungsstelle (CA) in der Liste der NTAuthCertificates aufgeführt ist. Ist die ausstellende CA dort nicht aufgeführt, wird die Anmeldung verweigert, selbst wenn das Zertifikat an sich gültig ist.

Unternehmenszertifizierungsstellen fügen sich während der Installation automatisch zu NTAuthCertificates hinzu. Zertifizierungsstellen von Drittanbietern oder eigenständige Zertifizierungsstellen, die für Smartcard-Zertifikate verwendet werden, müssen manuell hinzugefügt werden.

NTAuthCertificates über die Befehlszeile prüfen: Prüfen Sie, welche CA-Zertifikate im NTAuthCertificates-Speicher vorhanden sind.

• Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten
• Run: certutil -store -enterprise NTAuth
• Diese Liste enthält alle CA-Zertifikate, die sich aktuell in NTAuthCertificates befinden.
• Um eine fehlende CA hinzuzufügen: certutil -dsPublish -f <CA-cert.cer> NTAuthCA
• Nach dem Hinzufügen Folgendes ausführen: certutil -pulse auf DCs, um eine Aktualisierung der Richtlinien zu erzwingen

Hochwertiges Ziel für Angreifer
Durch das Hinzufügen eines gefälschten CA-Zertifikats zu NTAuthCertificates kann ein Angreifer gefälschte Zertifikate für die Smartcard-Anmeldung erstellen.
Dies ist eine bekannte Persistenztechnik. Überwachen Sie dieses Objekt auf unerwartete Änderungen.
Warnung bei Änderungen an: CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,
Regelmäßige Prüfungen: Vergleichen Sie die aktuellen cACertificate-Werte mit Ihrem bekannten, einwandfreien CA-Bestand.

KRA (Key Recovery Agent) Container

Der KRA-Container speichert die KRA-Zertifikate. Wenn eine Zertifizierungsstelle für die Schlüsselarchivierung konfiguriert ist, verwendet sie den öffentlichen Schlüssel eines KRA-Zertifikats (gespeichert in diesem Container), um die archivierte Kopie des privaten Benutzerschlüssels zu verschlüsseln. Nur der Inhaber des privaten KRA-Schlüssels kann diesen archivierten Schlüssel später entschlüsseln und wiederherstellen.

Dies ist ein sensibler Container. Wenn ein Angreifer die Kontrolle über den privaten Schlüssel eines KRA-Zertifikats erlangt, kann er alle archivierten privaten Benutzerschlüssel entschlüsseln und potenziell auf jahrelang verschlüsselte E-Mails, Dokumente und andere sensible Daten zugreifen. KRA-Zertifikate sollten mit denselben physischen Sicherheitsvorkehrungen wie CA-Schlüssel gespeichert werden, idealerweise geschützt durch ein FIPS 140-3 Level 3 HSM . Für Organisationen, die kryptografische Assets in großem Umfang verwalten, bietet CBOM Secure eine Bestandsübersicht, die neben CA-Zertifikaten und Endbenutzerzertifikaten auch das Ablaufdatum und die Klassifizierung der Schlüsselspeicherung von KRA-Zertifikaten umfasst.

OID (Objektkennung) Container

Objektkennungen (OIDs) sind weltweit eindeutige numerische Kennungen, die nahezu allen Elementen der PKI zugewiesen werden: Algorithmen, Zertifikatserweiterungen, Richtlinien und mehr. Im OID-Container in Active Directory registriert Ihre Organisation benutzerdefinierte OIDs, die in Zertifikatvorlagen für Anwendungsrichtlinien (Wofür ist das Zertifikat gültig?) und Ausstellungsrichtlinien (Unter welchen Bedingungen wurde dieses Zertifikat ausgestellt?) verwendet werden.

Wenn Sie im MMC-Snap-In „Zertifikatvorlagen“ eine benutzerdefinierte Anwendungsrichtlinienerweiterung erstellen, wird das resultierende OID-Objekt hier gespeichert. Dieser Container dient AD CS auch dazu, die für Menschen lesbaren Namen zu ermitteln, die für diese OIDs in der Benutzeroberfläche der Zertifikatvorlagen angezeigt werden sollen.

Dieser Container birgt zwar ein geringeres direktes Sicherheitsrisiko als die anderen, dennoch lohnt sich eine Überprüfung, um sicherzustellen, dass keine unerwarteten OID-Definitionen hinzugefügt wurden, die das Verhalten der Vorlage auf subtile Weise beeinflussen könnten.

Tools zum Anzeigen und Verwalten von AD CS-Containern

Nachdem wir nun wissen, was sich in den einzelnen Behältern befindet, wollen wir uns damit befassen, wie man damit interagiert. Ihnen stehen drei Hauptwerkzeuge zur Verfügung, die jeweils für unterschiedliche Aufgaben geeignet sind.

PKIView.msc: Der benutzerfreundliche Einstiegspunkt

PKIView (auch Enterprise PKI MMC-Snap-In genannt) bietet Ihnen den einfachsten Überblick über den Zustand Ihrer PKI. Es zeigt Ihnen die CA-Hierarchie, kennzeichnet CRL- und AIA-Zugriffsprobleme mit farbcodierten Statussymbolen und ermöglicht Ihnen die Navigation in den AD-Containern, ohne dass Sie LDAP-Pfade kennen müssen.

PKIView.msc: Enterprise-PKI-Integritätsansicht

Was Sie sehen werden, wenn Sie pkiview.msc auf einem in eine Domäne eingebundenen Computer starten:

• Start > Ausführen > pkiview.msc
• Linke Spalte: Hierarchische Baumstruktur Ihrer Enterprise-PKI (Root-CA oben, untergeordnete CAs darunter)
• Grünes Häkchen = Container/URL ist intakt und erreichbar
• Gelbes Warnsymbol = Die Sperrfrist (CRL) läuft bald ab oder die URL reagiert langsam
• Rotes X-Symbol = CRL- oder AIA-URL ist nicht erreichbar oder abgelaufen
• Klicken Sie mit der rechten Maustaste auf Enterprise PKI > AD-Container verwalten, um Containerobjekte anzuzeigen, zu löschen oder zu aktualisieren.

PKIView bietet Ihnen zwar eine gute Übersicht, aber nur begrenzte Möglichkeiten zur Änderung – abgesehen vom Löschen veralteter Einträge. Für eine umfassendere Verwaltung benötigen Sie die folgenden Tools.

ADSI Edit: Der Low-Level Explorer

ADSI Edit (adsiedit.msc) ist ein Verzeichniseditor, mit dem Sie beliebige Objekte in Active Directory, einschließlich der PKI-Container, durchsuchen und bearbeiten können. Stellen Sie sich ADSI Edit als Datei-Explorer für Active Directory vor. Große Macht bringt große Verantwortung mit sich: Eine fehlerhafte Änderung in ADSI Edit kann Ihre PKI auf schwer rückgängig zu machende Weise beschädigen. Testen Sie daher immer zuerst in einer Testumgebung.

ADSI-Bearbeitung: Navigation zu Public-Key-Diensten

Durchsuchen Sie die vollständige PKI-Containerstruktur:

• Start > Ausführen > adsiedit.msc
• Klicken Sie im linken Bereich mit der rechten Maustaste auf ADSI Edit > Verbinden mit
• Wählen Sie im Dropdown-Menü mit dem bekannten Namenskontext „Konfiguration“ aus > OK
• Erweitern: Konfiguration[DC=…] > CN=Konfiguration > CN=Dienste > CN=Öffentliche Schlüsseldienste
• Sie sehen nun alle Untercontainer: AIA, CDP, Zertifizierungsstellen, Registrierungsdienste, KRA, OID
• Klicken Sie mit der rechten Maustaste auf ein beliebiges Objekt und wählen Sie „Eigenschaften“, um alle seine Attribute und Werte anzuzeigen.

Certutil.exe: Das Arbeitstier der Kommandozeile

Certutil ist das Kommandozeilen-Werkzeug für alles rund um Active Directory Container Service (AD CS). Es kann AD CS-Container lesen und beschreiben, Zertifikate und CRLs veröffentlichen, Zertifikatsketten überprüfen und vieles mehr. Hier sind die am häufigsten verwendeten Befehle für die Containerverwaltung:

Aufgabe	Befehl
Liste der vertrauenswürdigen Stammzertifizierungsstellen in AD	certutil -store -enterprise Root
Liste der CAs mit mittlerer Qualifikation in AIA	certutil -store -enterprise SubCA
Liste der NTAuth-Zertifikate	certutil -store -enterprise NTAuth
Veröffentlichen Sie ein Stammzertifikat einer Zertifizierungsstelle in AD	certutil -dsPublish -f RootCA.cer RootCA
Veröffentlichen Sie ein Zwischenzertifikat der Zertifizierungsstelle.	certutil -dsPublish -f SubCA.cer SubCA
Fügen Sie eine Zertifizierungsstelle zu NTAuthCertificates hinzu.	certutil -dsPublish -f CA.cer NTAuthCA
CRL in AD erzwingen	certutil -crl (auf dem CA-Server ausführen)
Zertifikatskette mit URL-Abruf überprüfen	certutil -verify -urlfetch cert.cer
CA-Konfigurationsinformationen anzeigen	certutil -CAInfo

Kurzübersicht

Hier finden Sie eine zusammenfassende Übersicht aller in diesem Leitfaden behandelten AD CS-Container:

Container	Zweck	Risiko bei Kompromittierung
Zertifizierungsstellen	Vertrauenswürdige Stammzertifizierungsstellenzertifikate für den Gesamtbestand	Vertrauensverhältnis zu einer betrügerischen Stammzertifizierungsstelle eingerichtet
Registrierungsdienste	Unternehmenszertifizierungsstellen zur Registrierung/automatischen Registrierung verfügbar	Automatische Anmeldung defekt; gefälschte Zertifizierungsstelle veröffentlicht
Zertifikatvorlagen	Vorlage für Zertifikatstypen, die die PKI ausstellen kann	Rechteausweitung durch ESC-Angriffe
AIA	Mittlere CA-Zertifizierungen für den Aufbau von Handelsketten	Fehler bei der Zertifikatsvalidierung
CDP	Zertifikatssperrlisten für alle Zertifizierungsstellen	Widerrufsprüfung fehlgeschlagen; veralteter Widerruf.
NTAuthCertificates	Zertifizierungsstellen, die für die Anmeldung mit Smartcards autorisiert sind	Unerlaubte Smartcard-Anmeldung bei Zertifizierungsstelle; Authentifizierungsumgehung
KRA	Zertifikate des Schlüsselwiederherstellungsagenten	Massenentschlüsselung archivierter Benutzerschlüssel
OID	Benutzerdefinierte OID-Definitionen für Richtlinien	Manipulation des Vorlagenverhaltens

Wie Verschlüsselungsberatung Ihnen bei Ihrer PKI helfen kann

Encryption Consulting bietet spezialisierte Dienstleistungen zur Identifizierung von Schwachstellen und zur Risikominderung durch PKI-Services . Unsere strategische Beratung richtet PKI-Lösungen an den Unternehmenszielen aus, steigert die Effizienz und minimiert Kosten. Durch die Partnerschaft mit Encryption Consulting können Unternehmen das volle Potenzial von PKI-Lösungen ausschöpfen und so konkrete finanzielle Vorteile erzielen, während gleichzeitig hohe Sicherheitsstandards gewährleistet werden.

Encryption Consulting PKIaaS bietet eine flexible und sichere PKI-Lösung, die auf Ihre spezifischen Bedürfnisse zugeschnitten ist. Zu den Vorteilen zählen anpassbare Optionen, hohe Sicherheitsstandards und ein risikoarmes Management. PKIaaS automatisiert die Schlüssel- und Zertifikatsverwaltung, reduziert den Betriebsaufwand und minimiert das Risiko menschlicher Fehler. Darüber hinaus verbessert es die Netzwerktransparenz durch die Zertifikatspflicht für den Zugriff. Wir übernehmen den Aufbau der PKI-Infrastruktur und die Führung und Verwaltung der PKI-Umgebung (Cloud, Hybrid oder On-Premises) Ihres Unternehmens.

CertSecure Manager bietet umfassende Funktionen für das Lebenszyklusmanagement. Von der Erkennung und Inventarisierung über die Ausstellung, Bereitstellung, Verlängerung und den Widerruf bis hin zum Reporting – CertSecure ist eine Komplettlösung. Intelligente Berichtserstellung, Benachrichtigungen, Automatisierung, automatische Bereitstellung auf Servern und Zertifikatsregistrierung sorgen für zusätzliche Funktionen und machen CertSecure zu einem vielseitigen und intelligenten Werkzeug. Für Unternehmen, die vollständige kryptografische Transparenz anstreben, bietet CBOM Secure ein Inventar der Maschinenidentitäten, das AD CS-Container und Cloud-CA-Quellen umfasst. Im Zuge der Vorbereitung auf die Post-Quantum-Migration nach der Veröffentlichung von NIST FIPS 203, 204 und 205 (13. August 2024) unterstützen die EC PQC Readiness- Assessment-Services Unternehmen bei der Planung des Übergangs von AD CS-Zertifikatvorlagen und Registrierungs-Workflows zu ML-DSA-basierten Zertifikaten. Beratung hierzu erhalten Sie im PQC Center of Excellence.

Fazit

AD CS-Container sind die stillen Helden (und gelegentlichen Übeltäter) der Windows-PKI. Bei korrekter Konfiguration und ausreichender Absicherung arbeiten sie unauffällig im Hintergrund und ermöglichen die automatische Zertifikatsregistrierung, die Anmeldung per Smartcard, die SSL-Validierung und vieles mehr. Werden sie jedoch falsch konfiguriert, vernachlässigt oder angegriffen, können die Folgen von ärgerlichen Problemen (Fehler bei der automatischen Registrierung) bis hin zu katastrophalen Folgen (Rechteausweitung im gesamten Netzwerk) reichen.

Die wichtigsten Erkenntnisse aus diesem Leitfaden:

• Die gesamte AD CS-Konfiguration befindet sich im Namenskontext „Konfiguration“ und wird gesamtstrukturweit repliziert.
• Jeder Container erfüllt im Zertifikatslebenszyklus einen bestimmten Zweck; verstehen Sie die Rolle jedes einzelnen.
• Zertifikatvorlagen stellen die größte Angriffsfläche dar; überprüfen Sie sie regelmäßig.
• NTAuthCertificates und der KRA-Container sind wichtige Ziele, die eine strenge Zugriffskontrolle und Überwachung erfordern.
• PKIView, ADSI Edit und certutil bieten Ihnen drei sich ergänzende Möglichkeiten, Container zu untersuchen und zu verwalten.
• Die meisten PKI-Probleme lassen sich auf veraltete, fehlende oder abgelaufene Daten in einem dieser Container zurückführen.

Sich die Zeit zu nehmen, die Struktur Ihres PKI-Containers wirklich zu verstehen, ist eine der besten Investitionen in die Zuverlässigkeit und Sicherheit Ihrer Windows-Umgebung. Eine gut verstandene PKI ist eine PKI, die sich angemessen verteidigen lässt.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Artikel „Active Directory Certificate Services Containers verstehen“?

Die gesamte AD CS-Konfiguration befindet sich an einem zentralen Ort in der Gesamtstruktur: CN=Public Key Services im Namenskontext „Konfiguration“. Diese Konfiguration wird auf jeden Domänencontroller in der Gesamtstruktur repliziert. Sie umfasst vertrauenswürdige Stammzertifizierungsstellen, Zwischenzertifizierungsstellenzertifikate, CRLs, Zertifikatvorlagen, Registrierungen des Registrierungsdienstes, NTAuth-Vertrauensstellungen, KRA-Zertifikate und OID-Definitionen. Jede Fehlkonfiguration in einem dieser Container wirkt sich auf alle Domänen in der Gesamtstruktur aus und macht sie daher zu einer kritischen Sicherheits- und Betriebsverantwortung für jedes PKI-Team in Unternehmen.

Warum sind AD CS-Container für PKI-Teams in Unternehmen wichtig?

AD CS-Container bilden das operative Rückgrat der Windows-PKI. Automatische Registrierung, Smartcard-Anmeldung, Zertifikatskettenaufbau und CRL-Validierung setzen voraus, dass die Container korrekt befüllt und zugänglich sind. Laut der DigiCert Trust Pulse Survey (Juli 2025) verzeichneten 45 Prozent der Unternehmen im Vorjahr Ausfallzeiten aufgrund von Zertifikatsproblemen. Der Ablauf von Zertifikaten zählte mit 56.6 Prozent zu den drei größten Sorgen von CISOs. Die meisten dieser Ausfälle lassen sich auf veraltete, fehlende oder abgelaufene Daten in einem dieser Container zurückführen.

Welche Risiken steigen, wenn AD CS-Container manuell verwaltet oder vernachlässigt werden?

Die manuelle Verwaltung birgt vier Risikokategorien: Betriebsrisiken (abgelaufene CRLs verhindern die gesamte Zertifikatsvalidierung), Sicherheitsrisiken (unautorisierte Einträge in NTAuthCertificates oder Zertifizierungsstellen ermöglichen das Vertrauen in unautorisierte Zertifizierungsstellen), Compliance-Risiken (fehlende Protokollierung von Containeränderungen gemäß SOC 2, ISO 27001 und NIST SP 800-53) und Angriffsflächenrisiken (falsch konfigurierte Zertifikatvorlagen ermöglichen die Rechteausweitung von ESC1 bis ESC16). Alle vier Risiken verstärken sich mit zunehmender Anzahl an Zertifikaten und sinkender Gültigkeitsdauer auf 47 Tage gemäß CA/Browser Forum Ballot SC-081v3.

Welche Teams sollten für die AD CS-Container-Governance verantwortlich sein?

PKI-Administratoren sind für den täglichen Containerbetrieb verantwortlich: Veröffentlichung von Zertifizierungsstellen (CAs) und Sperrlisten (CRLs), Überwachung des CRL-Ablaufs, Verwaltung von Vorlagenkonfigurationen und Diagnose von Registrierungsfehlern. Sicherheitsarchitekten verantworten die Zugriffskontrollrichtlinie für jeden Container und die Überprüfung der Angriffsfläche des Enterprise Security Centers (ESC). Active Directory-Teams sind für die zugrunde liegenden Objektberechtigungen und die Replikationsstabilität im Konfigurationsnamenskontext zuständig. Compliance-Teams stellen sicher, dass die Audit-Nachweise dokumentiert sind, die belegen, dass Containeränderungen protokolliert und überprüft werden. CISOs verantworten die Governance-Richtlinie, die regelmäßige Container-Audits und SIEM-Warnungen bei unautorisierten Containeränderungen vorschreibt.

Wie stellen AD CS-Container eine Verbindung zum Zertifikatslebenszyklusmanagement her?

AD CS-Container dienen als Datenquelle für Zertifikatslebenszyklusmanagement-Plattformen (CLM), um die PKI-Umgebung zu verstehen. CLM-Plattformen wie CertSecure Manager nutzen den Container „Enrollment Services“, um verfügbare Zertifizierungsstellen (CAs) und veröffentlichte Vorlagen zu ermitteln. Der CDP-Container legt den Speicherort der CRL-Validierungsdaten fest. Der Container „Certificate Templates“ definiert die Richtlinien, die die CLM-gesteuerte automatische Registrierung befolgt. Ohne genaue und aktuelle Daten in diesen Containern arbeitet die CLM-Automatisierung mit veralteten Informationen und kann Zertifikatslücken übersehen.

Wie sollten Organisationen den Erfolg im AD CS-Containermanagement messen?

Wichtige Kennzahlen: Gültigkeitspuffer für CRL (die Basis-CRL hat immer noch eine Gültigkeit von mehr als 24 Stunden; die Delta-CRL hat immer noch eine Gültigkeit von mehr als 6 Stunden); Abdeckung der Containeränderungsprüfung (100 Prozent der Änderungen an NTAuthCertificates, Zertifizierungsstellen und Zertifikatvorlagen werden innerhalb von 24 Stunden protokolliert und überprüft); Vollständigkeit der ESC-Vorlagenprüfung (certutil -v -dstemplate wird vierteljährlich für alle veröffentlichten Vorlagen ausgeführt, wobei die Ergebnisse überprüft werden); und Erfolgsrate der automatischen Registrierung (keine Geräte, bei denen die automatische Registrierung aufgrund veralteter oder fehlender Daten im Enrollment Services-Container fehlschlägt).

Was sollte bei AD CS-Containern regelmäßig geprüft oder überwacht werden?

Kontinuierliche Überwachung: CA-Ereignis-IDs 4899 und 4900 (Zertifikatvorlage geändert und Vorlagensicherheit aktualisiert); AD-Objektänderungsereignisse unter CN=NTAuthCertificates und CN=Certification Authorities; CRL-Ablauf über PKIView oder automatisierte Überwachung mit Benachrichtigung, wenn die Gültigkeit der Basis-CRL unter 24 Stunden fällt. Vierteljährliche Prüfung: Führen Sie `certutil -store -enterprise Root` aus und vergleichen Sie die Ergebnisse mit dem genehmigten CA-Inventar; führen Sie `certutil -v -dstemplate` für alle veröffentlichten Vorlagen aus und prüfen Sie auf ESC-Fehlkonfigurationen; stellen Sie sicher, dass keine unerwarteten CA-Zertifikate in NTAuthCertificates oder im Container „Certification Authorities“ vorhanden sind.

Wie wirken sich AD CS-Container auf Cloud-, Hybrid- oder Multi-CA-PKI-Umgebungen aus?

In Hybridumgebungen bleiben AD CS-Container die maßgebliche Quelle für die lokale PKI-Konfiguration. Cloud-native Zertifizierungsstellen (CAs) werden in diesen Containern jedoch nicht abgebildet. Zertifikate von Cloud-CAs oder externen PKIaaS-Anbietern erscheinen nicht im AD CS-Registrierungsdienste-Container und sind für certutil und PKIView nicht sichtbar. Für eine vollständige kryptografische Bestandsaufnahme in Hybridumgebungen bietet CBOM Secure die Erkennung von Maschinenidentitäten über lokale AD CS- und Cloud-CA-Quellen hinweg. In Umgebungen mit mehreren CAs enthalten die CDP- und Registrierungsdienste-Container separate Unterobjekte pro CA, die jeweils unabhängig überwacht werden müssen.

Welche Voraussetzungen müssen für die Verwaltung von AD CS-Containern erfüllt sein?

Voraussetzungen: Administratorrechte (Unternehmensadministrator oder Domänenadministrator) zum Anzeigen und Ändern von Objekten im Konfigurationsnamenskontext; Installation von ADSI Edit über RSAT oder AD CS-Tools; certutil.exe (standardmäßig in Windows Server und Windows 10/11 integriert); Installation von PKIView.msc über AD CS-Verwaltungstools; Domänenverbindung von der Verwaltungs-Workstation zu einem Domänencontroller; und eine aktuelle Sicherung der AD CS-Konfiguration (certutil -backupDB auf jeder Zertifizierungsstelle) vor jeglichen Änderungen. Alle Änderungen an NTAuthCertificates, Zertifizierungsstellen und Zertifikatvorlagen sollten zunächst in einer Testumgebung geprüft werden.

Auf welche häufigen Fehler sollten Administratoren bei der Verwaltung von AD CS-Containern achten?

Häufige Fehler: CRL-Veröffentlichung schlägt fehl, da dem CA-Dienstkonto die Schreibberechtigung für den CDP-Container fehlt (überprüfen Sie dies mit `certutil -getreg ca\DSPublish`); `certutil -dsPublish` gibt beim Hinzufügen zu NTAuthCertificates eine Zugriffsverweigerung zurück (erfordert Unternehmensadministratorrechte, nicht Domänenadministratorrechte); automatische Registrierungsfehler aufgrund eines veralteten Registrierungsdiensteobjekts nach einer CA-Umbenennung oder -Neuinstallation (löschen Sie das veraltete Objekt in ADSI Edit und lassen Sie die CA die Veröffentlichung erneut durchführen); Fehler beim Aufbau der Zertifikatskette in domänenübergreifenden Szenarien aufgrund fehlender Zwischenzertifikate von Zertifizierungsstellen in AIA (veröffentlichen Sie mit `certutil -dsPublish -f SubCA.cer SubCA`); und PKIView zeigt eine soeben veröffentlichte CRL rot an (oftmals eine Verzögerung der AD-Replikation; erzwingen Sie die Replikation mit `repadmin /syncall` oder überprüfen Sie dies mit `repadmin /showrepl`). Organisationen, die eine Migration zu Post-Quantum-Zertifikaten planen, finden im PQC Center of Excellence Anleitungen zur ML-DSA-Vorlagenkonfiguration in AD CS.