Active Directory-Zertifikatdienste-Container verstehen

Wenn Sie jemals eine Windows-Umgebung verwaltet und sich gefragt haben, wo genau Ihre Zertifizierungsstellenkonfiguration innerhalb von Active Directory gespeichert ist, sind Sie nicht allein. Die meisten Fachleute wissen, dass Active Directory-Zertifikatdienste (AD CS) Die Ausstellung von Zertifikaten wird zwar übernommen, aber 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.

Was du lernen wirst

• Was AD CS-Container sind und wo sie sich in Active Directory befinden
• Zweck der einzelnen Container: Zertifizierungsstellen, AIA, CDP, Registrierungsdienste, NTAuth-Zertifikate, KRA, OID und mehr
• Wie man Container mit PKIView, ADSI Edit und certutil anzeigt und verwaltet

Was ist AD CS und warum sind Container wichtig?

Active Directory Certificate Services (AD CS) ist der in Microsoft integrierte Dienst Public-Key-Infrastruktur (PKI)-LösungEs ermöglicht Organisationen die Ausstellung und Verwaltung digitaler Zertifikate für Anwendungen wie Benutzerauthentifizierung, Computerauthentifizierung, verschlüsselte E-Mails, SSL/TLS, Smartcard-Anmeldung und Codesignierung.

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 für öffentliche Schlüsseldienste 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 wir in diesem Artikel besprechen, liegt irgendwo unterhalb dieses Pfades. Warum also ist die Sicherheit des gesamten Waldes so wichtig?

• 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 CA-Zertifikate aller Stammzertifizierungsstellen, denen Ihre Organisation vertraut. Bei der Installation einer Enterprise-Version StammzertifizierungsstelleDer Einrichtungsassistent veröffentlicht das CA-Zertifikat automatisch hier. Windows-Clients lesen diesen Container dann beim Erstellen von Zertifikatsketten. Dadurch erkennen sie, ob sie einem von Ihrer internen CA 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  mit tatsächlichem Pfad und Zertifikatsnamen. Beachten Sie, dass auch eine Kopie des Stammzertifikats der Zertifizierungsstelle 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 Speichern), um zu bestätigen, dass die ausstellende Zertifizierungsstelle vertrauenswürdig ist.

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

Zertifikat Vorlagen stellen in den meisten AD CS-Implementierungen die größte Angriffsfläche dar. Untersuchungen von Sicherheitsfirmen (insbesondere der bekanntesten) belegen dies. ESC1 bis ESC16 Die von SpecterOps dokumentierten Schwachstellenklassen haben gezeigt, dass falsch konfigurierte Vorlagen es Benutzern ohne entsprechende Berechtigungen 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 unnötige Aktivieren des Flags „Privaten Schlüssel als exportierbar markieren“
• Verwendung von Zertifikatvorlagen mit dem Flag ENROLLEE_SUPPLIES_SUBJECT auf Vorlagen mit hohen Berechtigungen

Kritische Sicherheitswarnung

Weisen Sie niemals „Authentifizierten Benutzern“ die Berechtigung zum Registrieren für Vorlagen zu, denen die Genehmigung durch einen Manager fehlt.

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 typischerweise in der AIA-Erweiterung jedes Zertifikats eingebettet, das Ihre untergeordnete Zertifizierungsstelle ausstellt. Wenn also ein Rechner fragt: „Wo erhalte ich das Zertifikat der Zertifizierungsstelle, die dieses Zertifikat ausgestellt hat?“, folgt daraus, dass LDAP URL und landet in diesem Container.

Überprüfen Sie die AIA mit certutil.

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

• Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten
• Ausführen: 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 im AIA-Container das Zertifikat der Zwischenzertifizierungsstelle, 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.

CDP (CRL-Verteilungspunkt) Container

Der CDP-Container ist der Speicherort Ihrer Zertifikatssperrlisten (CRLs) innerhalb von Active Directory. Eine CRL ist im Grunde eine signierte Liste von Seriennummern für Zertifikate, die vor ihrem Ablaufdatum widerrufen wurden. Wenn eine Clientanwendung ein Zertifikat validiert, prüft sie unter anderem, ob das 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

Manuelle Veröffentlichung einer CRL

CRL-Veröffentlichung im AD CDP-Container erzwingen

• Öffnen Sie auf dem CA-Server eine Eingabeaufforderung mit Administratorrechten.
• Führen Sie folgenden Befehl aus: 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.
• Überprüfen Sie dies mit: certutil -store -enterprise ldap:///CN= ,CN=CDP,….
• In PKIView.msc zeigt ein gelbes Symbol neben einer Zertifizierungsstelle an, dass die Gültigkeit der Sperrliste bald abläuft.

Ansicht aus dem ADSI.edit

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

Überprüfen Sie, welche CA-Zertifikate im NTAuthCertificates-Speicher vorhanden sind.

• Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten
• Führen Sie folgenden Befehl aus: certutil -store -enterprise NTAuth
• Diese Liste enthält alle CA-Zertifikate, die sich aktuell in NTAuthCertificates befinden.
• Um eine fehlende Zertifizierungsstelle hinzuzufügen: certutil -dsPublish -f NTAuthCA
• Nach dem Hinzufügen führen Sie auf den Domänencontrollern folgenden Befehl aus: `certutil -pulse`, um die Richtlinienaktualisierung zu erzwingen.

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 Schlüssels des Benutzers 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.

OID (Objektkennung) Container

Objektkennungen (OIDs) 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, sprechen wir darüber, 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 Edit – 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ü „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

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:

Kurzübersicht

Hier finden Sie eine zusammenfassende Übersicht aller von uns behandelten AD CS-Container:

Wie kann Verschlüsselungsberatung Ihnen bei Ihrer PKI helfen?

Encryption Consulting bietet spezialisierte Dienstleistungen zur Identifizierung von Schwachstellen und zur Risikominimierung durch Bereitstellung PKI-DiensteUnsere strategische Beratung richtet PKI-Lösungen an den Unternehmenszielen aus, steigert die Effizienz und minimiert die Kosten. Durch die Partnerschaft mit Encryption Consulting können Unternehmen das volle Potenzial von PKI-Lösungen ausschöpfen, spürbare finanzielle Vorteile erzielen und gleichzeitig strenge Sicherheitsmaßnahmen einhalten.

Verschlüsselungsberatung PKIaaS bietet eine flexible und sichere PKI-Lösung, die auf Ihre spezifischen Bedürfnisse zugeschnitten ist und Vorteile wie anpassbare Optionen, hohe Sicherheitsstandards und einen risikoarmen Managementansatz bietet. PKIaaS automatisiert Schlüssel- und Zertifikatsverwaltungsaufgaben, reduziert den Betriebsaufwand und minimiert das Risiko menschlicher Fehler. Darüber hinaus verbessert es die Netzwerktransparenz durch die Anforderung von Zertifikaten für den Zugriff. PKIaaS übernimmt den Aufbau der PKI-Infrastruktur zur Leitung und Verwaltung der PKI-Umgebung (Cloud/Hybrid oder On-Premise) Ihres Unternehmens.

CertSecure Manager CertSecure bietet eine umfassende Suite von 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 Funktionalität und machen CertSecure zu einem vielseitigen und intelligenten Werkzeug.

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 einen bestimmten Zweck im Zertifikatslebenszyklus; 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 Containerstruktur Ihrer PKI 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.