Problembehandlung bei der Windows 2000 PKI

Problembehandlung bei der Windows 2000 PKIBereitstellung und der Smartcard-Anmeldung
Whitepaper
Zusammenfassung
Microsoft® Windows® 2000-Zertifikatsdienste stellen eine integrierte Infrastruktur für öffentliche Schlüssel (PKI)
bereit, mit der Kunden Informationen sicher über das Internet sowie über Extranets und Intranets austauschen
können. Dieses Whitepaper beschreibt das Optimieren der PKI-Bereitstellung und die Diagnose und Behandlung
von Problemen mit PKI für Windows 2000-Zertifikatsdienste.
Inhalt
Einführung
Optimieren der PKI-Bereitstellung
Durch Active Directory-Replikation verursachte Latenzzeit
Durch automatische Registrierung und Gruppenrichtlinien verursachte Latenzzeit
Durch Zertifikatsvorlagen verursachte Latenzzeit
Auswirkungen der Gültigkeitsdauer von Zertifikatssperrlisten auf die Zertifikatssperrung
Erhalten eines ordnungsgemäßen Autoregistrierungsverhaltens beim Deinstallieren einer Zertifizierungsstelle
Deinstallieren von Stammzertifizierungsstellen
Deinstallieren von untergeordneten Zertifizierungsstellen
Die Gruppe der Zertifikatsherausgeber
DSStore - Das neue Tool für Windows 2000 PKI
Pulsen von Autoregistrierungsereignissen zum Beschleunigen von PKI-Prozessen
Verwalten von Organisationsverzeichnissen in Active Directory
Überprüfen des Status und der Gültigkeit von Domänencontrollerzertifikaten
Überprüfen der Gültigkeit des Smartcard-Zertifikats
Auflisten von Informationen über Zertifizierungsstellen in einer Organisation
Auflisten von Informationen über die Zertifikate eines Computers
Auflisten von Informationen über Computerobjekte in einer Domäne
Hinzufügen von Nicht-Windows 2000-Zertifizierungsstellen oder Offlinezertifizierungsstellen zu
Windows 2000 PKI
Problembehandlung bei Zertifikatsketten mit DSStore
Häufig von DSStore gemeldete Verkettungsfehler
Überprüfen des Domänencontrollerzertifikats
Überprüfen des Smartcard-Zertifikats
Fehler und Fehlerbehebung bei der Smartcard-Anmeldung
Fehler: Status insufficient resources
Fehler: Revocation server offline
Fehler: Certificate has been revoked, but still can be used for smart card logon
Fehler: Client credentials could not be verified
Fehler: The security database on the server does not have a computer account for this workstation trust
relationship
Fehler: Invalid Handle
Fehler: Die Netzwerkanforderung wird nicht unterstützt
Fehler: Eine Zertifikatskette wurde zwar ordnungsgemäß verarbeitet, aber ist in einem Stammzertifikat geendet,
das keine Vertrauensstellung mit dem Vertrauensanbieter hat
Fehler und Fehlerbehebung bei der Registrierung
Fehler: Windows could not find a certification authority to process the request
Fehler: Certsrv web pages inaccessible, and Virtual Roots do not show up in Internet Services Manager
Fehler: Die Registrierung für Smartcard über die Webseiten der Registrierungsstelle schlägt mit folgendem
Hinweis fehl: "Die Zertifizierungskette wurde ordnungsgemäß verarbeitet, doch wird eines der
Zertifizierungsstellen-Zertifikate vom Richtlinienanbieter nicht für vertrauenswürdig gehalten"
Fehler: Configuration information could not be read from the domain controller, either because the machine is
unavailable, or access has been denied
Fehler: Dieser Vorgang wurde zurückgegeben, weil das Zeitlimit überschritten wurde
Fehler: Der RPC-Server ist nicht verfügbar
Fehler: Ungültiger Parameter
Zusammenfassung
Weitere Informationen
Einführung
Microsoft® Windows® 2000-Zertifikatsdienste, die zum Erstellen einer Zertifizierungsstelle für die Verwaltung der
Infrastruktur für öffentliche Schlüssel (PKI) von Windows 2000, verwendet wurden, überprüfen und
authentifizieren die Gültigkeit aller an einer elektronischen Transaktion Beteiligten. Diese Technologie ermöglicht
den sicheren Austausch von Informationen in offenen Netzwerken, wie z. B. dem Internet, Extranets und Intranets.
Dieses Whitepaper konzentriert sich auf die Bereitstellung von Informationen für Administratoren, die
Windows 2000 PKI implementieren und unterstützen.
Dieses Whitepaper stellt einen Leitfaden zu Microsoft Consulting Services (MCS) und zum Microsoft Software
Service zum Diagnostizieren von Problemen und zur Problembehandlung bei der PKI-Bereitstellung in einer
Windows 2000-Gesamtstruktur bereit. Es enthält ausführliche Informationen über DSStore (ein
Windows 2000 Resource Kit-Tool zum Identifizieren und Lösen von Problemen bei der Smartcard-Anmeldung und
bei PKI) und Strategien zum Umgang mit und Lösen von Fehlermeldungen bei der Smartcard-Anmeldung und der
Zertifikatsregistrierung. Diese Themen werden in folgenden Abschnitten behandelt:

Optimieren der PKI-Bereitstellung

DSStore - Das neue Tool für Windows 2000 PKI

Fehler und Fehlerbehebung bei der Smartcard-Anmeldung

Fehler und Fehlerbehebung bei der Registrierung
Für das Verständnis dieses Whitepapers wird vorausgesetzt, dass Sie mit dem Whitepaper
"Windows 2000 Certificate Services" (englischsprachig) vertraut sind, in dem das Entwerfen und Bereitstellen_ von
PKI für Windows 2000-Zertifikatsdienste erläutert wird. Leser, die nicht mit der Kryptografie und den PKIKonzepten vertraut sind, sollten zuerst das Whitepaper "Cryptography and PKI Basics" (englischsprachig) lesen.
Optimieren der PKI-Bereitstellung
Die erfolgreiche Leistung Ihrer PKI-Implementierung kann von einigen Überlegungen beeinflusst werden. Ein
Verständnis der folgenden Themen erweist sich beim Optimieren der PKI-Bereitstellung als hilfreich:

Durch Active Directory™-Replication verursachte Latenzzeit

Durch automatische Registrierung und Gruppenrichtlinien verursachte Latenzzeit

Durch Zertifikatsvorlagen verursachte Latenzzeit

Auswirkungen der Gültigkeitsdauer von Zertifikatssperrlisten auf die Zertifikatssperrung


Erhalten eines ordnungsgemäßen Autoregistrierungsverhaltens beim Deinstallieren einer
Zertifizierungsstelle
Die Gruppe der Zertifikatsherausgeber
Weitere Informationen zum Entwerfen der Zertifizierungsstellenhierarchie und Bereitstellen von Zertifikatsdiensten
finden Sie im Abschnitt "PKI Design and Deployment in Windows 2000" im Whitepaper
"Windows 2000 Certificate Services" (englischsprachig).
Durch Active Directory™-Replication verursachte Latenzzeit
Windows 2000-Organisationszertifizierungsstellen (die wie auch eigenständige Zertifizierungsstellen im
Whitepaper "Windows 2000 Certificate Services" [englischsprachig] beschrieben sind) vertrauen auf Container und
Objekte in Active Directory und unterliegen somit den Regeln der Active Directory-Replikation. Wenn Sie z. B. die
freigegebene Zugriffsliste (DACL)1 einer Zertifikatsvorlage ändern, ändern Sie im Prinzip eine
Sicherheitsbeschreibung2 zu einem Objekt in einem individuellen Domänencontroller. Das Objekt, an dem Sie die
DACL-Änderung vornehmen, befindet sich in dem Container, der durch den folgenden definierten Namen
identifiziert wird.
CN=Certificate Templates,CN=Public Key Services,CN=Services, CN=Configuration,DC=MeineDomaene,
DC=com
Bevor diese Änderung für eine bestimmte Zertifizierungsstelle (oder einen bestimmten Client) in Kraft tritt, muss
die Änderung in der gesamten Organisation auf dem Domänencontroller repliziert werden, von dem die
Zertifizierungsstellen (bzw. der Client) Informationen empfängt. Dies findet in der Regel relativ schnell statt, bei
einigen Replikationstopologien kann es jedoch auch länger dauern (z. B. zwischen zwei Standorten, die durch eine
periodische WAN-Verbindung getrennt sind; ein Beispiel finden Sie unten). Bei sämtlichen Verwaltungsaktionen
muss diese Latenzzeit berücksichtigt werden.
Darüber hinaus ist es in einigen Replikationstopologien möglich, dass Container- oder Objektkonflikte auftreten, die
zur Erstellung neuer Container oder Objekte mit dem Präfix CNF führen <einige #><kollidierender gängiger
Name> (CNF bedeutet Konflikt). Die gängigsten, aus dieser Kollision resultierenden Probleme tauchen in den
Zertifikatsvorlagenobjekten als Fehler auf, wenn die ersten Zertifizierungsstellen auf einer Domäne installiert
werden. Dies gilt insbesondere für Organisationen mit mehreren Standorten.
Im Fall von kollidierenden Zertifikatsvorlagen löschen Sie das Zertifikatsvorlagenobjekt mit dem Präfix CNF
einfach unter Verwendung des Snap-Ins Active Directory-Standorte und -Dienste.
Eine allgemeine Darstellung der Active Directory-Replikation in einem Windows 2000-Netzwerk erhalten Sie im
Whitepaper "Active Directory Architecture" (englischsprachig). Spezifische Informationen über die Interaktion
zwischen der Active Directory-Replikation und den Zertifikatssperrlisten von Windows 2000-Zertifikatsdiensten
finden Sie im Unterabschnitt "Certificate Revocation Lists" im Whitepaper "Windows 2000 Certificate Services"
(englischsprachig). Eine ausführliche technische Abhandlung der Replikation finden Sie im Webdokument "Active
Directory Replication" (englischsprachig).
Beispielszenario: PKI-Bereitstellung über mehrere durch langsame WAN-Verbindungen getrennte Standorte
Das Bereitstellen von PKI über mehrere durch langsame WAN-Verbindungen verbundene Standorte stellt ein
interessantes Verwaltungsproblem dar. Dieses Bereitstellungsschema ist eine Möglichkeit für den Umgang mit
Layouts, bei denen eine niedrige oder periodische Bandbreite DCOM- oder HTTP-Verbindungen zwischen den
Benutzern an Standort 1 und den Zertifizierungsstellen an Standort 2 verhindert.
Voraussetzung für die in diesem Unterabschnitt behandelte theoretische Bereitstellung ist eine Organisation mit
zwei Standorten, die durch eine periodische 56K-WAN-Verbindung getrennt sind. Es wird außerdem vorausgesetzt,
dass es an jedem Standort eine Organisationszertifizierungsstelle gibt. Damit diese Strategie funktioniert, müssen
folgende fünf Bedingungen gelten:

Alle Benutzer und Computer an Standort 1 gehören zu der Gruppe Standort 1 Requestors.

Alle Benutzer und Computer an Standort 2 gehören zu der Gruppe Standort 2 Requestors.

Alle Computer an Standort 1 gehören zu der Organisationseinheit Standort 1 Computer.

Alle Computer an Standort 2 gehören zu der Organisationseinheit Standort 2 Computer.

Sowohl Standort 1 als auch Standort 2 enthalten einen globalen Katalogserver. Beachten Sie, dass
Windows 2000-Organisationszertifizierungsstellen an jedem Standort einen Katalogserver benötigen, wenn
es zwischen den Standorten keine DCOM-Konnektivität gibt. (Der globale Katalog des Betriebssystems
Windows 2000, der beim Anmelden von Benutzern, bei Abfragen und bei der Replikation eine wichtige
Rolle spielt, ist eine Datenbank, die sich auf einem oder mehreren Domänencontrollern befindet.)
Gehen Sie folgendermaßen vor, um die Benutzer und Computer an Standort 1 so einzuschränken, dass sie sich nur
bei den Organisationszertifizierungsstellen an Standort 1 registrieren können:
1.
Starten Sie das Zertifzierungsstellen-Snap-In für die Organisationszertifizierungsstelle an Standort 1.
2.
Klicken Sie mit der rechten Maustaste auf die Zertifizierungsstelle, und wählen Sie dann Eigenschaften
aus.
3.
Klicken Sie auf die Registerkarte Sicherheit.
4.
Deaktivieren Sie für Authentifizierte Benutzer das Kontrollkästchen Registrieren.
5.
Klicken Sie auf die Schaltfläche Hinzufügen....
6.
Fügen Sie Benutzer oder Computer hinzu, die für die DACL-Liste jeder Organisationszertifizierungsstelle
ein Zertifikat von Standort 1 anfordern, und aktivieren Sie das Kontrollkästchen Registrieren.
7.
Warten Sie, bis die Replikation zwischen den Standorten in Kraft tritt.
8.
Wiederholen Sie Schritt 1 bis 7 für "Standort 2 Requestors".
Wenn die automatische Registrierung darüber hinaus nur innerhalb der Standortgrenzen 3 vorgenommen werden
soll, führen Sie die folgenden Schritte durch:
1.
Erstellen Sie für die Organisationseinheit Standort 1 Computer eine neues Gruppenrichtlinienobjekt.
(Weitere Informationen zum Verwenden der Gruppenrichtlinien von Windows 2000 finden Sie im
Whitepaper "Group Policy" [englischsprachig].)
2.
Führen Sie den Assistenten für die Einstellungen der automatischen Zertifikatsanforderung aus, um das
Autoregistrierungsobjekt für die Organisationszertifizierungsstelle an Standort 1 zu erstellen.
3.
Wiederholen Sie Schritt 1 und 2 für die Organisationseinheit Standort 2 Computer.
Durch automatische Registrierung und Gruppenrichtlinien verursachte
Latenzzeit
Der wichtigste Latenzzeittyp im Zusammenhang mit Zertifikatsdiensten ist möglicherweise die zum
Autoregistrierungsereignis gehörende Latenzzeit. Bei einem Autoregistrierungsereignis werden mehrere
Operationen ausgelöst:








Überprüfung und erneute Registrierung. Überprüfung des aktuellen Zertifikats anhand des
Autoregistrierungsobjekts und erneute Registrierung, falls erforderlich. Eine erneute Registrierung kann
aufgrund einer Zertifikatssperrung, abgelaufener Zertifikate, einer geänderten Verwendung der
Zertifikatsvorlagen oder einer Änderung beim Aussteller im Autoregistrierungsobjekt notwendig sein.
Downloaden von Stammzertifikaten. Downloaden von Stammzertifikaten aus dem Active Directorybasierten Speicher für das Stammzertifikat der Organisation in den lokalen Speicher für das
Stammzertifikat der Organisation. (Eine Beschreibung dieses Speichers finden Sie im Abschnitt "Active
Directory-Based Enterprise Root Certificate Store" in Anhang A des Whitepaper
"Windows 2000 Certificate Services" (englischsprachig).
Downloaden von Organisations-Zertifizierungsstellenzertifikaten. Downloaden von OrganisationsZertifizierungsstellenzertifikaten aus dem Active Directory-Zertifikatsspeicher in den lokalen
Zertifikatsspeicher.
Folgende Ereignisse lösen die automatische Registrierung von Computern aus:
Pulsen eines Gruppenrichtlinienereignisses. Beim Pulsen eines Gruppenrichtlinienereignisses wird die
automatische Registrierung nur nach erfolgreicher Anwendung der Richtlinie ausgelöst. Die Richtlinie
wird nur angewendet, wenn sich eine der für den fraglichen Computer geltenden Gruppenrichtlinien
geändert hat.
DSStore–pulse. Mithilfe des Dienstprogramms DSStore können Sie das Ereignis manuell pulsen
(siehe "DSStore - Das neue Tool für Windows 2000 PKI").
Nach dem Neustart. Die automatische Registrierung wird nach einem Neustarten eines Computers
automatisch ausgelöst.
Alle acht Stunden. Die automatische Registrierung wird automatisch alle acht Stunden ausgelöst.
Im Folgenden finden Sie Beispiele dazu, welche Auswirkungen die Latenzzeit bei der automatischen Registrierung
auf einen Server oder eine Arbeitsstation in einer Domäne haben kann:


Smartcard-Registrierungsstelle Wenn eine Organisationszertifizierungsstelle erst kürzlich zum PKI eines
Unternehmens hinzugefügt wurde und sie kurz danach ein Registrierungs-Agent-Zertifikat an einen
Benutzer ausgestellt hat, kann es zwischen dem Ausstellen des Registrierungs-Agent-Zertifikats und
seinem Inkrafttreten auf der Smartcard-Registrierungsstelle zu einer Verzögerung kommen. (Suchen Sie in
der Windows 2000-Onlinehilfe nach "Registrieren für Smartcard-Zertifikate", um Informationen über die
Smartcard-Registrierungsstelle zu erhalten.) Diese Verzögerung tritt auf, weil im lokalen
Zertifikatsspeicher der Zertifizierungsstelle, bei der eine Registrierung im Namen von vorgenommen
wird, möglicherweise keine Kopie des neuen Zertifikats der Organisationszertifizierungsstelle vorhanden
ist. Diese Situation erkennen Sie am Fehler 0x800b0112 ("Die Zertifizierungskette wurde ordnungsgemäß
verarbeitet, doch wird eines der Zertifizierungsstellen-Zertifikate vom Richtlinienanbieter nicht für
vertrauenswürdig gehalten"). Um dies zu beheben, pulsen Sie das Autoregistrierungsereignis (dsstore pulse) auf der Zertifizierungsstelle, für die die Operation durchgeführt wird.
Smartcard-Anmeldung. Wenn eine neu installierte Organisationszertifizierungsstelle ein Smartcard-
Anmeldezertifikat ausgestellt hat, ist den Domänencontrollern, die die Anmeldeanforderung verarbeiten,
die neue Zertifizierungsstelle möglicherweise nicht bekannt. Um dies zu beheben, pulsen Sie das
Autoregistrierungsereignis auf dem Domänencontroller.

Zertifikatsregistrierung mithilfe des Registrierungsassistenten der Zertifikatverwaltung des
Zertifikat-Snap-Ins. Damit eine Einheit über den Registrierungsassistenten der Zertifikatverwaltung bei
einer Organisationszertifizierungsstelle registriert werden kann, muss das Stammzertifikat in der Kette auf
dem Server oder der Arbeitsstation vorhanden sein (die Webregistrierung wird nicht durch diese
Anforderung eingeschränkt). Ohne das Stammzertifikat aus einer Zertifikatshierarchie ist eine
Registrierung bei einer bestimmten Zertifizierungsstelle u. U. nicht möglich. Um dieses Problem zu lösen,
warten Sie, bis die Replikation und die Autoregistrierung ausgeführt sind. Dies kann bis zu acht Stunden
dauern.
Darüber hinaus setzt der Assistent voraus, dass die zu registrierende Person Registrierungszugriff auf die
Zertifizierungsstelle und auf mindestens eine von dieser Zertifizierungsstelle ausgestellte Vorlage hat.
Durch Zertifikatsvorlagen verursachte Latenzzeit
Bei den Servern und Arbeitsstationen einer Organisation kann auch eine durch Zertifikatsvorlagen verursachte
Latenzzeit auftreten. Die Informationen zu Zertifikatsvorlagen werden in einem Cache mit einer Gültigkeitsdauer
von 10 Minuten verwaltet. Beispiele für solche zwischengespeicherten Informationen sind freigegebene
Zugriffslisten und Schlüsselverwendungen (Schlüsselverwendungen geben an, wofür ein Zertifikat verwendet wird).
Wenn dieser Cache sein Zeitlimit überschritten hat, wird er während der Registrierung von Active Directory (für
das es wie oben beschrieben eine eigene durch Replikation verursachte Latenzzeit gibt) aktualisiert.
Darüber hinaus speichern Zertifizierungsstellen Informationen zu Zertifikatsvorlagen ebenfalls in einem Cache, die
kurzfristig u. U. nicht völlig mit den freigegebenen Zugriffslisten des Caches für Zertifikatsvorlagen der
registrierten Person synchronisiert sind. Aus diesem Grund treten DACL-Änderungen an Zertifikatsvorlagen nicht
immer unmittelbar nach ihrer Anwendung in Kraft, selbst wenn die registrierte Person die Berechtigungen hat, sich
bei einem bestimmten Zertifikat zu registrieren.
Auswirkungen der Gültigkeitsdauer von Zertifikatssperrlisten auf die
Zertifikatssperrung
Wenn die zu einem Zertifikat gehörenden privaten Schlüssel beschädigt sind, wird dieses Zertifikat standardmäßig
gesperrt. Ein gesperrtes Zertifikat wird in der Sperrliste des Ausstellers dieses Zertifikats angezeigt. Sperrlisten
werden regelmäßig an verschiedenen Stellen (z. B. in Active Directory, auf einer Website oder einer Dateifreigabe)
veröffentlicht. Die Gültigkeitsdauer jeder Sperrliste entspricht ungefähr ihrem Veröffentlichungszeitraum. Der
Standard-Veröffentlichungszeitraum für Windows 2000-Zertifizierungsstellen beträgt eine Woche. Windows 2000Zertifizierungsstellen ermöglichen es dem Administrator außerdem, zu konfigurieren, wie oft Sperrlisten
veröffentlicht werden (damit kann die Gültigkeitsdauer von Sperrlisten benutzerdefiniert werden).
Wenn eine Anwendung ein Zertifikat überprüft, bestimmt sie möglicherweise mithilfe der Informationen in einer
Sperrliste, ob ein bestimmtes Zertifikat für einen bestimmten Zweck akzeptiert werden soll oder nicht. Wenn ein
Webserver z. B. SSL-Clientauthentifizierung (Secure Sockets Layer)4 anfordert, kann er überprüfen, ob das
Clientzertifikat in der Sperrliste des Ausstellers enthalten ist.
Bei der Sperrlistenüberpüfung der meisten Windows 2000-Funktionen (darunter Smartcard-Anmeldung) werden die
APIs des Zertifikatsverkettungsmoduls von Microsoft CryptoAPI 2.0 (Cryptographic Application Program
Interface) verwendet. Dies hat den potenziellen Nebeneffekt, dass die während des Verkettungsvorgangs
abgerufenen Sperrlisten im Kontext5 des Benutzers oder Computers für die Gültigkeitsdauer der Sperrliste
zwischengespeichert werden. Wenn Sperrlisten geändert wurden oder Hinzufügungen zu diesen durchgeführt
wurden, werden diese Änderungen somit erst im Verkettungsvorgang auf anderen Computern reflektiert, wenn die
lokal zwischengespeicherte Kopie der Sperrliste abgelaufen ist. Aus diesem Grund empfiehlt Microsoft, die
Gültigkeitsdauer der Sperrlisten von Zertifizierungsstellen, die für das Ausstellen von Zertifikatsvorlagen für die
Smartcard-Anmeldung und Smartcard-Benutzer verantwortlich ist, kurz zu halten (z. B. 24 Stunden). Bei einer
kurzen Gültigkeitsdauer für die Sperrlisten treten die Auswirkungen der Sperrung eines SmartcardAnmeldezertifikats deutlich schneller ein.
Wenn Netzwerkverkehr ein Problem darstellt, können Sie darüber hinaus die von dieser Zertifizierungsstelle mit
Sperrlisten von kurzer Gültigkeitsdauer ausgestellten Zertifikatsvorlagen auf die Zertifikatstypen für die SmartcardAnmeldung beschränken. Dadurch wird sichergestellt, dass das wiederholte Abrufen und Überprüfen von zu dieser
Zertifizierungsstelle gehörenden Sperrlisten nur während Anmeldeoperationen stattfindet.
Erhalten eines ordnungsgemäßen Autoregistrierungsverhaltens beim
Deinstallieren einer Zertifizierungsstelle
Halten Sie sich an einige Faustregeln, damit die PKI beim Entfernen einer Organisations- oder eigenständigen
Zertifizierungsstelle von der Domäne auch weiterhin problemlos funktioniert. Das optimale Verfahren ergibt sich
aus dem Typ der zu deinstallierenden Zertifizierungsstelle.
Wichtig Eine deinstallierte Zertifizierungsstelle veröffentlicht keine Sperrlisten mehr, und die Überprüfung von
Zertifikatsketten führt normalerweise zu dem Fehler, dass der Sperrserver offline ist. Dieser Fehler ist in einigen
Fällen gültig (z. B. bei einem Laptop, der nicht mit dem Netzwerk verbunden ist) und löst keine automatische
Registrierung für ein neues Zertifikat aus. Diese Situation kann auf Domänencontrollern ein Problem darstellen,
deren Zertifikate auf einer Arbeitsstation, auf der eine Smartcard-Anmeldung stattfindet, aufgrund der abgelaufenen
Sperrliste nicht mehr überprüft werden können.
Wenn Sie die in den folgenden beiden Unterabschnitten beschriebenen Prozeduren nicht verwenden, müssen Sie die
automatisch registrierten Zertifikate gegebenenfalls. vom Domänencontroller löschen, damit die SmartcardAnmeldung ordnungsgemäß auf einer Domäne durchgeführt wird. Siehe "Fehler: Revocation server offline" im
Abschnitt "Fehler und Fehlerbehebung bei der Smartcard-Anmeldung" sowie im Abschnitt "Überprüfen des
Domänencontrollerzertifikats".
Deinstallieren von Stammzertifizierungsstellen
Um eine Stammzertifizierungsstelle zu deinstallieren, müssen Sie das Stammzertifikat aus den Windows 2000Vertrauensstellungskombinationen entfernen. Gehen Sie dazu wie folgt vor:
1.
Entfernen Sie das Zertifikat der Stammzertifizierungsstelle aus allen manuell erstellten
Gruppenrichtlinienobjekten. Suchen Sie in der Onlinehilfe zu Windows 2000 nach "Richtlinien öffentlicher
Schlüssel", um spezifische Anweisungen zu erhalten.
2.
Entfernen Sie das Zertifikat der Stammzertifizierungsstelle aus dem Active Directory-basierten Speicher
für das Stammzertifikat der Organisation, indem Sie folgenden Befehl an der Eingabeaufforderung
ausführen:
dsstore <DN Ihrer Stammdomäne> -del
3.
Gehen Sie zum Schluss durch die Konsolenmenüs, und löschen Sie die Zertifikate, die Ihrer
Stammzertifizierungsstelle entsprechen. Alle Computer in der Domäne werden beim nächsten Pulsen des
Autoregistrierungsereignisses über diese Änderung informiert. Sie können den Vorgang beschleunigen,
indem Sie dsstore -pulse an einer Eingabeaufforderung ausführen.
Deinstallieren von untergeordneten Zertifizierungsstellen
Nach der Deinstallation der untergeordneten Zertifizierungsstelle sollte das Zertifikat vom Aussteller gesperrt
werden. Diese manuelle Sperrung erfolgt über das Zertifizierungsstellen-Snap-In der ausstellenden
Zertifizierungsstelle.
Die Verwaltung in einer Organisation wird durch Zuweisen einer zwei- oder dreistufigen
Zertifizierungsstellenhierarchie erleichtert, da es bei dieser Konfiguration eine sichere Offline-
Stammzertifizierungsstelle gibt, die nicht gefährdet werden kann, und Sie untergeordnete Zertifizierungsstellen
problemlos sperren können, bevor Sie sie deinstallieren.
Die Gruppe der Zertifikatsherausgeber
Alle Organisationszertifizierungsstellen werden bei der Installation zur Gruppe der Zertifikatsherausgeber (eine von
Windows 2000 bereitgestellte Gruppe) hinzugefügt. Standard-DACLs für Benutzerobjekte gewähren der Gruppe
der Zertifikatsherausgeber Schreibzugriff auf die Attribute userCertificate und userCert der meisten
Benutzerobjekte (Ausnahmen sind im Folgenden aufgeführt). Damit können Sie einige Zertifikatstypen für
Benutzerobjekte veröffentlichen. Bedenken Sie beim Verwenden dieser Funktion folgende Punkte:

Die Mitgliedschaft bei der Gruppe der Zertifikatsherausgeber ist auf die lokale Domäne beschränkt.
Standard-DACLs für Benutzerobjekte gewähren der Gruppe der Zertifikatsherausgeber nur von der
Domäne des Benutzers Schreibzugriff. Wenn Zertifikatsherausgeber aus einer anderen Domäne
Benutzerobjekte in einer bestimmten Domäne veröffentlichen sollen, müssen Sie den Assistenten zum
Erstellen neuer Delegierungen an den Benutzerobjekten ausführen, um bSchreibzugriff auf die Attribute
userCertificate und userCert zu gewähren.
Nicht alle Zertifikatstypen werden in Benutzerobjekten veröffentlicht. Folgende Zertifikatstypen
werden im Rahmen des Registrierungsprozesses in Active Directory-Benutzer- oder Computerobjekten
veröffentlicht:


Benutzer

Nur Benutzersignatur

Smartcard-Benutzer

EFS

Administrator

EFS-Wiederherstellung

Computer

Domänencontroller
Für die Gruppenmitgliedschaft ist nach dem Ausführen des Installationsprogramms ein Neustarten
des Computers erforderlich. Wie bei allen Gruppenmitgliedschaften ist bei der Aufnahme der Gruppe der
Zertifikatsherausgeber im Authentifizierungstoken ein Abmelden und erneutes Anmelden notwendig. Bei
Computern entspricht das Abmelden und erneute Anmelden einem Computerneustart. Die ausgestellten
Zertifikate werden erst nach dem Neustart im Benutzerobjekt in Active Directory veröffentlicht.
DSStore - Das neue Tool für Windows 2000 PKI
DSStore ist ein neues Tool im Windows 2000 Resource Kit zum Verwalten von Active Directory-basierten
Kombinationen öffentlicher Schlüssel. Es wird insbesondere zur Diagnose von Problemen mit PKI und der
Smartcard-Anmeldung verwendet. In diesem Abschnitt, der in die folgenden Unterabschnitte unterteilt ist, wird die
Funktionalität von DSStore beschrieben.

Pulsen von Autoregistrierungsereignissen zum Beschleunigen von PKI-Prozessen

Verwalten von Organisationsstämmen in Active Directory

Überprüfen des Status und der Gültigkeit von Domänencontrollerzertifikaten

Überprüfen der Gültigkeit des Smartcard-Zertifikats

Auflisten von Informationen über Zertifizierungsstellen in einer Organisation

Auflisten von Informationen über die Zertifikate eines Computers

Auflisten von Informationen über Computerobjekte in einer Domäne


Hinzufügen von Nicht-Windows 2000-Zertifizierungsstellen oder Offlinezertifizierungsstellen zu
Windows 2000 PKI
Problembehandlung bei Zertifikatsketten mit DSStore
Pulsen von Autoregistrierungsereignissen zum Beschleunigen von PKIProzessen
Verwendung: dsstore -pulse
Durch Pulsen des Autoregistrierungsereignisses können drei Prozesse gestartet werden:

Downloaden von Organisationsstämmen von Active Directory

Downloaden von Organisations-Zertifizierungsstellenzertifikaten von Active Directory

Auslösen der automatischen Registrierung von Zertifikaten
Weitere Informationen zu diesen Ereignissen finden Sie weiter oben unter "Durch automatische Registrierung und
Gruppenrichtlinien verursachte Latenzzeit".
Verwalten von Organisationsstämmen in Active Directory
Verwendung: dsstore <DN der Stammdomäne (erforderlich)> [-display | -del | -addroot]
Wenn der Administrator einer Organisation (oder der Domänenadministrator einer Stammdomäne) eine
Stammzertifizierungsstelle in einem Netzwerk installiert, wird ihr Zertifikat automatisch im Speicher für das
Stammzertifikat der Organisation in Active Directory gespeichert. (Weitere Informationen über den Standort des
Stammzertifikats finden Sie im Abschnitt "Active Directory-Based Enterprise Root Certificate Store" in Anhang A
des Whitepapers Whitepaper "Windows 2000 Certificate Services" [englischsprachig]).
Mithilfe dieser Option können Administratoren diese Zertifikate im Speicher für das Stammzertifikat der
Organisation in Active Directory anzeigen, löschen oder hinzufügen. Das Hinzufügen von Stämmen wird
ausführlicher im Abschnitt "Hinzufügen von Nicht-Windows 2000-Zertifizierungsstellen oder
Offlinezertifizierungsstellen zu Windows 2000 PKI" weiter unten behandelt.
Überprüfen des Status und der Gültigkeit von Domänencontrollerzertifikaten
Verwendung: dsstore [-domain <Zieldomäne>] -dcmon
Mit diesem Befehl können Administratoren die Existenz und die Gültigkeit von Domänencontrollerzertifikaten
überprüfen. Beim Ausführen dieses Befehls gibt es vier Optionen:
1. Display Displays DC certificates (default)
2. Chain Check chaining on DC certificates
3. Delete all Deletes *all* DC certs on all DCs
4. Delete bad Deletes *all* KDC certs which do not chain




Die Option display zeigt nur die Domänencontrollerzertifikate zu jedem Domänencontroller in einer
bestimmten Domäne an.
Die Option chain zeigt den Status der Zertifikatskette für jeden Domänencontroller in einer bestimmten
Domäne an.
Die Option delete all löscht alle Domänencontrollerzertifikate aus allen Domänencontrollern in einer
bestimmten Domäne.
Die Option delete bad löscht nur die Domänencontrollerzertifikate, die nicht ordnungsgemäß verkettet
wurden.
Achtung Dieser Befehl sollte auf einem Mitgliedsserver oder einer Arbeitsstation ausgeführt werden, da
Verkettungsfehler beim Ausführen dieses Befehls auf dem Domänencontroller u. U. maskiert werden (insbesondere,
wenn auf dem Domänencontroller eine Zertifizierungsstelle installiert ist).
Überprüfen der Gültigkeit des Smartcard-Zertifikats
Verwendung: dsstore -checksc
Sie müssen diesen Befehl bei eingesteckter Karte auf einem Computer ausführen, der mit einem funktionierenden
Smartcard-Leser ausgestattet ist. Er überprüft, ob das Smartcard-Teilsystem funktioniert und ob die korrekte
Zertifikatskette mit dem Smartcard-Zertifikat verknüpft wurde.
Weitere Informationen finden Sie weiter unten im Abschnitt "Problembehandlung bei Zertifikatsketten mit
DSStore".
Auflisten von Informationen über Zertifizierungsstellen in einer Organisation
Verwendung: dsstore -tcainfo
Mithilfe dieses Befehls können Sie den Namen der Zertifizierungsstelle, den DNS-Namen und die Zertifikatstypen
anzeigen. Hier folgt ein Beispiel der Ausgabe dieses Befehls:
Dieser Eintrag zeigt den Namen der Zertifizierungsstelle in der Domäne an.
CA Name: W2K NTDEV Ent User CA =============================
Dieser Eintrag zeigt den Namen des DNS-Computers an (wenn Sie diesen Namen nicht zum erfolgreichen
Pingen der Zertifizierungsstelle verwenden können, schlägt die Registrierung fehl, und Sie erhalten
höchstwahrscheinlich folgende Fehlermeldung: "Die Zertifizierungsstelle kann nicht erreicht werden"):
Machine Name: w2kuserca.ntdev.microsoft.com
In diesem Abschnitt erfahren Sie, welche Zertifikatstypen von einer bestimmten Zertifizierungsstelle ausgestellt
werden können und ob eine Person Zugriff auf diese Zertifizierungsstelle hat oder nicht. Der unten gezeigte
Benutzer hat keinen Zugriff auf den Zertifikatstyp Administrator:
:: Unterstützte Zertifikatsvorlagen ::
CT #1 : Nur Benutzersignatur
CT #2 : Authentifizierte Sitzung
CT #3 : Codesignatur
Kein Zugriff!
CT #4 : Vertrauenslistensignatur
Kein Zugriff!
CT #5 : Registrierungs-Agent
Kein Zugriff!
CT #6 : EFS-Wiederherstellungs-Agent
Kein Zugriff!
CT #7 : Basis-EFS
CT #8 : "Untergeordnete Zertifizierungsstelle
Kein Zugriff!
CT #9 : Administrator
Kein Zugriff!
CT #10 : Benutzer
#CTs from enum: 10
Anmerkung Sie können freigegebene Zugriffslisten von Zertifikatstypen mit dem Snap-In Active DirectoryStandorte und -Dienste ändern.
Auflisten von Informationen über die Zertifikate eines Computers
Verwendung: dsstore -entmon <Computername>
Wichtig Stellen Sie sicher, dass Sie für diese Operation einen SAM-Computer verwenden, d. h.
MeineDomaene\MeineMaschine$.
Dieser Befehl, der von einem Administrator auf dem Zielcomputer ausgeführt werden muss, zeigt folgende
Informationen zum Zielcomputer an:

Stammzertifikate der Organisation auf diesem Computer

Autoregistrierungsobjekte auf diesem Computer

Zertifikate, die auf diesem Computer automatisch registriert wurden

Gruppenmitgliedschaft auf diesem Computer
Beispielausgabe:
++++++++ MACHINE :: toddsdevx ++++++++
Enterprise Roots on machine:
NTDEV Offline SA Root
CEP Enrollment CA
Autoenrollment Object:
{25F346B2-AA63-11D2-9F27-00105A24E191}|Machine
Certificates matching autoenrollment object
Issuer:: W2K NTDEV Machine CA 2
Subject:: TODDSDEVX.ntdev.microsoft.com
1 Machine certs (0 archived) for toddsdevx
Group Memberships:
Domänen-Benutzer
Domänen-Computer
Auflisten von Informationen über Computerobjekte in einer Domäne
Verwendung: dsstore -macobj <Computername>
Wichtig Stellen Sie sicher, dass Sie für diese Operation einen SAM-Computer verwenden, d. h.
MeineDomaene\MeineMaschine$.
Es ist zwar höchst unwahrscheinlich, aber dennoch möglich, dass beim Verwenden der Active Directory-Attribute
ServicePrincipalName (SPN), DNSHostName und der Gruppenmitgliedschaftsattribute von Computerobjekten
Fehler auftreten.
Dieser Befehl ist hauptsächlich als Diagnosetool gedacht, mit dem Sie feststellen können, ob eine problematische
Smartcard-Anmeldung (oder Computerregistrierung) mit der Verwendung dieser Attribute zu tun hat.
Hinzufügen von Nicht-Windows 2000-Zertifizierungsstellen oder
Offlinezertifizierungsstellen zu Windows 2000 PKI
Verwendung:
dsstore <DN der Stammdomäne (erforderlich)> -addroot <.crt file> <Name der Zertifizierungsstelle>
dsstore <DN der Stammdomäne (erforderlich)> -addcrl <.crl file> <Name der Zertifizierungsstelle>
<Computername>
dsstore <DN der Stammdomäne (erforderlich)> -addaia <.crt file> <Name der Zertifizierungsstelle>
Sie können alle diese Optionen entweder für eine Offlinezertifizierungsstelle oder für Zertifizierungsstelle von
Drittanbietern verwenden (von denen keine in Active Directory veröffentlicht). Mit diesen Schaltern können Sie
diese Zertifizierungsstellen, die Active Directory nicht unterstützen, veranlassen, genau wie
Onlinezertifizierungsstellen in Active Directory zu veröffentlichen.
Im Folgenden werden die Aufgaben dieser Optionen erläutert:
-addroot fügt ein Zertifikat der Stammzertifizierungsstelle zum Speicher für das Stammzertifikat der Organisation
und das Zertifikat zum üblichen Verzeichnis für den Zugriff auf Stelleninformationen in Active Directory hinzu.
-addaia fügt ein Zwischenzertifikat der Zertifizierungsstelle zum üblichen Verzeichnis für den Zugriff auf
Stelleninformationen (AIA) in Active Directory hinzu.
-addcrl veröffentlicht eine Sperrliste im üblichen Verzeichnis in Active Directory.
Wenn DSStore mit diesen Optionen verwendet wird, ist die Hauptaufgabe des Programms,
Offlinezertifizierungsstellen zu einer Organisations-PKI oder eine Zertifizierungsstelle eines Drittanbieters zu einer
Organisations-PKI-Liste mit vertrauenswürdigen Stämmen hinzuzufügen, ohne sich auf den
Gruppenrichtlinienmechanismus verlassen zu müssen. Mit dem Tool DSStore können Sie Sperrlisten zum üblichen
Verzeichnis von Verteilungspunkten für Zertifikatssperrlisten (CDP) hinzufügen.
DSStore ermöglicht es dem Verkettungsmodul, Zertifikatsketten, die in einem Offlinestamm oder einer NichtWindows-Zertifizierungsstelle erstellt wurden, zu überprüfen.
An den folgenden beiden URLs werden neue Stammzertifikate zu Active Directory hinzugefügt, eines für den
Active Directory-basierten Speicher für das Stammzertifikat der Organisation und ein anderes im üblichen in AIAErweiterungen verwendeten Verzeichnis (das automatisch im Rahmen der Autoregistrierung gedownloadet wird).

Active Directory-basierter Speicher für das Stammzertifikat der Organisation:
CN=<Name der Zertifizierungsstelle>,CN=Certification Authorities,CN=Public Key
Services,CN=Services,CN=Configuration,DC=<Stammdomäne in der Organisation>,DC=com

AIA-Verzeichnis:
ldap:///CN=<Name der Zertifizierungsstelle>,CN=AIA,CN=Public Key Services,
CN=Services,CN=Configuration,DC=<Stammdomäne in der Organisation>
Neue Zertifikatssperrlisten werden an dem CDP-Verzeichnis zu Active Directory hinzugefügt:

CDP-Verzeichnis:
ldap:///CN=<Name der Zertifizierungsstelle>,CN=<Computername>, CN=CDP,CN=Public%20Key%20Services,
CN=Services,CN=Configuration,DC =<Stammdomäne in der Organisation>
Wichtig Denken Sie daran, die AIAs und CDPs von ausgestellten Zertifikaten vor dem Ausstellen von Zertifikaten
an untergeordnete Zertifizierungsstellen (mit dem MMC-Snap-In Zertifizierungsstellen) zu ändern, damit auf diese
Verzeichnisse verwiesen wird. Wenn Sie dies nicht tun, kann die resultierende Zertifikatskette nicht erstellt werden.
Weitere Informationen finden Sie in der Onlinehilfe zu Windows 2000.
Problembehandlung bei Zertifikatsketten mit DSStore
In den folgenden Unterabschnitten erfahren Sie, wie Sie Probleme bei Zertifikatsketten mithilfe von DSStore lösen.
Häufig von DSStore gemeldete Verkettungsfehler
CERT_TRUST_REVOCATION_STATUS_UNKNOWN.
Dieser Fehler hat in der Regel eine von zwei Ursachen: Entweder ist die Sperrliste abgelaufen, oder sie kann mit
den CDP-Erweiterungen in den Zertifikaten der Kette nicht mehr erreicht werden. Prüfen Sie, ob alle
Zertifizierungsstellen online sind und alle Sperrlisten erreicht werden können, und stellen Sie sicher, dass die
Sperrlisten nicht abgelaufen sind.
CERT_TRUST_IS_PARTIAL_CHAIN
Dieser Fehler gibt an, dass die Kette nicht erstellt werden kann, weil auf dem Computer, auf dem die
Kettenüberprüfung ausgeführt wird, Zertifikate fehlen oder die Zertifikate in der Kette nicht über ihre AIAErweiterungen erreicht werden können.
CERT_TRUST_IS_NOT_TIME_VALID
Dieser Fehler gibt an, dass ein oder mehrere Zertifikate in der Kette abgelaufen sind.
CERT_TRUST_IS_REVOKED
Dieser Fehler gibt an, dass ein oder mehrere Zertifikate in der Kette gesperrt wurden.
CERT_TRUST_IS_NOT_VALID_FOR_USAGE
Dieser Fehler gibt an, dass versucht wurde, ein Zertifikat für einen nicht unterstützten Zweck zu verwenden.
CERT_TRUST_IS_UNTRUSTED_ROOT
Dieser Fehler gibt an, dass die Zertifikatskette in einem nicht vertrauenswürdigen Stammzertifikat beendet wird.
Stellen Sie die Vertrauensstellung entweder manuell durch Importieren des Stammzertifikats mithilfe des ZertifikatSnap-Ins her, oder verwenden Sie bei einer Verteilung des Stammes in der gesamten Organisation die
Gruppenrichtlinie der Richtlinien öffentlicher Schlüssel oder den Active Directory-basierten Speicher für das
Stammzertifikat der Organisation.
Überprüfen des Domänencontrollerzertifikats
Folgende Schritte können nur von einem Domänenadministrator durchgeführt werden: Mithilfe dieser Schritte wird
überprüft, ob die Domänencontrollerzertifikate auf allen Domänencontrollern ordnungsgemäß verkettet werden
können. Es empfiehlt sich, diese Option auf einer Mitgliedsarbeitsstation oder einem Server auszuführen, denn
dabei wird die Kettenüberprüfung emuliert, die auf einem Smartcard-Anmeldeclient vorgenommen wird.
1.
Führen Sie dsstore –dcmon an einer Eingabeaufforderung aus.
2.
Wählen Sie Option 2 aus:
2. Chain Check chaining on DC certificates
3.
Stellen Sie sicher, dass es keine Verkettungsfehler gibt.
4.
Wenn es Verkettungsfehler gibt, führen Sie dsstore -dcmon erneut aus.
5.
Wählen Sie Option 4 aus:
4. Delete bad Deletes *all* KDC certificates which do not chain
Überprüfen des Smartcard-Zertifikats
Um Smartcard-Zertifikate auf der Arbeitsstation zu überprüfen, führen Sie Folgendes aus:
dsstore –checksc
Dabei wird der Fehlerstatus aller Elemente in der Kette gelöscht und das Zertifikat auf der Karte angezeigt. Damit
können Sie fehlende Sperrlisten oder gesperrte Zertifikate finden. Im Folgenden finden sie zwei Beispielausgaben
(Fall 1 und Fall 2):
Fall 1: Fehlende Zwischen- und Stammzertifikate
Folgende Fehlerbehebungsinformationen weisen darauf hin, dass die komplette Kette nicht erstellt werden kann,
weil die Zwischenzertifikate und das Stammzertifikat auf dem Computer, auf dem der Test ausgeführt wird, fehlen.
Dies gibt an, dass die Smartcard ordnungsgemäß funktioniert:
The Microsoft Smart Card Resource Manager is running.
Current reader/card status:
--- reader: SCM Microsystems SCR300 0
--- status: SCARD_STATE_PRESENT | SCARD_STATE_UNPOWERED
--- status: The card is available for use.
--- card:
=======================================================
Analyzing card in reader: SCM Microsystems SCR300 0
No signature cert for reader: SCM Microsystems SCR300 0
Dies gibt an, dass die Schlüssel auf dieser Karte Integrität haben:
Performing public key matching test...
Public key matching test succeeded.
Dieser Teil der Ausgabe zeigt den Status der Zertifikatskette:
Performing cert chain verification...
Chain Context
Trust Status (E=0x10040,I=0x0)
Hierbei handelt es sich um den Gesamtstatus der kompletten Kette. Beachten Sie, dass Sperrinformationen und
Elemente in der Kette fehlen. Es ist lediglich ein Endknotenzertifikat vorhanden:
CERT_TRUST_REVOCATION_STATUS_UNKNOWN
CERT_TRUST_IS_PARTIAL_CHAIN
Simple Chain Count = 1
Simple Chain [0]
Trust Status (E=0x10040,I=0x0)
CERT_TRUST_REVOCATION_STATUS_UNKNOWN
CERT_TRUST_IS_PARTIAL_CHAIN
Dies zeigt alle Elemente in der Kette an. Es ist lediglich ein Endknotenzertifikat vorhanden:
Chain Element Count = 1
Chain Element [0]
Subject::
[0,0] 2.5.4.3 (CN) Administrator
Issuer::
[0,0] 2.5.4.6 (C) US
[1,0] 2.5.4.3 (CN) ENT SUB
SerialNumber:: 61 68 BE E1 00 00 00 00 00 0E
SHA1 Thumbprint:: 02567413 D84051F1 CDCE7D5B 773BAFA9 A7302CB9
MD5 Thumbprint:: 895FD36A 2FCC8938 B26C61B9 6AC722E7
Signature Thumbprint:: C44CE505 1BC56A91 4C6BC488 CFBDF369 BC40E5F7
KeyIdentifier Thumbprint:: 059FEB98 8379EF55 1706CBA3 224A1700 9AC70D99
Key Provider:: Type: 1 Name: Gemplus GemSAFE Card CSP v1.0 Flags: 0x1
(SET_KEY_C
ONTEXT_PROP) Container: 3cbdfad8-5478-4fcd-86c2-17162ebb06fe KeySpec: 1
Dies gibt den Status der Vertrauensstellung dieses individuellen Zertifikats an:
Trust Status (E=0x40,I=0x1)
CERT_TRUST_REVOCATION_STATUS_UNKNOWN ( RevError: 80092012 )
CERT_TRUST_HAS_EXACT_MATCH_ISSUER
Chain on smart card is invalid ::
Fall 2: Das Stammzertifikat ist nicht vertrauenswürdig
Folgende Ausgabe zeigt die Ergebnisse an, die auftreten, wenn das Stammzertifikat in einer Kette nicht
vertrauenswürdig ist. Für diesen Fall wurden nur die Ketteninformationen angegeben.
Performing cert chain verification...
Chain Context
Trust Status (E=0x20,I=0x0)
Dies gibt an, dass die Kette, abgesehen vom fehlenden Stammzertifikat, in Ordnung ist:
CERT_TRUST_IS_UNTRUSTED_ROOT
Simple Chain Count = 1
Simple Chain [0]
Trust Status (E=0x20,I=0x0)
CERT_TRUST_IS_UNTRUSTED_ROOT
Chain Element Count = 4
Chain Element [0]
Subject::
[0,0] 2.5.4.3 (CN) Todd Stecher
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) [email protected]
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) W2K User Enrollment CA
SerialNumber:: 23 51 12 E4 00 00 00 00 01 21
SHA1 Thumbprint:: D80F9D5A 4E6B82C3 EC0D6A33 C77FFF69 67D5E553
MD5 Thumbprint:: 3848D2B6 B08B58DF E0D4D929 FBC0A706
Signature Thumbprint:: 434D7972 24EA0247 27714A85 4EBA2613 31C1FA22
KeyIdentifier Thumbprint:: 059FEB98 8379EF55 1706CBA3 224A1700 9AC70D99
Key Provider:: Type: 1 Name: Gemplus GemSAFE Card CSP v1.0 Flags: 0x1
(SET_KEY_C
ONTEXT_PROP) Container: 3cbdfad8-5478-4fcd-86c2-17162ebb06fe KeySpec: 1
Dieses Endknotenzertifikat ist in Ordnung:
Trust Status (E=0x0,I=0x1)
CERT_TRUST_HAS_EXACT_MATCH_ISSUER
Chain Element [1]
Subject::
[0,0] 1.2.840.113549.1.9.1 (E) [email protected]
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) W2K User Enrollment CA
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) [email protected]
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV W2K PCA
SerialNumber:: 61 10 12 C8 00 00 00 00 00 54
SHA1 Thumbprint:: 19A9461B A974CB18 55C65880 C51BF0E5 96A86375
MD5 Thumbprint:: 17D1802A 1D1583AF 2A45D0C8 B28EC2B3
Signature Thumbprint:: D7297952 3704D281 71B1CA27 C4A9B428 427AA760
KeyIdentifier Thumbprint:: 44C56E9C 93D11AAF EAFD0A3E DCB4304D D1A9615A
Dieses Zwischenzertifikat ist in Ordnung:
Trust Status (E=0x0,I=0x1)
CERT_TRUST_HAS_EXACT_MATCH_ISSUER
Chain Element [2]
Subject::
[0,0] 1.2.840.113549.1.9.1 (E) [email protected]
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV W2K PCA
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) [email protected]
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV Offline SA Root
SerialNumber:: 05 5B ED 61 00 00 00 00 00 03
SHA1 Thumbprint:: 98FF4DD7 D386C0B9 2DAE1A3A 476F361D 7D539B68
MD5 Thumbprint:: 627B8EB8 770A1706 78E03B48 BA8F0F16
Signature Thumbprint:: F49751AF 9337CE48 724B6B3A 6266E61B F5D9708E
KeyIdentifier Thumbprint:: 7AFC16DE 561908A3 39215D55 0FF257BE 8F5EC77F
Dieses Zwischenzertifikat ist in Ordnung:
Trust Status (E=0x0,I=0x1)
CERT_TRUST_HAS_EXACT_MATCH_ISSUER
Chain Element [3]
Subject::
[0,0] 1.2.840.113549.1.9.1 (E) [email protected]
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV Offline SA Root
Issuer::
[0,0] 1.2.840.113549.1.9.1 (E) [email protected]
[1,0] 2.5.4.6 (C) US
[2,0] 2.5.4.8 (S) WA
[3,0] 2.5.4.7 (L) Redmond
[4,0] 2.5.4.10 (O) NT Distributed Systems
[5,0] 2.5.4.11 (OU) PKS Test
[6,0] 2.5.4.3 (CN) NTDEV Offline SA Root
SerialNumber:: 3C 18 66 29 80 00 69 87 11 D3 1A B0 3F 48 F0 EE
SHA1 Thumbprint:: C7E802C4 4FE87DA7 4B239004 BF27282D EAE971E4
MD5 Thumbprint:: E55A36A0 B7EA4147 49CB2B25 A6662F86
Signature Thumbprint:: 7F3538D4 BCB9314A 587881BA BA62B2A9 7EA57B56
KeyIdentifier Thumbprint:: 2C1CB809 66DC3B75 3E021CA8 CE47B503 2CB186A6
Dies zeigt, dass das Zertifikat (über seine AIA-Erweiterung) abgerufen werden konnte, jedoch kein
Stammzertifikat darstellt und auf diesem Computer nicht vertrauenswürdig ist. Stammzertifikate müssen sich im
Active Directory-basierten Speicher für das Stammzertifikat der Organisation befinden, damit sie bei
Operationen der öffentlichen Schlüssel vertrauenswürdig sind:
Trust Status (E=0x20,I=0xc)
CERT_TRUST_IS_UNTRUSTED_ROOT
CERT_TRUST_HAS_NAME_MATCH_ISSUER
CERT_TRUST_IS_SELF_SIGNED
Chain on smart card is invalid ::
Fehler und Fehlerbehebung bei der Smartcard-Anmeldung
In diesem Abschnitt werden Fehler bei der Smartcard-Anmeldung und ihre Behebung behandelt.
Fehler: Status insufficient resources
Ursache:
Für diesen Fehler ist lediglich eine Ursache bekannt. Er tritt auf, wenn Clients und Domänencontroller aus
verschiedenen Windows 2000-Builds vorhanden sind. Eine Vielzahl der Protokolle basiert auf einer sich ändernden
Spezifikation, die sich zusammen mit dem Produkt entwickelt hat, was zu Problemen beim Austauschprozess führt.
Hierbei handelt es sich auch um die Zuordnung für allgemeine Kerberos-Fehler, so dass möglicherweise weitere
(bisher unbekannte) Fehlerbedingungen diesen Fehler auslösen könnten.
Lösung:
Aktualisieren Sie sämtliche Domänencontroller, Mitgliedsserver und Arbeitsstationen.
Fehler: Sperrserver offline
Ursache:
Dieser Fehler gibt an, dass das Domänencontrollerzertifikat vom Client nicht überprüft werden kann. Weitere
Informationen zum Überprüfen der Zertifikatskette finden Sie unter "Problembehandlung bei Zertifikatsketten mit
DSStore".
Dieser Fehler wird durch eines von zwei Ereignissen ausgelöst:

Die Sperrliste ist abgelaufen.

Die Sperrliste kann vom Mitgliedsserver oder Domänencontroller nicht erreicht werden.
Lösung:
Stellen Sie sicher, dass alle Zertifizierungsstellen in der Zertifikatshierarchie ausgeführt werden und
ordnungsgemäß gültige Sperrlisten veröffentlichen. Certutil.exe wird auf jeder, in einer Domäne erstellten,
Zertifizierungsstelle installiert. Wenn Sie diesen Befehl wie folgt ausführen, werden die Sperrlisten aller
Zertifizierungsstellen in der Organisation gelöscht.
Certutil -dsCRL
Diese Fehlermeldung wurde vermutlich entweder ausgelöst, weil eine Person eine Zertifizierungsstelle aus der
Domäne entfernt hat, ohne die weiter oben im Abschnitt "Erhalten eines ordnungsgemäßen
Autoregistrierungsverhaltens beim Deinstallieren einer Zertifizierungsstelle" aufgeführte Vorgehensweise zu
befolgen, oder weil eine Zertifizierungsstelle ausfiel, bevor sie eine neue Sperrliste veröffentlichen konnte.
Informationen zum Beheben dieses Problems finden Sie weiter oben im Abschnitt "Problembehandlung bei
Zertifikatsketten mit DSStore". Als Lösung sollten Sie dsstore -dcmon ausführen, um das problematische KDCZertifikat zu entfernen, und anschließend dsstore -pulse ausführen, um auf dem Domänencontroller ein
Autoregistrierungsereignis auszulösen.
Fehler: Certificate has been revoked, but still can be used for smart card
logon
Ursache:
Die Sperrlisten werden auf einem Computer zwischengespeichert, bis sie abgelaufen sind, um unnötigen
Netzwerkverkehr zu vermeiden. Das Sperren eines Zertifikats (und Veröffentlichen der Sperrliste) bedeutet nicht
unbedingt, dass die Sperrung sofort erfolgt, da alle Computer, die über eine zwischengespeicherte Version der
Sperrliste verfügen, erst versuchen, eine neue Sperrliste abzurufen, wenn die lokal zwischengespeicherte Kopie
abgelaufen ist.
Lösung:
Für dieses Problem gibt es zwei Lösungsmöglichkeiten. Sie können das Benutzerkonto deaktivieren, um SmarcardAnmeldezertifikate zu sperren. Wenn Sie stattdessen der ausstellenden Zertifizierungsstelle Sperrlistenzeiten
zuweisen, die kürzer als die Standardeinstellung (1 Wochenende) sind, wird die Sperrung wesentlich schneller
festgestellt. Der Nachteil hierbei ist jedoch ein verstärkter Netzwerkverkehr. Daher empfiehlt es sich, die
Sperrlistenzeiten nur für die Zertifizierungsstellen zu ändern, die direkt für das Ausstellen von Zertifikaten an
Benutzer verantwortlich sind.
Weitere Informationen zu diesem Thema finden Sie weiter oben unter "Optimieren der PKI-Bereitstellung".
Fehler: Client credentials could not be verified
Ursache:
Das Clientzertifikat ist kein Smartcard-Anmeldezertifikat. Es ist gesperrt, nicht vertrauenswürdig, oder die
Sperrinformationen standen dem Domänencontroller, der die Anmeldeanforderung verarbeitete, nicht zur
Verfügung.
Lösung:
Führen Sie dsstore –checksc aus, um das Clientzertifikat zu überprüfen (siehe weiter oben unter
"Problembehandlung bei Zertifikatsketten mit DSStore"). Überprüfen Sie, ob das Zertifikat ein Zertifikat vom Typ
Smartcard-Anmeldung oder Smartcard-Benutzer ist. Diese Informationen finden Sie auf der Registerkarte
Details in der Zertifikatsbenutzeroberfläche.
Führen Sie danach dsstore -dcmon (mit der Option display) aus, um zu überprüfen, ob alle Domänencontroller
über eine Kopie des Stammzertifikats in der Smartcard-Zertifikatshierarchie verfügen.. Überprüfen Sie, ob der von
der Option checksc aufgeführte Stamm in jedem Domänencontroller vorhanden ist.
Fehler: The security database on the server does not have a computer account
for this workstation trust relationship
Ursache:
Das Attribut ServicePrincipalName (SPN) des Computers, auf dem die Smartcard-Anmeldung stattfindet, ist in
Active Directory nicht korrekt.
Lösung:
Verwenden Sie DSStore wie folgt:
dsstore -macobj <Computername>
Dieser Befehl entfernt die Attribute SPN und DNSHostName sowie die Gruppenmitgliedschaften für einen
bestimmten Computer. Jetzt müsste ein SPN folgendermaßen angezeigt werden: host/DNSHostName. Wenn dieses
SPN nicht richtig festgelegt ist, verwenden Sie das Windows 2000 Resource Kit-Tool Setspn.exe wie folgt:
setspn -R <Computername>
Fehler: Invalid Handle
Ursache:
Hierbei handelt es sich um einen Serverfehler (Domänencontrollerfehler), der auftritt, weil der Domänencontroller
keine Smartcard-Anmeldeanforderungen erfüllen kann. Dieses Problem tritt extrem selten auf, aber Sie finden die
Lösung hier dennoch für alle Fälle.
Lösung:
Starten Sie den Domänencontroller erneut, bei dem die Smartcard-Anmeldeanforderung eingegangen ist. Ermitteln
Sie, auf welchem Domänencontroller es beim Verarbeiten der Anforderung zu einem Fehler kam, indem Sie sich
mit einem Benutzernamen und Kennwort an der Arbeitsstation anmelden und dann in der Eingabeaufforderung den
Befehl Set ausführen. Starten Sie den durch den Eintrag LogonServer identifizierten Domänencontroller erneut.
C:\ set
LOGONSERVER=\\NTDSDC2
Fehler: Die Netzwerkanforderung wird nicht unterstützt
Ursache:
Dieser Fehler gibt an, dass der Domänencontroller nicht über ein Domänencontrollerzertifikat verfügt.
Lösung:
Wenn es in der Organisation eine Organisationszertifizierungsstelle gibt, sollten Domänencontroller eine
"automatische Registrierung" für ein Zertifikat vornehmen. Nach der Installation einer Zertifizierungsstelle kommt
es zu einer potenziellen Zeitverzögerung, während der ein Domänencontroller kein KDC-Zertifikat erhält. Durch
Ausführen von dsstore -pulse auf dem Domänencontroller wird die von der automatischen Registrierung beim
KDC verursachte Zeitverzögerung vermieden.
Wenn Ihr Domänencontroller nach dem Pulsen dieses Ereignisses noch immer über kein Zertifikat verfügt (führen
Sie dazu dsstore -dcmon mit Option 1 (display) aus, um zu überprüfen, ob alle Domänencontroller in der Domäne
über KDC-Zertifikate verfügen), analysieren Sie die Ereignisprotokolle des Domänencontrollers
(Anwendungsprotokoll, winlogon-Ereignis) und die Ereignisprotokolle der Zertifizierungsstelle, um
herauszufinden, warum die Registrierung fehlschlägt.
Wenn der problematische Domänencontroller gerade erst zur Domäne hinzugefügt wurde, stellen Sie sicher, dass
die Replikation dieses Objekts (des Computerobjekts des Domänencontrollers) und seiner Attribute vorgenommen
wurde. Wenn die Replikation nicht vorgenommen wurde, wird der Fehler 0x547 ("Configuration information could
not be read from the domain controller, either because the machine is unavailable, or access has been denied.")
ausgelöst, da der Domänencontroller, anhand dessen die Zertifizierungsstelle die Anforderung überprüft, noch nicht
über die Kontendaten des neu hinzugefügten Domänencontrollers verfügt.
Fehler: Eine Zertifikatskette wurde zwar ordnungsgemäß verarbeitet, ist
jedoch in einem Stammzertifikat geendet, das keine Vertrauensstellung mit
dem Vertrauensanbieter hat
Ursache:
Diese Meldung gibt an, dass dem Client das Stammzertifikat fehlt, das die Zertifikatskette des KDC-Zertifikats
ausgestellt hat. Dieser Fehler kann folgende Ursachen haben:


Der Mitgliedsserver empfängt keine Richtlinien. Überprüfen Sie in diesem Fall das Anwendungsprotokoll
auf userenv-Fehler.
Der Mitgliedsserver kann keine Authentifizierung in Active Directory durchführen und empfängt kein
Stammzertifikat.
Lösung:
Pulsen Sie das Autoregistrierungsereignis (dsstore -pulse), welches alle Stämme aus den Speichern für das
Stammzertifikat der Organisation in Active Directory downloadet.
Fehler und Fehlerbehebung bei der Registrierung
In diesem Abschnitt werden Fehler bei der Registrierung und ihre Behebung behandelt.
Fehler: Windows could not find a certification authority to process the
request
Ursache:
Dieser Fehler weist auf eine von vier möglichen Bedingungen hin. Er tritt nur auf, wenn Sie versuchen, den
Registrierungsassistenten der Zertifikatverwaltung des Zertifikat-Snap-Ins verwenden. Dieser Fehler kann folgende
Ursachen haben:

In der Domäne existieren keine Zertifizierungsstellen.

Es existieren keine Zertifizierungsstellen, bei denen sich die registrierte Person registrieren lassen kann.


Keine der Zertifizierungsstellen in der Organisation stellt Zertifikatsvorlagen aus, bei denen die registrierte
Person das Recht hat, sich registrieren zu lassen .
Auf dem Computer der registrierten Person fehlt das Stammzertifikat für eine bestimmte
Zertifizierungsstellenhierarchie.
Die ersten drei Ursachen lassen sich auf die Konfiguration zurückführen. Die letzte bedeutet normalerweise, dass
der Mitgliedsserver oder die Arbeitsstation bisher noch keine Kopie des Stammzertifikats für eine Organisation
erhalten hat (weil die Replikation noch nicht vorgenommen wurde).
Lösung:
Führen Sie in allen vier Fällen zum Lösen des Problems dsstore -pulse aus (für Active Directory-basierte Speicher
für das Stammzertifikat der Organisation), oder führen Sie secedit /refreshpolicy machine_policy aus (für GPObasierte Stammzertifikate).
Wenn das Problem nach dem Ausführen eines dieser Befehle nicht behoben wurde, überprüfen Sie das
Ereignisprotokoll auf netlogon-Fehler im Zusammenhang mit dem sicheren Kanal des Computers.
Fehler: Certsrv web pages inaccessible, and Virtual Roots do not show up in
Internet Services Manager
Ursache:
Dieser Fehler tritt in der Regel auf, wenn die Zertifikatsdienste vor den Internet-Informationsdiensten (IIS)
installiert wurden.
Lösung:
Führen Sie in der Zertifizierungsstelle certutil -vroot aus. Dadurch werden die virtuellen Stämme erneut mit den
richtigen Berechtigungen installiert. (Ein virtueller Stamm ist das Stammverzeichnis, das Benutzer bei einer
Verbindung mit einem Internetserver verwenden, z. B. ein HTTP- oder FTP-Server. Der virtuelle Stamm ist
eigentlich ein Verweis auf das physikalische Stammverzeichnis, das sich an einem anderen Standort, wie z. B. auf
einem anderen Server, befinden kann. Ein virtueller Stamm dient zum Erstellen eines einfachen URLs für die
Internetsite und zum Verschieben des Stammverzeichnisses ohne Auswirkungen auf den URL.)
Fehler: Die Registrierung für Smartcard über die Webseiten der
Registrierungsstelle schlägt mit folgendem Hinweis fehl: "Die
Zertifizierungskette wurde ordnungsgemäß verarbeitet, doch wird eines der
Zertifizierungsstellen-Zertifikate vom Richtlinienanbieter nicht für
vertrauenswürdig gehalten"
Ursache:
Das Registrierungs-Agent-Zertifikat wurde von einer nicht zu dieser Organisation gehörenden
Organisationszertifizierungsstelle oder einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt. Dafür kann
es zwei Ursachen geben:


Die ausstellende Zertifizierungsstelle ist keine Organisationszertifizierungsstelle.
Die Zertifizierungsstelle, die die Anforderung verarbeitet, hat das Zertifikat der ausstellenden
Zertifizierungsstelle noch nicht in den lokalen Zertifikatspeicher gedownloadet.
Bei der ersten Ursache handelt es sich um das erwartete (ordnungsgemäße) Verhalten.
Organisationszertifizierungsstellen führen die Authentifizierungsprüfung durch DCOM-Imitation durch, so dass
eine Prüfung der Identität des Clients möglich ist. Eigenständige Zertifizierungsstellen können die
Authentifizierungsprüfung nicht durch DCOM-Imitation durchführen. Aus diesem Grund sind Zertifikate, die von
einer eigenständigen Zertifizierungsstelle gewährt wurden, in einer Organisationsumgebung ungültig und können in
der Registrierungsstelle nicht verwendet werden.
Weitere Informationen zur zweiten Ursache für diesen Fehler finden Sie weiter oben unter "Durch automatische
Registrierung und Gruppenrichtlinien verursachte Latenzzeit".
Lösung:
Um dieses Problem zu beheben, pulsen Sie das Autoregistrierungsereignis (dsstore -pulse) auf der
Zertifizierungsstelle, für die die Operation durchgeführt wird.
Fehler: Configuration information could not be read from the domain
controller, either because the machine is unavailable, or access has been
denied
Ursache:
Dieser Fehler tritt normalerweise auf, wenn ein Anforderer (entweder ein Benutzer oder ein Computer) nicht auf
dem globalen Katalogserver verfügbar ist, an den die Zertifizierungsstelle Informationen sendet. Dies kann
passieren, wenn der Benutzer oder Computer gerade erst in die Domäne verschoben wurde und die Informationen
noch nicht im globalen Katalog repliziert wurden. Dieser Fehler kann auch auftreten, wenn Sie versuchen, eine
gesamtstrukturübergreifende Webregistrierung von einer vertrauenswürdigen Gesamtstruktur durchzuführen, die
nicht in Windows 2000 unterstützt wird. Und schließlich kann es Probleme mit der Replikation oder Ihrem globalen
Katalog geben.
Lösung:
Wie bei allen Problemen mit der Latenzzeit empfiehlt es sich, dem Netzwerk Zeit zu lassen. Windows 2000
unterstützt keine gesamtstrukturübergreifende Registrierung.
Wenn der Benutzer sich schon seit langem in der Domäne befindet, untersuchen Sie den Zustand Ihrer globalen
Kataloge mit dem Tool DCDiag des Windows 2000 Resource Kit oder einem ähnlichen Tool. Analysieren Sie Ihr
Ereignisprotokoll im globalen Katalog auf Fehlermeldungen.
Fehler: Dieser Vorgang wurde zurückgegeben, weil das Zeitlimit
überschritten wurde
Ursache:
Die Zertifizierungsstelle hat nicht innerhalb von 60 Sekunden auf die Zertifikatsanforderung reagiert.
Lösung:
Stellen Sie sicher, dass die Zertifizierungsstelle ordnungsgemäß und nicht mit maximaler CPU oder maximalem
Arbeitsspeicher ausgeführt wird. Stellen Sie darüber hinaus sicher, dass die rechtzeitige Registrierung nicht durch
Netzwerkprobleme verhindert wird.
Fehler: Der RPC-Server ist nicht verfügbar
Ursache:
Die Zertifizierungsstelle ist nicht verfügbar, oder es gibt ein Problem beim Auflösen des DNS-Namens. (Beachten
Sie, das DCOM RPC verwendet. Aus diesem Grund wird in der Fehlermeldung auf RPC verwiesen.)
Lösung:
Wenn die Zertifizierungsstelle offline ist, starten Sie sie erneut. Führen Sie für DNS dsstore -tcainfo aus, und sehen
Sie sich die Resultate des Computernamens der Zertifizierungsstelle an, bei der die Registrierung stattfand. Wenn
Sie ihn nicht mit diesem Namen pingen können, überprüfen Sie die DNS-Einträge für die Zertifizierungsstelle.
Fehler: Ungültiger Parameter
Ursache:
Dieser Fehler tritt traditionell nur beim Registrieren eines Computers auf und wenn beim Attribut DNSHostName
des anfordernden Rechners ein Problem auftritt. Überprüfen Sie dies im Ereignisprotokoll der Zertifizierungsstelle,
bei der die Anforderung eingeht.
Lösung:
Dieser Fehler ist höchst unwahrscheinlich. Sollte er aber dennoch auftreten, lässt er sich durch Trennen der
Verbindung von und erneutes Verbinden mit der Domäne beheben.
Zusammenfassung
Die Implementierung der PKI-Technologie über die Windows 2000-Zertifikatsdienste ermöglicht den sicheren
Austausch von Informationen über das Internet, über Extranets und Intranets. Dieses Whitepaper stellt Richtlinien
zum Diagnostizieren und Behandeln von Problemen bei der PKI-Bereitstellung in einer Windows 2000Gesamtstruktur bereit. Außerdem wird die Verwendung des Dienstprogramms DSStore ausführlich beschrieben und
die Ursachen und Lösungen für Fehler bei der Smartcard-Anmeldung und Zertifikatsregistrierung erläutert.
Weitere Informationen
Die neuesten Informationen zu Windows 2000 Server finden Sie in unserer Website unter
http://www.microsoft.com/germany/windows2000/ bzw. unter http://www.microsoft.com/windows/server/
(englischsprachig) und im Windows NT Server Forum auf MSN™ unter
http://computingcentral.msn.com/topics/windowsnt (englischsprachig).
Weitere Informationen finden Sie außerdem in folgenden Dokumenten:
Whitepaper "Windows 2000 Certificate Services" (englischsprachig)
Whitepaper "Cryptography and PKI Basics" (englischsprachig)
Whitepaper "Smart Cards" (englischsprachig)
Whitepaper "Smart Card Logon" (englischsprachig)
Whitepaper "An Introduction to the Windows 2000 Public Key Infrastructure" (englischsprachig)
Whitepaper "Microsoft Windows 2000 Public Key Infrastructure" (englischsprachig)
Whitepaper "Public Key Interoperability" (englischsprachig)
Whitepaper "Active Directory Architecture" (englischsprachig)
Webdokument "Active Directory Replication" (englischsprachig)
Whitepaper "Group Policy" (englischsprachig)
Website der International Telecommunications Union (ITU) (englischsprachig)
PKIX-Website (IETF-Arbeitsgruppe, die die Verantwortung für die Definition der Grundlagen einer interoperablen
PKI trägt)
Windows 2000 Server – Die technische Referenz (Windows 2000 Server Resource Kit). Dieses finden Sie auf
den CDs zu Windows 2000 Server und Advanced Server unter den Supporttools.
Schneier, Bruce. Angewandte Kryptographie. Protokolle, Algorithmen und Sourcecode in C. Addison-Wesley, 1996
(bzw. Applied Cryptography: Protocols, Algorithms, and Source Code in C. 2nd Ed. John Wiley & Sons, 1995.)
Dies ist eine allgemeine Einführung in Kryptografie.
© 2000 Microsoft Corporation. Alle Rechte vorbehalten.
Die in diesem Dokument enthaltenen Informationen stellen die behandelten Themen aus der Sicht der Microsoft
Corporation zum Zeitpunkt der Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen
reagieren muss, stellt dies keine Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier
dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren.
Dieses Whitepaper dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIESES DOKUMENT
JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT.
Microsoft, Active Directory, MSN, Windows und Windows NT sind entweder eingetragene Marken oder Marken
der Microsoft Corporation in den USA und/oder anderen Ländern.
Die in diesem Dokument aufgeführten Produkt- und Firmennamen sind möglicherweise Marken der jeweiligen
Eigentümer.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA
0400
1 In Windows 2000 versteht man unter einer Zugriffssteuerungsliste (Acces Control List, ACL) eine Liste von
Sicherheitsschutzmaßnahmen, die für ein gesamtes Objekt, eine Reihe der Objekteigenschaften oder für eine
einzelne Eigenschaft eines Objekts gelten können. Jedes Active Directory-Objekt verfügt über zwei zugehörige
ACLs: Die freigegebene Zugriffssteuerungsliste (Discretionary Access Control List, DACL) ist eine Liste der
Benutzerkonten, Gruppen und Computer, denen der Zugriff auf das Objekt gewährt (oder verweigert) wird. Die
System-Zugriffssteuerungsliste (System Access Control List, SACL) definiert, welche Ereignisse (z. B.
Dateizugriff) für einen Benutzer oder eine Gruppe überwacht werden.
2 Windows 2000 implementiert die Zugriffssteuerung, indem Administratoren erlaubt wird, in Active Directory
gespeicherten Objekten Sicherheitsbeschreibungen zuzuweisen. Eine Sicherheitsbeschreibung ist eine Reihe von
Informationen, die an ein Objekt (z. B. eine Datei, einen Drucker oder einen Dienst) angefügt wurden und die
verschiedenen Gruppen (oder Benutzern) erteilten Berechtigungen sowie die zu überwachenden
Sicherheitsereignisse angeben. Neben dem Zugriff auf ein bestimmtes Objekt können Sie auch den Zugriff auf ein
bestimmtes Attribut dieses Objekts steuern.
3 Sie können auch die Anwendung von Gruppenrichtlinien einschränken, indem Sie DACLs vom Typ
"Gruppenrichtlinie übernehmen" für das Gruppenrichtlinienobjekt verwenden. In diesem Fall müssten keine
getrennten Organisationseinheiten erstellt werden.
4 SSL (Secure Sockets Layer) ist ein vorgeschlagener offener Standard, der von Netscape Communications zum
Einrichten eines sicheren Kommunikationskanals entwickelt wurde, um das Abfangen wichtiger Informationen,
z. B. von Kreditkartennummern, zu verhindern. In erster Linie ermöglicht dieser Standard sichere elektronische
Finanztransaktionen im World Wide Web, wenngleich er auch für andere Internetdienste konzipiert wurde.
5 Kontext verweist hier auf den Benutzer- (z. B. als angemeldeter Benutzer) oder Computerkontext.