Windows Vista SmartCard-Infrastruktur

Windows Vista® SmartCard Infrastructure enthält Details über die Microsoft® Windows ® Smartcardinfrastruktur und wie Smartcard-bezogene Komponenten in Windows funktionieren. Dieses Dokument enthält auch Informationen zu Problembehandlungs- und Debugtools und Tools, mit denen It-Entwickler und Administratoren smartcardbasierte starke Authentifizierung im Unternehmen bereitstellen können.

Zielgruppe

Dieses Dokument enthält details zur Funktionsweise der Windows Smartcardinfrastruktur auf niedriger Ebene. Sie müssen grundlegende Kenntnisse über öffentliche Schlüsselinfrastrukturkonzepte (PKI) und Smartcard-Konzepte haben, um die Empfehlungen in diesem Dokument vollständig zu nutzen. Dieses Dokument richtet sich an:

• Entwickler und Unternehmens-IT-Experten, die eine Smartcardbereitstellung planen oder implementieren. Dazu gehören IT-Direktoren und IT-Mitarbeiter.
• Smartcardanbieter, die Smartcard-Minitreiber oder Anmeldeinformationenanbieter schreiben. In diesem Dokument werden die inneren Arbeiten der Windows Smartcardarchitektur erläutert und Informationen darüber bereitgestellt, wie IT-Abteilungen Smartcardbereitstellungen planen.

Windows SmartCard-Infrastruktur

Die Smartcardunterstützung wurde zunächst in Windows 2000 aufgenommen. Windows Server 2003 und Windows XP unterstützen auch Smartcards.

Hinweis

Der Smartcard-Dienst (SCardSvr.exe) und die WinSCard-API waren als optionale Komponenten für Windows 95, Windows 98 und Windows ME verfügbar.

Da Smartcards in Windows 2000 integriert wurden, können sich Benutzer digital anmelden und verschlüsseln. Es gibt jedoch einige Einschränkungen in der Implementierung.

Vor Windows Vista:

• Eine Smartcard konnte nur ein Zertifikat für die Anmeldung unterstützen.
• Nur ein Container auf der Smartcard konnte standardmäßig markiert werden. Zusätzliche Zertifikate können für andere Zwecke, z. B. S/MIME, auf der Smartcard gespeichert werden.
• Das Ändern der PIN und das Aufheben der Blockierung einer Smartcard wurden nicht systemeigenen unterstützt oder integriert. Daher musste sich ein Benutzer zunächst mit einem Standardbenutzernamen und einem Kennwort anmelden, um diese Aufgaben auszuführen.

Windows Vista-Verbesserungen

Winlogon wurde in Windows Vista neu entwickelt. In früheren Versionen von Windows wurde eine benutzerdefinierte GINA Dynamic Link Library (DLL) verwendet, um anpassbare Benutzeridentifikation und Authentifizierung zu unterstützen. Auf Windows Vista wurde die GINA-Funktionalität unter drei Komponenten verteilt:

• Windows-Anmeldung
• Anmeldebenutzeroberfläche (UI)
• Anmeldeinformationsanbieter

MSGINA.DLL wurde entfernt, und benutzerdefinierte GINAs werden nicht auf Systemen geladen, die Windows Vista und späteren Versionen ausgeführt werden. Sowohl der Kennwort-Anmeldeinformationenanbieter als auch der Smartcard-Anmeldeinformationenanbieter werden standardmäßig bereitgestellt, und die Möglichkeit, benutzerdefinierte Authentifizierungsmechanismen zu unterstützen, erfordert die Erstellung eines benutzerdefinierten Anmeldeinformationenanbieters. Nachdem die Windows-Anmeldung die Anmeldebenutzeroberfläche gestartet hat, werden registrierte Anmeldeinformationsanbieter geladen. Der Smartcard-Anmeldeinformationsanbieter verwendet Schnittstellen, die über das Anmeldeinformationsanbieter-Framework verfügbar gemacht werden, um die erforderlichen Anmeldeinformationen zu erfassen, zu verpacken und an die Anmeldebenutzeroberfläche zurückzugeben. Anschließend übergibt die Anmelde-UI die Anmeldeinformationen an Winlogon, die für die Kerberos-Authentifizierung verwendet werden sollen.

In Vista unterstützt Winlogon mehrere Anmeldezertifikate und Container auf derselben Smartcard. Die Anzahl der Zertifikate, die gespeichert werden können, und der Container, die erstellt werden können, hängt davon ab, wie viel Speicherplatz auf der Smartcard verfügbar ist.

Jede Smartcard muss über einen Kryptografiedienstanbieter (CSP) verfügen. Ein CSP verwendet die Kryptografieanwendungs-Programmierschnittstelle (CAPI) oben und die WinSCard-APIs unten. (Ausführliche Informationen finden Sie unter Smartcard-Subsystemarchitektur.)

In der Vergangenheit war das Schreiben eines Smartcard-CSP keine triviale Aufgabe. Ein neuer CSP namens Base CSP hilft nun jedoch, eine Smartcard-CSP zu schreiben. Der Basis-CSP ermöglicht Smartcardanbietern das Schreiben von kartenspezifischen Modulen namens Smartcard-Minitreibern. Microsoft stellt den Base-CSP als Teil der Plattform bereit. Ein herunterladbares Paket besteht für Windows XP SP2, Windows 2000 SP4 und Windows Server 2003 SP1. Ein Smartcard-Minitreiber ist eine Schnittstelle, die Microsoft für Smartcardanbieter unterstützt, um Implementierungen in ihre Smartcard zu schreiben. Dies ist analog zum Schreiben eines Druckertreibers für einen Drucker.

WinSCard-API wurde erweitert, um zwischenspeichern (Speichern von nicht vertraulichen Daten auf Benutzerbasis) auf Smartcard-Ressourcen-Managerebene. Der Smartcard-Ressourcen-Manager wurde früher als Smartcarddienst bezeichnet.

Um zusätzliche kryptografische Algorithmen zu unterstützen und eine erweiterbare Architektur bereitzustellen, wurde kryptografische API: Next Generation (CNG) entwickelt. Architektonisch ist dies parallel zu CAPI. Wie bei CSP befindet sich ein Schlüsselspeicheranbieter (KSP) unter dem CNG. In Windows Vista wird die Smartcard-KSP-Implementierung standardmäßig bereitgestellt. Die gleiche Smartcard-Minitreiberschnittstelle, die für Base CSP verfügbar ist, gilt auch für Smartcard-KSP. Smartcard-Minitreiberunterstützung für RSA und elliptische Kurvengrafie (ECC) ist mit Smartcard-KSP verfügbar.

Aufbau

Die Smartcardregistrierungsdatenbank befindet sich in HKLM\Software\Microsoft\Kryptografie\Calais\SmartCard. Diese Datenbank enthält Smartcard- und Smartcardleserinformationen. Die Smartcardinfrastruktur in Windows umfasst zwei primäre Komponenten:

• Windows interaktive Anmeldearchitektur
• Smartcard-Subsystemarchitektur

Windows interaktive Anmeldearchitektur

Vor Windows Vista enthält die Windows interaktive Anmeldearchitektur die in Tabelle 1 dargestellten Komponenten.

Tabelle 1 Vorab-Windows Vista interaktive Anmeldekomponenten

Komponente	BESCHREIBUNG
Windows-Anmeldung	Bietet interaktive Anmeldeinfrastruktur.
Komponente "Grafische Identifizierung und Authentifizierung" (GINA)	Stellt das interaktive Ui-Rendering bereit.
Lokale Sicherheitsautorität (LSA)	Verarbeitet Anmeldeinformationen.
Authentifizierungspakete	Enthält NTLM und Kerberos. Kommuniziert mit Serverauthentifizierungspaketen, um Benutzer zu authentifizieren.

Hinweis

Weitere Informationen zur GINA-basierten interaktiven Anmeldearchitektur finden Sie unter How Interactive Logon Works (https://go.microsoft.com/fwlink/?LinkId=93339).

Windows Vista-Anmeldeinformationenanbieterarchitektur

Tabelle 2 zeigt die Komponenten in der Windows Vista interaktiver Anmeldearchitektur.

Tabelle 2 Windows Vista interaktive Anmeldekomponenten

Komponente	BESCHREIBUNG
Windows-Anmeldung	Bietet interaktive Anmeldeinfrastruktur.
Anmeldeoberflächen	Stellt das interaktive Ui-Rendering bereit.
Anmeldeinformationenanbieter (Kennwort und Smartcard)	Beschreibt Anmeldeinformationen und Serialisierungsanmeldeinformationen.
LSA	Verarbeitet Anmeldeinformationen.
Authentifizierungspakete	Enthält NTLM und Kerberos. Kommuniziert mit Serverauthentifizierungspaketen, um Benutzer zu authentifizieren.

Abbildung 1 Windows Architektur des Anmeldeinformationenanbieters

Windows Vista interaktive Anmeldungen beginnen, wenn der Benutzer STRG+ALT+DEL drückt. Die STRG+ALT+DEL-Tastenkombination wird als sichere Aufmerksamkeitssequenz (SAS) bezeichnet. Winlogon registriert diese Sequenz während des Startvorgangs, um andere Programme und Prozesse zu verwenden. Die Anmelde-Benutzeroberfläche generiert dann die Kachel aus Informationen, die von den registrierten Anmeldeinformationenanbietern empfangen wurden. Die folgende Abbildung zeigt das Dialogfeld Windows Vista-Anmeldung.

Abbildung 2 Windows Vista-Anmeldeschnittstelle

Ein Benutzer, der sich mit einem lokalen Konto oder einem Domänenkonto bei einem Computer anmeldet, muss einen Benutzernamen und ein Kennwort eingeben. Diese Anmeldeinformationen werden verwendet, um die Identität des Benutzers zu überprüfen. Im Falle von Smartcard-Anmeldungen sind jedoch die Anmeldeinformationen eines Benutzers auf dem Sicherheitschip der Smartcard enthalten. Ein externes Gerät, das als Smartcardleser bezeichnet wird, liest den Sicherheitschip. Während einer Smartcard-Anmeldung gibt ein Benutzer anstelle eines Benutzernamens, einer Domäne und eines Kennworts eine persönliche Identifikationsnummer (PIN) ein.

Anmeldeinformationenanbieter sind IN-Prozess-COM-Objekte, die verwendet werden, um Anmeldeinformationen in Windows Vista zu sammeln und im lokalen Systemkontext auszuführen. In der Zusammenfassung stellt die Anmeldeoberfläche interaktives UI-Rendering bereit, Winlogon stellt interaktive Anmeldeinfrastruktur bereit, und Anmeldeinformationenanbieter helfen beim Sammeln und Verarbeiten von Anmeldeinformationen.

In Windows Vista weist Winlogon die Anmeldeoberfläche an, Kacheln anzuzeigen, nachdem es ein SAS-Ereignis empfängt. Die Anmeldeoberflächenabfrage jedes Anmeldeinformationenanbieters für die Anzahl der Anmeldeinformationen, die er aufzählen möchte. Anmeldeinformationenanbieter haben die Möglichkeit, eine dieser Kacheln als Standard anzugeben. Nachdem alle Anbieter ihre Kacheln aufgezählt haben, zeigt die Anmelde-BEnutzeroberfläche sie dem Benutzer an. Der Benutzer interagiert mit einer Kachel, um seine Anmeldeinformationen zu liefern. Die Anmelde-UI sendet diese Anmeldeinformationen für die Authentifizierung.

Zusammen mit der Unterstützung von Hardware können Anmeldeinformationenanbieter das Microsoft Windows Betriebssystem erweitern, um Benutzern die Anmeldung über biometrische (Fingerabdruck, Retinal oder Spracherkennung), Kennwort, PIN, Smartcardzertifikat oder ein benutzerdefiniertes Authentifizierungspaket eines Drittanbieters zu ermöglichen. Unternehmen und IT-Experten können benutzerdefinierte Authentifizierungsmechanismen für alle Domänenbenutzer entwickeln und bereitstellen und müssen benutzer explizit diesen benutzerdefinierten Anmeldemechanismus verwenden.

Anmeldeinformationenanbieter sind keine Durchsetzungsmechanismen. Sie werden verwendet, um Anmeldeinformationen zu sammeln und zu serialisieren. Die LSA- und Authentifizierungspakete erzwingen Sicherheit.

Anmeldeinformationenanbieter können so konzipiert sein, dass single sign-on (SSO), authentifiziert Benutzer an einen sicheren Netzwerkzugriffspunkt (mithilfe von RADIUS und anderen Technologien) sowie die Computeranmeldung. Anmeldeinformationenanbieter sind auch so konzipiert, dass anwendungsspezifische Anmeldeinformationen gesammelt werden, und können für die Authentifizierung für Netzwerkressourcen verwendet werden, Computer zu einer Domäne beitreten oder Administratoreinstimmungen für die Benutzerkontensteuerung (UAC) bereitstellen.

Mehrere Anmeldeinformationenanbieter können auf einem Computer gemeinsam vorhanden sein.

Anmeldeinformationenanbieter werden auf einem Windows Vista-Computer registriert und sind verantwortlich für:

• Beschreiben der anmeldeinformationen, die für die Authentifizierung erforderlich sind.
• Behandeln von Kommunikation und Logik mit externen Authentifizierungsstellen.
• Verpacken von Anmeldeinformationen für interaktive und Netzwerkanmeldeinformationen.

Die Credential Provider-API entwickelt keine Benutzeroberfläche. Es beschreibt, was gerendert werden muss. Nur Kennwortanmeldeinformationenanbieter sind im sicheren Modus verfügbar. In-Box-Smartcard-Anmeldeinformationenanbieter sind im sicheren Modus mit Netzwerk verfügbar.

Weitere Informationen zu Anmeldeinformationenanbietern und deren Verwendung finden Sie unter der technischen Referenz des Credential Provider (https://go.microsoft.com/fwlink/?LinkId=93340).

Abbildung 3 veranschaulicht Windows Vista-Anmeldebildschirmfluss mit PIN-Unblockierung und PIN-Änderung.

Abbildung 3 PIN-Entblockung und PIN-Änderung der Benutzeroberfläche

Smartcard-Subsystemarchitektur

Anbieter und Partner sind für den Erfolg von Smartcard-basierten Szenarien sehr wichtig. Anbieter bieten Smartcards und Smartcardleser, und in vielen Fällen sind die Smartcard- und Leseanbieter unterschiedlich. Lesertreiber werden in die Standardversion 1.0 der PC/SC geschrieben. Jede Smartcard muss über einen CSP verfügen, der die CAPI-Schnittstellen oben und die WinSCard-APIs unten verwendet. Das GINA-Modul verfügt außerdem über die Smartcard-Anmeldung, um die relevante Benutzeroberfläche für die Erfassung der Anmeldeinformationen und die nachfolgende Marshallung bereitzustellen, die an die LSALogonUser für die Authentifizierung gesendet werden sollen.

Basis-CSP- und Smartcard-Minitreiberarchitektur für Windows 2000, Windows XP und Windows 2003

Anforderungen: Der Basis-CSP muss installiert werden. Der Basis-CSP ist ein kostenloser, optionaler Download auf der Microsoft-Website (https://go.microsoft.com/fwlink/?LinkId=93341).

Abbildung 4 veranschaulicht, wie CAPI, CSPs, Basis-CSP und Smartcard-Minitreiber architektonisch geschichtet sind.

Abbildung 4 Basis-CSP- und Smartcard-Minitreiberarchitektur

Smartcardauswahl-Heuristik

Containerspezifikationsstufen

Als Reaktion auf einen CryptAcquireContext-Aufruf versucht der Basis-CSP, den Container abzugleichen, den der Anrufer an eine bestimmte Karte und einen bestimmten Leser angibt. Der Aufrufer kann einen Containernamen mit unterschiedlichen Spezifischen Ebenen bereitstellen, die in der folgenden Liste angezeigt werden, sortiert von spezifischeren bis weniger spezifischen Anforderungen.

Ähnlich wie bei der Smartcard-KSP verwendet NCryptOpenKey das gleiche Format wie in Tabelle 3 dargestellt. Vor dem Öffnen der Taste wird ein Aufruf von NCryptOpenStorageProvider(MS_SMART_CARD_KEY_STORAGE_PROVIDER) vorgenommen.

Tabelle 3 Containerspezifikationsstufen

type	Name	Format
I	Lesername und Containername	\\.\<Lesername\<Containername>>
II	Lesername und Containername (NULL)	\\.\<Lesername>\
III	Containername nur	<Containername>
IV	Standardcontainer (NULL) nur	NULL

Für die ersten beiden Fälle, in denen ein Lesername bereitgestellt wird, sucht der Basis-CSP in der Regel nach dem angegebenen Leser und führt den angeforderten Vorgang auf der Karte aus, die in diesem Leser eingefügt wurde. Für die zweiten beiden Fälle, in denen kein Smartcardlesername bereitgestellt wird, sucht der Basis-CSP nach einer Karte und Leseausgabe, die für die aktuelle Anforderung geeignet ist, beginnend mit Karten, die bereits für die Basis-CSP bekannt sind und alle Smartcards und Lesegeräte, die mit dem Smartcard-Subsystem verfügbar sind.

Für jede der oben genannten Fälle sucht der Basis-CSP zunächst nach einer übereinstimmenden Karte in der Liste der zwischengespeicherten Kartendaten. Dieser Cache enthält eine Liste von Smartcards und zugeordneten Smartcardstatusinformationen, die der CSP in der aktuellen Sitzung gefunden hat (wobei die Sitzung normalerweise die Lebensdauer des aktuellen Prozesses ist). Wenn eine übereinstimmende Smartcard im Cache gefunden wird, sollte der Kartenhandpunkt, der dem Cacheelement zugeordnet ist, aktualisiert werden. Dies bestimmt, ob sich die Karte noch im Lesegerät befindet, da die Smartcard möglicherweise seit der Erstellung des Cacheelements entfernt wurde.

Wenn eine übereinstimmende Smartcard zwischengespeichert wird, aber der zwischengespeicherte Smartcard-Handle nicht mehr gültig ist, wird die SCardUIDlg-API verwendet, um den Kartenhandpunkt zu aktualisieren. Zusätzliche Informationen, z. B. die Seriennummer der übereinstimmenden Smartcard, werden von SCardUIDlg bereitgestellt, um Kandidaten-Smartcards schnell zu filtern.

Containervorgänge

Drei Hauptcontainervorgänge können mithilfe von CryptAcquireContext angefordert werden. Dies sind:

1. Erstellen eines neuen Containers (CRYPT_NEWKEYSET)
2. Vorhandenes Container öffnen
3. Container löschen (CRYPT_DELETEKEYSET)

Die Heuristik, die zum Zuordnen eines Benutzerkontexts mit einer bestimmten Karte und einem Leser verwendet wird, basiert hauptsächlich auf dem angeforderten Containervorgang und der Ebene der verwendeten Containerspezifikation.

Tabelle 4 zeigt die Einschränkungen für den Containererstellungsvorgang.

Einschränkungen für den Containererstellungsvorgang in Tabelle 4

Spezifikation	Einschränkung
Kein stiller Kontext	Die Erstellung von Schlüsselcontainern muss immer in der Lage sein, benutzeroberfläche anzuzeigen, z. B. die PIN-Eingabeaufforderung.
Kein Überschreiben vorhandener Container	Wenn der angegebene Container bereits auf der ausgewählten Smartcard vorhanden ist, wählen Sie entweder eine andere Karte aus, oder kündigen Sie den Vorgang.

Kontext-Flags

Tabelle 5 zeigt die Kontext-Flags für die Einschränkungen für den Containererstellungsvorgang.

Tabelle 5 Einschränkungszeichen

Flag	Beschreibung
CRYPT_SILENT	Während dieses Vorgangs wird möglicherweise keine Benutzeroberfläche angezeigt.
CRYPT_MACHINE_KEYSET	Während dieses Vorgangs sollten keine zwischengespeicherten Daten verwendet werden.
CRYPT_VERIFYCONTEXT	Nur auf öffentliche Daten kann auf der Smartcard zugegriffen werden.

Zusätzlich zu Containervorgängen und Containerspezifikationen müssen Sie andere Benutzeroptionen berücksichtigen, z. B. die obigen CryptAcquireContext-Flags während der Kartenauswahl.

Wichtig

Das CRYPT_SILENT Flag kann nicht mit containervorgang A verwendet werden (neuen Container erstellen).

Erstellen eines neuen Containers im unbeaufsichtigten Kontext

Anwendungen können den Basis-CSP mit CRYPT_DEFAULT_CONTAINER_OPTIONAL aufrufen, die PIN im hintergrundlosen Kontext festlegen und dann einen neuen Container im automatischen Kontext erstellen:

1. Rufen Sie CryptAcquireContext auf, der den Smartcardlesernamen als Typ II angibt, wobei das CRYPT_DEFAULT_CONTAINER_OPTIONAL Flag angegeben wird.
2. Rufen Sie CryptSetProvParam auf, indem Sie PP_KEYEXCHANGE_PIN oder PP_SIGNATURE_PIN und eine NULL-beendete ASCII-PIN angeben.
3. Geben Sie den in Schritt 1 erworbenen Kontext frei.
4. Rufen Sie CryptAcquireContext mit CRYPT_NEWKEYSET an, der das Typ I-Format angibt.
5. Rufen Sie CryptGenKey auf, um den Schlüssel zu erstellen.

Smartcard-Auswahlverhalten

In einigen der folgenden Szenarien kann der Benutzer aufgefordert werden, eine Smartcard einzufügen. Wenn der Benutzerkontext unbeaufsichtigt ist, schlägt dieser Vorgang fehl, und es wird keine Benutzeroberfläche angezeigt. Andernfalls kann der Benutzer als Reaktion auf die Benutzeroberfläche entweder eine Smartcard einfügen oder auf "Abbrechen" klicken. Wenn der Benutzer den Vorgang abbricht, schlägt der Vorgang fehl.

Abbildung 5 Verhalten der Smartcardauswahl

Im Allgemeinen wird das Verhalten der Kartenauswahl von der SCardUIDlgSelectCard-API behandelt. Der Basis-CSP interagiert mit dieser API, indem er sie direkt aufruft. Der Basis-CSP sendet auch Rückruffunktionen, deren Zweck es ist, Kandidaten-Smartcards zu filtern und abzugleichen. Anrufer von CryptAcquireContext stellen Kartenabgleichsinformationen bereit. Intern verwendet der Basis-CSP eine Kombination aus Seriennummern, Lesernamen und Containernamen für smartcards, um bestimmte Smartcards zu finden.

Jeder Aufruf von SCardUI* kann zu zusätzlichen Informationen führen, die von einer Kandidaten-Smartcard gelesen werden. Die Basis-CSP-Smartcardauswahl-Rückrufe speichern diese Informationen zwischen.

Die SCardUI*-API wird verwendet, um Smartcardhandles zu aktualisieren, da eine Ziel-Smartcard möglicherweise entfernt oder erneut eingefügt wird, nachdem ein Kartenziehpunkt zwischengespeichert wurde. Die übereinstimmende Seriennummer wird von FindCachedCard() ermittelt, die zusammen mit einem Status an FindCard() übergeben wird, der an FindCard() angibt, dass die Suche erfolgreich war, aber dass der Kartenziehpunkt erneut erworben werden muss. (Oder dass die entsprechende Smartcardstatusstruktur zurückgegeben werden könnte, anstatt nur die Seriennummer. Dadurch würde verhindert, dass der Rückruf die Liste der Karten erneut durchsuchen muss.) FindCard stellt die Seriennummer für den entsprechenden Kartenabgleich mit SCardUI*bereit.

Erstellen einer Leser-Übereinstimmung

Für Containerspezifikationsebenen I und II ist der Smartcardauswahlprozess weniger komplex, da nur die Smartcard im benannten Leser als Übereinstimmung betrachtet werden kann.

1. Suchen Sie den angeforderten Leser. Wenn sie nicht gefunden werden kann, schlägt der Vorgang fehl. (Dies erfordert eine Cachesuche nach Lesernamen.)
2. Wenn sich keine Smartcard im Reader befindet, wird der Benutzer aufgefordert, eine Smartcard einzufügen (nur im nicht automatischen Modus; wenn der Anruf im automatischen Modus ausgeführt wird, schlägt er fehl).
3. Nur für Stufe II wird der Name des Standardcontainers auf der ausgewählten Smartcard bestimmt.
4. Suchen Sie für Containervorgänge B (bereits geöffnet) und C (löschen), den angegebenen Container. Wenn der angegebene Container auf dieser Smartcard nicht gefunden werden kann, wird der Benutzer aufgefordert, eine Smartcard einzufügen.
5. Bei Containervorgang A (neu erstellen), wenn der angegebene Container bereits auf dieser Smartcard vorhanden ist, schlägt der Prozess fehl.

Erstellen einer Smartcard-Übereinstimmung

Für Containerspezifikationsebenen III und IV wird eine breitere Methode verwendet, um einer geeigneten Karte mit einem Benutzerkontext zu entsprechen, da mehrere zwischengespeicherte Smartcards die bereitgestellten Kriterien erfüllen können.

Öffnen eines vorhandenen Standardcontainers – kein Leser angegeben

Hinweis

Dieses Szenario erfordert, dass Sie den Smartcard-KSP mit dem Basis-CSP verwenden.

1. Suchen Sie für jede smartcard, die bereits vom Basis-CSP bekannt ist, nach einem gültigen Standardcontainer. Ein Vorgang wird versucht, den zwischengespeicherten SCARDHANDLE zu überprüfen, um seine Aktualität zu überprüfen. Wenn der Smartcard-Handle ungültig ist, sucht der Basis-CSP weiterhin nach einer neuen Smartcard.
2. Wenn eine übereinstimmende Karte im Basis-CSP-Cache nicht gefunden wird, rufen Sie das Smartcard-Subsystem auf. SCardUIDlgSelectCard() wird mit einem entsprechenden Rückruffilter verwendet, um eine übereinstimmende Karte mit einem gültigen Standardcontainer zu finden.

Öffnen vorhandener GUID-benannter Container, kein reader angegeben

Hinweis

Dieses Szenario erfordert, dass Sie den Smartcard-KSP mit dem Basis-CSP verwenden.

1. Suchen Sie für jede Smartcard, die der Basis-CSP bereits kennt, nach dem angeforderten Container. Versuchen Sie, einen Vorgang auf dem zwischengespeicherten SCARDHANDLE zu überprüfen, um die Aktualität zu überprüfen. Wenn der Kartenziehpunkt ungültig ist, wird die Seriennummer der Smartcard an die SCardUI*-API übergeben, um die Suche nach dieser bestimmten Smartcard fortzusetzen (anstatt nur eine allgemeine Übereinstimmung für den Containernamen).
2. Wenn eine übereinstimmende Karte im Basis-CSP-Cache nicht gefunden wird, wird ein Aufruf im Smartcard-Subsystem ausgeführt. SCardUIDlgSelectCard() wird mit einem entsprechenden Rückruffilter verwendet, um eine übereinstimmende Karte mit dem angeforderten Container zu finden. Oder wenn eine Smartcard-Seriennummer aus der Suche in Schritt 1 resultierte, versucht der Rückruffilter, die Seriennummer nicht mit dem Containernamen übereinzugleichen.

Erstellen eines neuen Containers, kein angegebener Reader

Hinweis

Dieses Szenario erfordert, dass Sie den Smartcard-KSP mit dem Basis-CSP verwenden.

Wenn die PIN nicht zwischengespeichert wird, ist für die Containererstellung keine CRYPT_SILENT zulässig, da der Benutzer mindestens zur Eingabe einer PIN aufgefordert werden muss.

Bei anderen Vorgängen kann der Aufrufer möglicherweise einen "verify"-Kontext für den Standardcontainer (CRYPT_DEFAULT_CONTAINER_OPTIONAL) abrufen und dann einen CryptSetProvParam-Aufruf vornehmen, um die Benutzer-PIN für nachfolgende Vorgänge zwischenzuspeichern.

1. Aktualisieren Sie für jede smartcard, die bereits vom CSP bekannt ist, die gespeicherte SCARDHANDLE , und führen Sie die folgenden Prüfungen aus:
   1. Wenn die Smartcard entfernt wurde, fahren Sie mit der Suche fort.
   2. Wenn die Smartcard noch vorhanden ist, aber bereits über den benannten Container verfügt, fahren Sie mit der Suche fort.
   3. Wenn die Smartcard verfügbar ist, aber ein Aufruf von CardQueryFreeSpace angibt, dass die Karte nicht genügend Speicherplatz für einen zusätzlichen Schlüsselcontainer hat, fahren Sie mit der Suche fort.
   4. Verwenden Sie andernfalls die erste verfügbare Smartcard, die die oben genannten Kriterien für die Containererstellung erfüllt.
2. Wenn eine entsprechende Smartcard im CSP-Cache nicht gefunden wird, rufen Sie das Smartcard-Subsystem auf. Der Rückruf, der zum Filtern aufgezählter Smartcards verwendet wird, sollte überprüfen, ob eine Kandidaten-Smartcard nicht bereits über den benannten Container verfügt, und dass CardQueryFreeSpace angibt, dass die Karte ausreichend Platz für einen zusätzlichen Container hat. Wenn keine geeignete Karte gefunden wird, zeigen Sie die Benutzeroberfläche an, die den Benutzer auffordert, eine Smartcard einzufügen.

Löschen eines Containers

1. Wenn der angegebene Containername NULL ist, wird der Standardcontainer gelöscht. Durch das Löschen des Standardcontainers wird ein neuer Standardcontainer willkürlich ausgewählt. Aus diesem Grund wird dieser Vorgang nicht empfohlen.
2. Aktualisieren Sie für jede smartcard, die bereits vom CSP bekannt ist, die gespeicherte SCARDHANDLE , und führen Sie die folgenden Prüfungen aus.
   1. Wenn die Smartcard nicht über den benannten Container verfügt, fahren Sie mit der Suche fort.
   2. Wenn die Smartcard den benannten Container hat, aber der Kartenziehpunkt nicht mehr gültig ist, speichern Sie die Seriennummer der übereinstimmenden Smartcard, und übergeben Sie sie an SCardUI*.
3. Wenn eine übereinstimmende Karte im CSP-Cache nicht gefunden wird, rufen Sie das Smartcard-Subsystem auf. Der Rückruf, der zum Filtern von aufgezählten Karten verwendet wird, sollte überprüfen, ob eine Kandidatenkarte den benannten Container hat. Wenn eine Seriennummer als Ergebnis der obigen Cachesuche bereitgestellt wurde, sollte der Rückruf auf aufgezählte Karten auf Seriennummern und nicht auf Container-Übereinstimmungen filtern. Wenn der Kontext nicht automatisch ist und keine geeignete Smartcard gefunden wird, zeigen Sie die Benutzeroberfläche an, die den Benutzer auffordert, eine Smartcard einzufügen.

Zwischenspeichern mit Basis-CSP und Smartcard-KSP (nur Windows Vista)

Zwischenspeichern von Daten

Jeder CSP implementiert den aktuellen Smartcarddatencache separat. Der Basis-CSP implementiert z. B. einen robusten Cachemechanismus, der es einem einzelnen Prozess ermöglicht, Karten-I/O-Vorgänge zu minimieren.

Der vorhandene Prozesscache funktioniert wie folgt.

1. Die Anwendung fordert einen CAPI-Vorgang an. Beispielsweise ist ein Benutzerzertifikat aus der Karte zu lesen.
2. Der CSP überprüft zuerst den Cache für das Element.
3. Wenn das Element im Cache nicht gefunden wird oder das Element zwischengespeichert, aber nicht auf dem neuesten Stand ist, wird das Element dann von der Smartcard gelesen.
4. Nachdem ein Element aus der Smartcard gelesen wurde, wird es dem Cache hinzugefügt. Jede vorhandene veraltete (veraltete) Kopie dieses Elements wird ersetzt.

Das primäre Problem in der vorhandenen Lösung besteht darin, dass jeder Smartcard-fähige Prozess im System das obige Verhalten duplizieren muss und seine eigene Kopie derselben Daten beibehalten muss. Das aktuelle Modell ist nicht ausreichend. Ein Prozess muss kartendaten verwenden können, die zuvor von anderen Prozessen gelesen wurden.

Der globale Datencache wird im Smartcard-Ressourcen-Manager gehostet. Windows Vista enthält zwei neue öffentliche Windows Smartcard-API-Aufrufe, SCardWriteCache und SCardReadCache. Diese API-Aufrufe stellen globale Datencachefunktionen für Anwendungen zur Verfügung. Diese API-Aufrufe werden nur auf Windows Vista-Clientcomputern unterstützt.

1. Jede Smartcard, die der neuen Smartcard-Minitreiberspezifikation entspricht, verfügt über einen 16-Byte-Kartenbezeichner. Dieser Wert wird verwendet, um zwischengespeicherte Daten zu identifizieren, die sich auf eine bestimmte Smartcard beziehen. Aus Gründen der Einfachheit wird der standard-Windows GUID-Typ verwendet.
2. Mit diesen APIs kann eine Anwendung Daten hinzufügen und Daten aus dem globalen Cache lesen.

Sie müssen zwei neue APIs, RedirectedSCardWriteCache und RedirectedSCardReadCache, mit den entsprechenden IOCTLs und Handlern implementieren, um den Terminalserver umzuleiten.

PIN-Zwischenspeichern

Der PIN-Cache hilft, den Benutzer zu beschränken, die bei jeder Deuthentifizierung der Smartcard eine PIN erneut durchführen zu müssen. Nachdem eine Smartcard authentifiziert wurde, unterscheidet sie sich nicht zwischen hostseitigen Anwendungen; jede Anwendung kann auf private Daten auf der Smartcard zugreifen. Um dies zu verringern, wird die Smartcard unter einem exklusiven Zustand platziert, wenn sich eine Anwendung bei der Smartcard authentifiziert. Dies bedeutet jedoch, dass andere Anwendungen nicht mit der Smartcard sprechen können und blockiert werden. Daher werden solche exklusiven Verbindungen minimiert. Das Problem besteht darin, dass ein Protokoll wie Kerberos mehrere Signaturvorgänge erfordert und daher über einen längeren Zeitraum entweder exklusiven Zugriff auf die Smartcard erfordert oder mehrere Authentifizierungsvorgänge erfordert. Hier kommt der PIN-Cache ins Spiel und ermöglicht die minimale exklusive Nutzung der Smartcard, ohne dass der Benutzer mehrere Male seine PIN eingeben muss.

Hier ist ein Beispiel, das genau veranschaulicht, wie dies funktioniert. In diesem Szenario gibt es zwei Anwendungen: Outlook und Internet Explorer. Beide Anwendungen verwenden Smartcards für verschiedene Zwecke.

1. Der Benutzer startet Outlook und versucht, eine signierte E-Mail zu senden. Der private Schlüssel befindet sich auf der Smartcard.
2. Outlook fordert den Benutzer zur Smartcard-PIN auf. Der Benutzer gibt die richtige PIN ein.
3. E-Mail-Daten werden an die Smartcard für den Signaturvorgang gesendet. Der Outlook Client formatiert die Antwort und sendet die E-Mail.
4. Der Benutzer öffnet Internet Explorer und versucht, auf eine geschützte Website zuzugreifen, die die TLS-Clientauthentifizierung erfordert.
5. Internet Explorer fordert den Benutzer zur Smartcard-PIN auf. Der Benutzer gibt die richtige PIN ein.
6. Der TLS-bezogene private Schlüsselvorgang tritt auf der Smartcard auf, und der Benutzer wird authentifiziert und angemeldet.
7. Der Benutzer kehrt zu Outlook zurück, um eine andere signierte E-Mail zu senden. Dieser Zeitpunkt wird der Benutzer nicht zur Eingabe einer PIN aufgefordert, da die PIN vom vorherigen Vorgang zwischengespeichert wird. Wenn der Benutzer Internet Explorer erneut zum Ausführen eines anderen Vorgangs verwendet, fordert Internet Explorer den Benutzer nicht zur Eingabe einer PIN auf.

Der Basis-CSP verwaltet intern einen Prozesscache der PIN, um die Zwischenspeicherung zu ermöglichen. Die PIN wird im Arbeitsspeicher verschlüsselt gespeichert. Die Funktionen, die zum Sichern der PIN verwendet werden, sind "RtlEncryptMemory", "RtlDecryptMemory" und "RtlSecureZeroMemory", die pufferte, die die PIN enthalten haben.

Basis-CSP- und KSP-basierte Architektur in Windows Vista

Abbildung 6 Kryptografiearchitektur in Windows Vista

Basis-CSP- und Smartcard-KSP-Eigenschaften in Windows Vista

Die folgenden Eigenschaften werden in Windows Vista unterstützt.

Hinweis

Die API-Definitionen befinden sich in WinCrypt.h und WinSCard.h.

Tabelle 6 Basis-CSP- und Smartcard-KSP-Eigenschaften

Eigenschaft	BESCHREIBUNG
PP_USER_CERTSTORE	Wird verwendet, um einen HCERTSTORE zurückzugeben, der alle Benutzerzertifikate auf der Smartcard enthält. Schreibgeschützt (nur von CryptGetProvParam verwendet). Anrufer, der für das Schließen des Zertifikatspeichers zuständig ist. Zertifikat codiert mit PKCS_7_ASN_ENCODING oder X509_ASN_ENCODING CSP sollte KEY_PROV_INFO für Zertifikate festlegen Der Zertifikatspeicher sollte als speicherinterner Speicher verwendet werden. Zertifikate sollten über eine gültige CRYPT_KEY_PROV_INFO als Eigenschaft verfügen.
PP_ROOT_CERTSTORE	Lese-/Schreibzugriff (sowohl CryptGetProvParam als auch CryptSetProvParam) Wird verwendet, um eine Sammlung von Stammzertifikaten auf die Smartcard zu schreiben oder einen HCERTSTORE zurückzugeben, der Stammzertifikate aus der Smartcard enthält Wird hauptsächlich für den Domänenbeitritt mit Smartcard verwendet Anrufer, der für das Schließen des Zertifikatspeichers zuständig ist
PP_SMARTCARD_READER	Schreibgeschützt (nur CryptGetProvParam) Gibt den Smartcardlesernamen als ANSI-Zeichenfolge zurück, die zum Erstellen eines vollqualifizierten Containernamens (Reader + Container) verwendet wird.
PP_SMARTCARD_GUID	Rückgabekarten-GUID (auch als Seriennummer bezeichnet), die für jede Smartcard eindeutig sein soll Wird vom Zertifikatverteilungsdienst verwendet, um die Quelle eines Stammzertifikats nachzuverfolgen
PP_UI_PROMPT	Wird verwendet, um die Suchzeichenfolge für das Einfügedialogfeld der SCardUIDlgSelectCard festzulegen Dauerhaft für den gesamten Prozess, sobald er festgelegt wurde Schreibgeschützt (nur von CryptSetProvParam verwendet)

Auswirkungen von CSPs in Windows Vista

CSP wird weiterhin in Windows Vista unterstützt. Es wird jedoch nicht empfohlen, insbesondere, wenn Sie mit Smartcards kommunizieren möchten. Die Verwendung des vorhandenen Basis-CSP und des Smartcard-KSP mit dem Minitreibermodell für Smartcards bietet erhebliche Vorteile hinsichtlich Leistung und PIN und Datenspeicherung. Derselbe Minitreiber kann so konfiguriert werden, dass er sowohl unter CAPI- als auch CNG-Ebenen funktioniert und von verbesserter kryptografischer Unterstützung, elliptischer Kurven-Kryptografie und AES profitiert.

Wenn eine Smartcard sowohl von einem CSP als auch von einem Smartcard-Minitreiber registriert wird, wird deren Installation zuletzt für die Kommunikation mit der Smartcard verwendet.

Wenn Sie einen Smartcard-Minitreiber, einen CSP oder einen KSP schreiben möchten

CSP und KSP sollen nur geschrieben werden, wenn bestimmte Funktionen in der aktuellen Smartcard-Minitreiberarchitektur nicht verfügbar sind. Die Smartcard-Minitreiberarchitektur unterstützt beispielsweise Hardwaresicherheitsmodule (HSMs), sodass kein CSP oder KSP erforderlich ist.

Weitere Informationen zum Schreiben eines Smartcard-Minitreibers, eines CSP oder eines KSP finden Sie unter Enterprise Smartcardbereitstellung im Microsoft Windows SmartCard Framework (https://go.microsoft.com/fwlink/?LinkId=93348).

Windows Vista Gruppenrichtlinie Einstellungen

In der folgenden Tabelle werden die Gruppenrichtlinie Einstellungen veranschaulicht, die pro Computer verwendet werden können. Es gibt keine Einstellungen pro Benutzer. Einige dieser Einstellungen können nur auf eine funktionale Domäne auf Windows Vista-Ebene angewendet werden, z. B. Domänenhinweise. Alle Schlüssel befinden sich unter \Policies\Microsoft\Windows\SmartCardCredentialProvider und \Policies\Microsoft\Windows\CertProp

Im Gruppenrichtlinie-Editor (gpedit.exe) können Sie Gruppenrichtlinie auf Computer in der Domäne bearbeiten und anwenden. Smartcard-bezogene Richtlinien sind unter

Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Smartcard

Abbildung 7 Smartcard-bezogene Einstellungen in Gruppenrichtlinie

Nachdem der Domänenadministrator sie angewendet hat, befindet er sich auf dem lokalen Computer des Benutzers in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SmartCardCredentialProvider

Tabelle 7 Gruppenrichtlinie Einstellungen

Schlüssel	BESCHREIBUNG
AllowSignatureOnlyKeys	Ermöglicht Signaturschlüsseln, die für die Anmeldung gültig sind. Diese Einstellung gilt auch, wenn die Benutzeroberfläche der Anmeldeinformationen aufgerufen wird. Mithilfe dieser Einstellung können Signaturschlüsselbasierte Zertifikate aufgezählt und für die Anmeldung verfügbar sein. 1 (Aktiviert): Alle zertifikate, die auf der Smartcard mit einem signaturgeschützten Schlüssel verfügbar sind, werden auf dem Anmeldebildschirm aufgelistet. 0 (Deaktiviert): Alle verfügbaren Smartcardsignaturschlüsselbasierte Zertifikate werden nicht auf dem Anmeldebildschirm aufgeführt. Nicht konfiguriert: Alle verfügbaren Smartcardsignaturschlüsselbasierte Zertifikate werden nicht auf dem Anmeldebildschirm aufgeführt.
AllowCertificatesWithNoEKU	Ermöglicht Zertifikaten, ohne dass ein EKU-Satz für die Anmeldung verwendet werden soll. In früheren Versionen von Windows war die EKU-Erweiterung erforderlich, um die Smartcard-Anmeldeobjekt-ID vorhanden zu haben. Diese Einstellung steuert diese Einschränkung. 1 (Aktiviert): Nur die smartcardbasierten Zertifikate, die den Smartcard-Anmeldeobjektbezeichner enthalten, oder keine EKU-Erweiterung wird auf dem Anmeldebildschirm aufgeführt. 0 (Deaktiviert): Nur diese Smartcard-basierten Zertifikate, die den Smartcard-Anmeldeobjektbezeichner enthalten, werden auf dem Anmeldebildschirm aufgelistet. Nicht konfiguriert: Nur diese smartcardbasierten Zertifikate, die den Anmeldeobjektbezeichner der Smartcard enthalten, werden auf dem Anmeldebildschirm aufgelistet.
AllowTimeInvalidCertificates	Ermöglicht die Anzeige von Zertifikaten für die Anmeldung, die entweder abgelaufen ist oder noch nicht gültig ist. In früheren Versionen von Windows mussten Zertifikate eine gültige Uhrzeit enthalten und nicht abgelaufen sein. Das Zertifikat muss weiterhin vom Domänencontroller akzeptiert werden, um verwendet zu werden. Diese Einstellung steuert nur, ob das Zertifikat auf dem Clientcomputer angezeigt wird. 1 (Aktiviert): Zertifikate werden auf dem Anmeldebildschirm aufgelistet, unabhängig davon, ob sie ungültige Zeiten haben oder die Gültigkeitsdauer abgelaufen ist. 0 (Deaktiviert): Zertifikate, die abgelaufen sind oder noch nicht gültig sind, werden auf dem Anmeldebildschirm nicht aufgeführt. Nicht konfiguriert: Zertifikate, die abgelaufen sind oder noch nicht gültig sind, werden auf dem Anmeldebildschirm nicht aufgeführt.
AllowIntegratedUnblock	Ermöglicht Es Ihnen, zu bestimmen, ob das integrierte Unblock-Feature in der Anmeldeoberfläche verfügbar ist. Um das integrierte Unblock-Feature zu verwenden, muss Ihre Smartcard dieses Feature unterstützen. Fragen Sie Ihren Hardwarehersteller, ob Ihre Smartcard dieses Feature unterstützt. 1 (Aktiviert): Integriertes Unblockierungsfeature ist verfügbar. 0 (Deaktiviert): Integrierte Unblockierungsfunktion ist nicht verfügbar. Nicht konfiguriert: Integriertes Unblock-Feature ist nicht verfügbar.
ReverseSubject	Ermöglicht es Ihnen, den Betreffnamen von der Speicherung im Zertifikat beim Anzeigen während der Anmeldung rückgängig zu machen. Standardmäßig wird der Benutzerprinzipalname (USER Principal Name, UPN) zusätzlich zum allgemeinen Namen angezeigt, damit Benutzer ein Zertifikat von einem anderen unterscheiden können. Wenn der Zertifikatsubjekt z. B. CN=User1, OU=Users, DN=contoso, DN=com ist und ein UPN von user1@contoso.com, wird "User1" zusammen mit "user1@contoso.com" angezeigt. Wenn der UPN nicht vorhanden ist, wird der gesamte Betreffname angezeigt. Diese Einstellung steuert das Aussehen dieses Betreffnamens und muss möglicherweise pro Organisation angepasst werden. 1 (Aktiviert): Betreffname wird umgekehrt. 0 (Deaktiviert): Der Betreffname wird angezeigt, wie es im Zertifikat angezeigt wird. Nicht konfiguriert: Der Betreffname wird umgekehrt.
X509HintsNeeded	Ermöglicht es Ihnen, zu bestimmen, ob ein optionales Feld während der Anmeldung und Erhöhung angezeigt wird, mit der ein Benutzer seinen Benutzernamen oder benutzernamen oder seine Domäne eingeben kann, wodurch ein Zertifikat diesem Benutzer zugeordnet wird. 1 (Aktiviert): Ein optionales Feld wird angezeigt, mit dem ein Benutzer seinen Benutzernamen oder benutzernamen und seine Domäne eingeben kann. 0 (Deaktiviert): Das optionale Feld wird nicht angezeigt. Nicht konfiguriert: Das optionale Feld wird nicht angezeigt.
IntegratedUnblockPromptString	Ermöglicht es Ihnen, eine bestimmte Zeichenfolge zu verwalten, wenn eine Smartcard blockiert wird. 1 (Aktiviert): Angegebene Zeichenfolge wird dem Benutzer angezeigt, wenn die Smartcard blockiert wird. Hinweis Sie müssen auch sicherstellen, dass Sie die folgende Einstellung in Gruppenrichtlinie aktivieren: Zulassen, dass der Bildschirm "Integrierte Blockierung aufheben" zum Zeitpunkt der Anmeldung angezeigt wird. 0 (Deaktiviert): Standardzeichenfolge wird dem Benutzer angezeigt, wenn die Smartcard blockiert wird, wenn die integrierte Blockierungsfunktion aktiviert ist. Nicht konfiguriert: Die Standardzeichenfolge wird dem Benutzer angezeigt, wenn die Smartcard blockiert wird, wenn das integrierte Unblock-Feature aktiviert ist.
CertPropEnabledString	Ermöglicht es Ihnen, die Zertifikatweitergabe zu verwalten, die auftritt, wenn eine Smartcard eingefügt wird. 1 (Aktiviert): Die Zertifikatverteilung tritt auf, wenn Sie Ihre Smartcard einfügen. 0 (Deaktiviert): Die Zertifikatverteilung tritt nicht auf, und die Zertifikate werden nicht für Anwendungen wie Outlook zur Verfügung gestellt. Nicht konfiguriert: Die Zertifikatweitergabe tritt auf, wenn Sie Ihre Smartcard einfügen.
CertPropRootEnabledString	Ermöglicht es Ihnen, die Stammzertifikatweitergabe zu verwalten, die auftritt, wenn eine Smartcard eingefügt wird. 1 (Aktiviert): Die Stammzertifikatverteilung tritt auf, wenn Sie Ihre Smartcard einfügen. Hinweis Damit diese Richtlinieneinstellung funktioniert, muss auch die folgende Richtlinieneinstellung aktiviert sein: Aktivieren Sie die Zertifikatweitergabe von Smartcard. 0 (Deaktiviert): Stammzertifikate werden nicht von der Smartcard weitergegeben. Nicht konfiguriert: Die Stammzertifikatverteilung tritt auf, wenn Sie Ihre Smartcard einfügen.
RootsCleanupOption	Ermöglicht Ihnen das Konfigurieren der Stammzertifikatbereinigung. Diese Option befindet sich in HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\CertProp. Ermöglicht Ihnen das Verwalten des Bereinigungsverhaltens von Stammzertifikaten. Wenn Sie diese Richtlinieneinstellung aktivieren, tritt die Stammzertifikatbereinigung entsprechend der ausgewählten Option auf. Wenn Sie diese Einstellung deaktivieren oder nicht konfigurieren, tritt die Stammzertifikatbereinigung beim Abmelden auf. Zu den Optionen für die Stammzertifikatbereinigung gehören: Keine Bereinigung (Standard) Bereinigen von Zertifikaten auf smartcard entfernung Bereinigen von Zertifikaten beim Abmelden des Benutzers Hinweis Diese Richtlinie funktioniert in Verbindung mit HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots\Flags. Wenn dies (standardmäßig deaktiviert) ist, werden Stammzertifikate für die Verteilung deaktiviert, auch von der Smartcard.
Smartcard (Computerrichtlinie) erforderlich – Richtlinien für interaktive Anmeldung. Siehe Abbildung 9.	Erzwingt smartcards, die für die Anmeldung pro Computer erforderlich sind. Dieser Schlüssel befindet sich in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Policies\System\scforceoption. Nachfolgend sind die unterstützten Werte aufgeführt: 0: Keine Aktion 1: Für die Anmeldung erforderliche Smartcard aktivieren
Richtlinie zum Entfernen von Smartcards – Richtlinien für interaktive Anmeldung. Siehe Abbildung 10.	Hinweis Wenn der Smartcard-Entfernungsrichtliniendienst nicht ausgeführt wird, starten Sie den Dienst mit dem Befehl: Net starten Sie ScPolicySvc und legen Sie den Starttyp auf "Auto" fest (sc config scpolicysvc start= auto). Dieser Schlüssel befindet sich in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\scremoveoption. Wenn dies festgelegt ist (standardmäßig 0, 0), wird die Smartcard entfernt. Nachfolgend sind die unterstützten Werte aufgeführt: 0: Keine Aktion 1: Arbeitsstation sperren – Benutzersitzung auf smartcard entfernung gesperrt 2: Abmelden – Benutzer, der sich bei der Entfernung von Smartcard angemeldet hat 3: Trennen Sie die Verbindung mit der Remote-Terminalserversitzung – Das Entfernen der Smartcard trennt die Sitzung, ohne den Benutzer abzumelden. Dadurch kann der Benutzer die Smartcard einfügen und die Sitzung später fortsetzen oder an einem anderen smartcardleserfähigen Terminal, ohne sich erneut anmelden zu müssen.
FilterDuplicateCertificates	Ermöglicht ihnen, zu konfigurieren, ob alle gültigen Anmeldezertifikate angezeigt werden. Während des Zertifikatverlängerungszeitraums kann ein Benutzer über mehrere gültige Anmeldezertifikate verfügen, die aus derselben Zertifikatvorlage ausgestellt wurden. Dies kann Verwirrung darüber verursachen, welches Zertifikat für die Anmeldung ausgewählt werden soll. Der häufige Fall für dieses Verhalten ist, wenn ein Zertifikat erneuert wird und die alte noch nicht abgelaufen ist. Zwei Zertifikate werden bestimmt, wenn sie aus derselben Vorlage mit derselben Hauptversion ausgestellt werden, und sie sind für denselben Benutzer (bestimmt durch ihr UPN) bestimmt. Wenn sich zwei oder mehr des "gleichen" Zertifikats auf einer Smartcard befinden und diese Richtlinie aktiviert ist, wird das Zertifikat, das für die Anmeldung auf Windows 2000, Windows XP und Windows 2003 Server verwendet wird, angezeigt. Andernfalls wird das Zertifikat mit der Ablaufzeit in Zukunft am weitesten angezeigt. Hinweis Diese Einstellung wird nach der folgenden Einstellung angewendet: Zeit für ungültige Zertifikate zulassen. 1 (Aktiviert): Filterung tritt auf. 0 (Deaktiviert): Es tritt keine Filterung auf. Nicht konfiguriert: Filterung tritt auf.
ForceReadingAllCertificates	Ermöglicht es Ihnen, das Lesen aller Zertifikate aus der Smartcard zu erzwingen, unabhängig von dem unterstützten Feature, das im CSP festgelegt ist. Diese Richtlinie gilt, wenn der Smartcard-Anmeldeinformationsanbieter oder die Benutzeroberfläche der Anmeldeinformationen aufgerufen wird. 1 (Aktiviert): Windows versucht, alle Zertifikate auf der Smartcard zu lesen, unabhängig vom Featuresatz im CSP. 0 (Deaktiviert): Windows liest nur den Standardcontainer der Smartcard für die Anmeldung, es sei denn, es unterstützt das Abrufen aller Zertifikate in einem einzigen Anruf. Zertifikate, die an anderer Stelle als im Standardcontainer gespeichert sind, sind für die Anmeldung nicht verfügbar. Nicht konfiguriert: Windows liest nur den Standardcontainer der Smartcard für die Anmeldung, es sei denn, es unterstützt das Abrufen aller Zertifikate in einem einzigen Aufruf. Zertifikate, die an anderer Stelle als im Standardcontainer gespeichert sind, sind für die Anmeldung nicht verfügbar.

Die folgende Gruppenrichtlinie Einstellung befindet sich in der Registrierung unter HKLM\SYSTEM\CCS\Services\Kdc\Parameters\.

Tabelle 8

Schlüssel	BESCHREIBUNG
SCLogonEKUNotRequired	Wenn Sie diese Einstellung aktivieren, erfordert die KDC nicht das Smartcardzertifikat, das die SmartcardauthentifizierungS-EKU enthält. Typ: DWORD Standardwert: 0

Hinweis

Bei der Bereitstellung sind möglicherweise zusätzliche Richtlinien erforderlich, um die Verwendung zu erleichtern oder die Sicherheit zu verbessern. Einige dieser Richtlinien umfassen:

Deaktivieren der Delegierung für Computer.

Interaktive Anmeldung: Nicht STRG+ALT+DEL erforderlich (nicht empfohlen).

Lokale CSP-Einstellungen

Die lokalen Einstellungen für den Basis-CSP befinden sich in der Registrierung unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Base Smartcard Crypto Provider.

Hinweis

Die lokalen KSP-Einstellungen der Smartcard befinden sich unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft Smartcardschlüssel Storage Anbieter.

Sie können die gleichen Schlüssel sowohl für den Basis-CSP als auch für den KSP konfigurieren. Tabelle 9 zeigt diese Schlüssel an.

Tabelle 9 Lokale Richtlinieneinstellungen für Basis-CSP und Smartcard-KSP

Schlüssel	BESCHREIBUNG
DefaultPrivateKeyLenBits	Typ: DWORD Standardwert: 00000400 Standardschlüsselgenerierungsparameter: 1024-Bit-Schlüssel
RequireOnCardPrivateKeyGen	Wenn dieser Wert festgelegt ist, kann ein schlüssel, der auf einem Host generiert wird, in die Smartcard importiert werden. Dies wird für Smartcards verwendet, die keine On-Card-Schlüsselgenerierung unterstützen oder bei der Schlüssel-Escrow erforderlich ist. Typ: DWORD Standardwert: 00000000. Dies legt das Flag für die Anforderung von privaten Schlüsselgenerierungen auf Der Karte (Standard) fest.
TransactionTimeoutMillisekunden	Typ: DWORD Standardwert: 000005dc1500. 1,5 Sekunden ist das Standardzeitout für die Aufbewahrung von Transaktionen auf die Smartcard.
AllowPrivateECDHEKeyImport	Dieser Wert ermöglicht den Import von ECDHE privatem Schlüssel für die Verwendung in Schlüsselarchivszenarien. Typ: DWORD Standardwert: 00000000.
AllowPrivateECDSAKeyImport	Dieser Wert ermöglicht den Import des privaten ECDSA-Schlüssels für die Verwendung in Schlüsselarchivszenarien. Typ: DWORD Standardwert: 00000000

Gruppenrichtlinie Richtlinien für Administratoren, die nur Smartcard-Anmeldung bereitstellen

Konfigurieren eines Benutzerkontos für die nur smartcardgeschützte Anmeldung

So konfigurieren Sie ein Benutzerkonto für die Nur-Anmeldung für die Smartcard

1. Melden Sie sich als Domänenadministrator an einem Windows Servercomputer an.

2. Klicken Sie auf "Start", klicken Sie auf "Ausführen", geben Sie "DSA.msc" ein, und klicken Sie dann auf "OK".

3. Erweitern Sie in der Konsolenstruktur Active Directory-Benutzer und -Computer, erweitern Sie die Domäne, die Sie konfigurieren möchten, und klicken Sie dann auf "Benutzer".

4. Klicken Sie im Detailbereich mit der rechten Maustaste auf den Benutzer, den Sie nur für die Smartcard-Anmeldung aktivieren möchten, und klicken Sie dann auf "Eigenschaften".

5. Klicken Sie im Dialogfeld "Kontoeigenschaften" auf die Registerkarte "Konto ".

6. Wählen Sie unter "Kontooptionen" das Kontrollkästchen " Smartcard" für interaktive Anmeldungen aus , und klicken Sie dann auf "OK".

   Abbildung 8 zeigt diese Konfiguration.

Abbildung 8 Keine Delegierung und Smartcard erforderliche Domäneneinstellung für Benutzerkonten

Abbildung 9 zeigt, wie die Einstellung in Abbildung 8 die lokale Richtlinieneinstellung konfiguriert.

Abbildung 9 Erfordern einer Smartcardeinstellung (erzwungen pro Computer)

Abbildung 10 zeigt, wie Sie die Smartcard-Entfernungsrichtlinie aktivieren.

Abbildung 10 Smartcard-Entfernungseinstellung

In smartcard-only-Umgebungen wäre eine nützliche Richtlinieneinstellung das Deaktivieren von STRG+ALT+DEL. Abbildung 11 zeigt, wo Sie dies in Gruppenrichtlinie konfigurieren können.

Abbildung 11 Erfordert keine STRG+ALT+DEL bei der Anmeldebildschirmeinstellung

Abbildung 12 zeigt, wie Benutzerkonten oder Computer für die Delegierung aktiviert werden. Wir empfehlen dringend, alle Änderungen, die Sie für Benutzer und Computer vornehmen, sorgfältig zu berücksichtigen. Sicherheitsrisiken könnten in einigen Szenarien sehr hoch sein. Die Delegierung kann jedoch nützlich sein, wenn Sie Windows verwaltete Instrumentierung (WMI) ausführen.

Abbildung 12 Benutzer- und Computerdelegierungseinstellung

Wenn Smartcardadministratoren den Computer verwenden, empfehlen wir dringend, die Delegierung auf dem Computer zu deaktivieren. Abbildung 13 zeigt diese Einstellung in Gruppenrichtlinie.

Abbildung 13 Nicht vertrauenswürdig für die Delegierungsdomäneneinstellung

Windows Vista Services

Drei Dienste in Windows Vista aktivieren die Smartcardverwaltung:

• Smartcard-Ressourcen-Manager-Dienst
• Zertifikatweiterleitungsdienst
• Smartcard-Entfernungsdienst

Smartcard-Ressourcen-Manager-Dienst

Der Smartcard-Ressourcen-Manager stellt die grundlegende Infrastruktur für alle anderen Smartcardkomponenten bereit. Der Smartcard-Ressourcen-Manager verwaltet Smartcardleser und Anwendungsinteraktionen auf dem Computer. Es ist vollständig PC/SC 1.0 konform.

Der Smartcard-Ressourcen-Manager wird im Kontext eines lokalen Diensts ausgeführt und wird als freigegebener Dienst des svchost-Prozesses implementiert. Der Smartcard-Ressourcen-Manager-Dienst verfügt über die folgende Dienstbeschreibung:

<serviceData name="SCardSvr"
displayName="@%SystemRoot%\System32\SCardSvr.dll,-1"
errorControl="normal" group="SmartCardGroup" 
imagePath="%SystemRoot%\system32\svchost.exe /k
LocalService" start="demand" tag="" 
type="win32ShareProcess" security=""
description="@%SystemRoot%\System32\SCardSvr.dll,-5
requiredPrivileges="SeCreateGlobalPrivilege,SeChangeNotifyPrivilege,SeImpersonatePrivilege" 
dependOnGroup="" dependOnService="PlugPlay" 
objectName="NT AUTHORITY\LocalService">
     <failureActions resetPeriod="900">
       <actions>
         <action type="restartService" delay="120000"/>
         <action type="restartService" delay="300000"/>
         <action type="none" delay="0"/>
       </actions>
     </failureActions>
     <registryKeys>
       <registryKey keyName="HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SCardSvr\Parameters">
        <registryValue name="ServiceDll" valueType="REG_EXPAND_SZ" value="%SystemRoot%\System32\SCardSvr.dll" buildFilter=""></registryValue>
        <registryValue name="ServiceMain" valueType="REG_SZ" value="CalaisMain" buildFilter=""></registryValue>
        <registryValue name="ServiceDllUnloadOnStop" valueType="REG_DWORD" value="1" buildFilter=""></registryValue>
       </registryKey>
       <securityDescriptor name="ServiceXKeySecurity"/>
     </registryKeys>
     <securityDescriptor name="ServiceXSecurity" buildFilter=""/>
  </serviceData>

Hinweis

Die Inf-Datei sollte folgendes für die Klasse und ClassGUID angeben, damit winscard.dll als richtiges Klasseninstallationsprogramm aufgerufen werden soll:

Class=SmartCardReader

ClassGuid={50DD5230-BA8A-11D1-BF5D-000F805F5F530}

Standardmäßig ist der Dienst für den manuellen Modus konfiguriert. Smartcard-Treiberautoren müssen den Dienst konfigurieren, um automatisch zu starten und einen vordefinierten Einstiegspunkt in winscard.dll aufzurufen, der den Dienst startet. Mit dieser Methode wird sichergestellt, dass der Dienst aktiviert wird, wenn es benötigt wird, aber auch für die großteil der Benutzer deaktiviert ist, die keine Smartcards verwenden.

Wenn der Dienst gestartet wird, führt er mehrere Buchführungsfunktionen aus. Der Dienst registriert sich zuerst für Dienstbenachrichtigungen. Es registriert sich auch für Plug & Play (PnP)-Benachrichtigungen für die Entfernung und Ergänzung von Geräten. Außerdem initialisiert er seinen Datencache und ein globales Ereignis, das signalisiert, dass der Dienst gestartet wurde.

Es wird dringend empfohlen, alle Kommunikationen mit Smartcardlesern über den Smartcard-Ressourcen-Manager zu Windows zu senden. Es bietet eine umfassende Schnittstelle zum Nachverfolgen, Auswählen und Kommunizieren mit allen Treibern, die selbst Mitglieder der Smartcardlesergerätegruppe deklarieren. Der Smartcard-Ressourcen-Manager kategorisiert jeden Smartcardleser-Platz als einzigartiger Leser. Jeder Steckplatz wird auch separat verwaltet, unabhängig von den physischen Merkmalen des Geräts. Der Smartcard-Ressourcen-Manager behandelt die folgenden Aktionen auf hoher Ebene:

• Geräteeinführung
• Initialisierung des Lesers
• Benachrichtigen von Clients von neuen Lesern
• Serialisieren des Zugriffs auf Leser
• Smartcardzugriff
• Tunneln von lesespezifischen Befehlen

Zertifikatweiterleitungsdienst

Der Zertifikatweitergabedienst gilt, wenn ein angemeldeter Benutzer eine Smartcard in einen Lesegerät einfügt, der an den Computer angefügt ist. Diese Aktion bewirkt, dass die Zertifikats(n) aus der Smartcard gelesen werden. Die Zertifikate werden dann dem persönlichen Speicher des Benutzers hinzugefügt. Die Dienstaktion wird mit Gruppenrichtlinie gesteuert, wie in Tabelle 7 dargestellt.

Abbildung 14 zeigt den Fluss des Zertifikatweiterleitungsmodells. Im Diagramm fügt ein angemeldeter Benutzer eine Smartcard ein. Der erste Pfeil gibt an, dass der Dienstcontroller CertPropSvc benachrichtigt, wenn sich ein Benutzer angemeldet hat. Bei der Anmeldebenachrichtigung beginnt CertPropSvc, die Smartcards zu überwachen, die von der Benutzersitzung sichtbar sind. Der Pfeil mit der Markierung R stellt die Möglichkeit einer Remotesitzung und die Verwendung der Smartcardumleitung dar.

Abbildung 14 Zertifikatweiterleitungsdienst

1. Ein angemeldeter Benutzer fügt eine Smartcard ein.
2. CertPropSvc wird benachrichtigt, dass eine Smartcard eingefügt wurde.
3. CertPropSvc liest alle Zertifikate aus allen eingefügten Smartcards. Die Zertifikate werden in den persönlichen Zertifikatspeicher des Benutzers geschrieben.

Hinweis

Der Zertifikatweiterleitungsdienst wird als Abhängigkeit vom Terminaldienstedienst gestartet.

Die folgenden Listen Eigenschaften des Zertifikatweiterleitungsdiensts:

• Der Dienst verwendet die Eigenschaft CERT_STORE_ADD_REPLACE_EXISTING_INHERIT_PROPERTIES, um Zertifikaten zum persönlichen Speicher eines Benutzers hinzuzufügen.
• Wenn das Zertifikat über die CERT_ENROLLMENT_PROP_ID-Eigenschaft (wie durch wincrypt.h definiert) verfügt, werden keine leeren Anforderungen an den persönlichen Speicher des Benutzers verteilt, aber sie werden gefiltert, um im Anforderungsspeicher des aktuellen Benutzers platziert zu werden.
• Der Dienst verteilt keine Computerzertifikate an den persönlichen Speicher eines Benutzers oder umgekehrt.
• Der Dienst verteilt Zertifikate gemäß Gruppenrichtlinie Optionen. Diese Optionen werden in Tabelle 7 beschrieben.
  • CertPropEnabledString: Gibt an, ob das Zertifikat eines Benutzers verteilt werden soll.
  • CertPropRootEnabledString: Gibt an, ob Stammzertifikate verteilt werden sollen, einschließlich Optionen für die Bereinigung.

Stammzertifikatweiterleitung

Die Stammzertifikatweiterleitung ist für bestimmte Smartcardbereitstellungsszenarien verantwortlich, in denen die PKI-Vertrauensstellung noch nicht eingerichtet wurde:

• Teilnehmen an der Domäne
• Remotezugriff auf ein Netzwerk

In beiden Fällen ist der Computer nicht mit einer Domäne verbunden und wird daher nicht von Gruppenrichtlinie verwaltet. Das Ziel besteht jedoch darin, eine Authentifizierung auf einem Remoteserver (dem Domänencontroller oder dem RADIUS-Server) durchzuführen. Die Stammzertifikatweiterleitung bietet die Möglichkeit, die Smartcard zu verwenden, um die fehlende Vertrauenskette einzuschließen.

Bei der Einfügemarke der Smartcard wird der Zertifikatweitergabedienst alle Stammzertifikate auf der Karte an den vertrauenswürdigen Stammcomputerspeicher verteilen. Dieser Prozess stellt eine Vertrauensstellung mit dem Unternehmen her. Sie können auch eine nachfolgende Bereinigungsaktion verwenden, wenn die Smartcard des Benutzers aus dem Leser entfernt wird, oder wenn sich der Benutzer abmeldet. Tabelle 7 zeigt, wie dies mit Gruppenrichtlinie konfigurierbar ist.

Weitere Informationen zu Stammzertifikatanforderungen finden Sie unter SmartCard-Stammzertifikatanforderungen für Benutzer mit einem Domänenbeitritt.

Smartcard-Entfernungsrichtliniendienst

Die Smartcard-Entfernungsrichtlinie gilt, wenn sich ein Benutzer mit einer Smartcard angemeldet hat und anschließend diese Smartcard aus dem Leser entfernt. Die Aktion, die ausgeführt wird, wenn die Smartcard entfernt wird, wird mit Gruppenrichtlinie gesteuert, wie in Tabelle 7 dargestellt.

Abbildung 15 Smartcard-Entfernungsrichtliniendienst

1. In Windows Vista ist Winlogon nicht mehr direkt an der Überwachung von Smartcard-Entfernungsereignissen beteiligt. Die Reihenfolge der Schritte, die in der Entfernungsrichtlinie beteiligt sind, beginnt mit dem Smartcard-Anmeldeinformationenanbieter im Anmeldeoberflächenprozess. Wenn sich ein Benutzer erfolgreich mit einer Smartcard anmeldet, erfasst der Smartcard-Anmeldeinformationenanbieter die Anzahl der Zeiten, zu denen die Smartcard eingefügt oder aus dem Leser entfernt wurde (die Aktivitätsanzahl), sowie den Lesernamen. Diese Informationen werden dann in der Registrierung gespeichert, zusammen mit dem Sitzungsbezeichner, in dem die Anmeldung initiiert wurde. Die Aktivitätsanzahl ist die obere 16 Bit des dwEventState-Felds des Lesers, wie von SCardGetStatusChange gesehen.
2. Der Smartcard-Ressourcen-Manager benachrichtigt den Smartcard-Entfernungsrichtliniendienst, dass eine Anmeldung aufgetreten ist.
3. ScPolicySvc ruft die Smartcardstatistiken aus der Registrierung ab, die der Smartcard-Anmeldeinformationenanbieter gespeichert hatte. Diese Statistiken werden verwendet, um sicherzustellen, dass die Smartcard nicht entfernt wurde und möglicherweise während des Handoffs zwischen dem Smartcard-Anmeldeinformationenanbieter, wenn und ScPolicySvc die Smartcard für Entfernungen überwacht hat. Dieser Aufruf wird umgeleitet, wenn sich der Benutzer in einer Remotesitzung befindet. Nachdem der Benutzer die Smartcard entfernt hat oder wenn die Smartcard während des Handoffs entfernt wurde, wird ScPolicySvc benachrichtigt.
4. ScPolicySvc ruft Terminalserver auf, um die entsprechende Aktion auszuführen, wenn die Anforderung den Benutzer abmelden oder die Sitzung des Benutzers trennen soll. (Dies kann zu Datenverlust führen.) Wenn die Einstellung zum Sperren des Computers konfiguriert ist, wenn die Smartcard entfernt wird, sendet ScPolicySvc eine Nachricht an Winlogon, um den Computer zu sperren.

Windows Vista-Szenarien

Zertifikatanforderungen für die Smartcard-Anmeldung

Zertifikatanforderungen für Windows XP und früher

Das Smartcardzertifikat verfügt über bestimmte Formatanforderungen, wenn sie mit Windows XP und früheren Plattformen verwendet wird.

Tabelle 10 Vorab-Windows Vista-Zertifikatanforderungen

Komponente	Anforderung
CRL-Verteilerpunkt (CDP) Standort	Der Speicherort muss ausgefüllt, online und verfügbar sein. Beispiel: [1] CRL-Verteilerpunkt Name des Verteilungspunkts: Vollständiger Name: URL=http://server1.contoso.com/CertEnroll/caname.crl
Schlüsselverwendung	Digitale Signatur
Grundlegende Einschränkungen	[Subject Type=End-Entität, Pfadlängeneinschränkung=Keine] (Optional)
Erweiterte Schlüsselverwendung	Clientauthentifizierung (1.3.6.1.5.5.7.3.2) (Der Clientauthentifizierungsobjektbezeichner ist nur erforderlich, wenn ein Zertifikat für DIE SSL-Authentifizierung verwendet wird.) SmartCard-Anmeldung (1.3.6.1.4.1.311.20.2.2.2)
Alternativer Antragstellername	Anderer Name: Principal Name= (UPN). Beispiel: UPN = user1@contoso.com Der UPN OtherName OID lautet "1.3.6.1.4.1.311.20.2.3". Der UPN OtherName-Wert muss ASN1-codierte UTF8-Zeichenfolge sein.
Thema	Unterschiedener Name des Benutzers. Dieses Feld ist eine obligatorische Erweiterung, aber die Bevölkerung dieses Felds ist optional.

Es gibt zwei vordefinierte Typen von privaten Schlüsseln. Diese Schlüssel sind Nur Signatur (AT_SIGNATURE) und Schlüssel Exchange (AT_KEYEXCHANGE). Smartcard-Anmeldezertifikate müssen über einen schlüssel-Exchange (AT_KEYEXCHANGE) privaten Schlüsseltyp verfügen, damit die Smartcard-Anmeldung ordnungsgemäß funktioniert.

Zertifikatanforderungen für Windows Vista

Tabelle 11 Windows Vista-Zertifikatanforderungen

Komponente	Anforderung
CRL	Nicht erforderlich
UPN	Nicht erforderlich
Schlüsselverwendung	Digitale Signatur
Erweiterte Schlüsselverwendung	Smartcard-Anmeldeobjektbezeichner ist nicht erforderlich. Siehe Tabelle 7.
Alternativer Antragstellername	Die E-Mail-ID ist für die Smartcard-Anmeldung nicht erforderlich. Siehe Tabelle 7.
Schlüsselaustausch (AT_KEYEXCHANGE Feld)	Für Smartcard-Anmeldezertifikate nicht erforderlich.

Sie können ein beliebiges Zertifikat aktivieren, das für den Smartcard-Anmeldeinformationsanbieter sichtbar ist. Wenn eine EKU vorhanden ist, muss sie die Smartcard-Anmelde-EKU enthalten. Zertifikate ohne EKU können für die Anmeldung verwendet werden.

Wie funktioniert die Smartcardanmeldung in Windows?

Obwohl Microsoft Windows 2000 und höhere Versionen Unterstützung für Smartcards enthalten, waren die Arten von Zertifikaten, die Smartcards enthalten könnten, eingeschränkt. Die Einschränkungen waren:

• Jedes Zertifikat muss über einen Benutzerprinzipalnamen (USER Principal Name, UPN) verfügen und die Smartcard-Anmeldeobjekt-ID (auch als OID bezeichnet) im EKU-Attributfeld enthalten. Wenn die EKU vorhanden ist, muss die Smartcardanmeldung OID vorhanden sein. Es gibt eine Gruppenrichtlinieneinstellung, um EKU optional zu machen.

• Jedes Zertifikat musste im AT_KEYEXCHANGE Teil des Standard-CAPI-Containers gespeichert werden.

  Hinweis

  Nicht standardmäßige CAPI-Container werden nicht unterstützt.

• Zertifikate sind erforderlich, um einen Wert für die Verwendung von digitalen Signaturschlüsseln zu haben. Diese Anforderung wird für Windows Vista fortgesetzt.

Um die Unterstützung für Smartcardbereitstellungen zu verbessern, wurden Änderungen an Windows vorgenommen, um die Unterstützung für eine Reihe von Zertifikaten zu ermöglichen, die nicht über die vorherigen Einschränkungen verfügen.

Smartcardbasierte Anmeldung in Windows Vista

Die Smartcardanmeldung auf Windows Vista hat sich in mehreren wichtigen Aspekten geändert. Die wichtigsten Unterschiede sind unten hervorgehoben:

• Die Anmeldung wird nicht mehr bei der Einfügemarke der Smartcard ausgelöst. Benutzer müssen normalerweise STRG+ALT+DEL drücken, um den Anmeldevorgang zu starten.
• Gültige Zertifikate werden aufgezählt und von allen Smartcards angezeigt und dem Benutzer angezeigt. Die Smartcard muss eingefügt werden, bevor der Benutzer die PIN eingeben kann.
• Schlüssel sind nicht mehr auf das Standardcontainer beschränkt, und Zertifikate in verschiedenen Smartcards können ausgewählt werden.
• Auf den CSP wird in lsass.exe zugegriffen (wie in smartcard-Anmeldung Flow in Windows Vista beschrieben). Der CSP wird nie in den Winlogon-Prozess geladen.
• Mehrere Terminaldienstesitzungen werden in einem einzelnen Prozess unterstützt. Da Windows Vista in Terminaldienste integriert ist, um schnellen Benutzerwechsel bereitzustellen, sollten Sie diese Tatsache nicht übersehen.
• ECC-basierte Zertifikate werden für die Smartcardanmeldung in Windows nicht unterstützt. ECC-basierte PKINIT wird weiterhin als Teil von IETF (http://www.ietf.org/html.charters/krb-wg-charter.html) standardisiert.

Zertifikataufzählung

Wenn eine Smartcard eingefügt wird, werden die folgenden Schritte ausgeführt:

Hinweis

Sofern nicht anders erwähnt, werden alle Vorgänge automatisch ausgeführt (CRYPT_SILENT wird an CryptAcquireContext übergeben).

1. Die Datenbank des Smartcard-Ressourcen-Managers fragt nach dem CSP der Smartcard.
2. Ein qualifizierter Containername wird mithilfe des abgerufenen Lesernamens erstellt und an den CSP übergeben. Das Format für diesen Namen lautet wie folgt: \\.\<Reader name>\
3. CryptAcquireContext wird aufgerufen, um einen Kontext für den Standardcontainer abzurufen. Ein Fehler hier würde dazu führen, dass die Smartcard für die Smartcardanmeldung nicht verwendet werden kann.
4. Der Name des Containers wird abgerufen, indem der PP_CONTAINER Parameter mithilfe von CryptGetProvParam angefordert wird.
5. Mit dem in Schritt 3 erworbenen Kontext wird der CSP für den PP_USER_CERTSTORE Parameter abgefragt, der in Windows Vista hinzugefügt wurde. (Weitere Informationen finden Sie in der Smartcard-Subsystemarchitektur.) Wenn der Vorgang erfolgreich ist, wird ein Zertifikatspeicher zurückgegeben, und der Programmfluss wird zu Schritt 8 übersprungen.
6. Wenn der Vorgang in Schritt 5 fehlschlägt, wird der Standardcontainerkontext aus Schritt 3 für den AT_KEYEXCHANGE-Schlüssel abgefragt.
7. Das Zertifikat wird dann über KP_CERTIFICATE vom Schlüsselkontext abgefragt. Das Zertifikat wird einem speicherinternen Zertifikatspeicher hinzugefügt.
8. Für jedes Zertifikat im Zertifikatspeicher aus Schritt 5 oder Schritt 7 werden die folgenden Prüfungen ausgeführt:
   1. Das Zertifikat muss basierend auf der Computersystemuhr gültig sein (nicht abgelaufen oder in zukunft gültig).
   2. Das Zertifikat darf nicht im AT_SIGNATURE Teil eines Containers enthalten sein.
   3. Das Zertifikat muss über einen gültigen UPN verfügen.
   4. Das Zertifikat muss über die Verwendung des Schlüssels für digitale Signaturen verfügen.
   5. Das Zertifikat muss über die Smartcard-Anmelde-EKU verfügen.
      Diese Anforderungen sind die gleichen Anforderungen wie in Windows 2003, aber sie werden ausgeführt, bevor der Benutzer die PIN eingibt. Sie können viele davon überschreiben, indem Sie Gruppenrichtlinie Einstellungen verwenden.
      Jedes Zertifikat, das diese Anforderungen erfüllt, wird dem Benutzer zusammen mit dem UPN des Zertifikats (oder der E-Mail-Adresse oder dem Betreff, abhängig vom Vorhandensein der Zertifikaterweiterungen) angezeigt.
9. Anschließend wird ein Zertifikat ausgewählt, und die PIN wird eingegeben.
10. LogonUI.exe packt die Informationen und sendet sie an lsass.exe, um den Anmeldeversuch zu verarbeiten.
11. Wenn dies erfolgreich ist, wird logonUI.exe abgerissen. Dies bewirkt, dass der in Schritt 3 erworbene Kontext freigegeben wird.

Smartcard-Anmeldefluss in Windows Vista

Die meisten Probleme während der Authentifizierung treten aufgrund des Sitzungsverhaltens auf. Außerdem erhält die LSA den Kontext nicht erneut; es basiert stattdessen auf dem CSP, um die Sitzungsänderung zu behandeln.

ermöglicht die Unterstützung von Clientzertifikaten, die keinen UPN im Feld subjectAltName (SAN) des Zertifikats enthalten und eine viel breitere Vielfalt von Zertifikaten unterstützt, einschließlich mehrerer Zertifikate.

Diese Änderungen sind jedoch nicht standardmäßig aktiviert, außer für die Unterstützung mehrerer Zertifikate. (Einige Zertifikate sind ausgeschlossen.) Administratoren müssen die Registrierungsschlüssel auf Clients (z. B. mit Gruppenrichtlinie) festlegen, um die Funktionalität zu aktivieren.

Clients würden standardmäßig die Zertifikate des Clients auf der Smartcard mithilfe der EKU der Clientauthentifizierung filtern. Der Anmeldeinformationsanbieter verfügt auch über eine Richtlinie, AllowSignatureOnlyKeys (entspricht dem AT_SIGNATURE Schlüsselwert in CAPI), um zu ermitteln, ob die Clientzertifikate basierend auf einer Anforderung gefiltert werden müssen, dass das Anmeldezertifikat verschlüsselungsfähig ist, indem der Benutzer die Anzeige und Auswahl von signaturgeschützten Zertifikaten ermöglicht. Diese Richtlinieneinstellungen haben direkte Auswirkungen auf die Filterung und die resultierende Anzeige von Zertifikaten auf der Anmelde-UI.

Abbildung 16 veranschaulicht, wie die Smartcardanmeldung in Windows Vista funktioniert.

Abbildung 16 Smartcard-Anmeldefluss

Flow Sequenz:

1. WinLogon fordert die Anmeldeinformationen für die Anmeldeinformationen der Benutzeroberfläche an.

2. Der Smartcard-Ressourcen-Manager wird asynchron gestartet. Der Smartcard-Anmeldeinformationsanbieter:

   1. Ruft Anmeldeinformationen, eine Liste bekannter Anmeldeinformationen oder keines ab, oder dass Windows einen Smartcardleser erkannt haben.
   2. Ruft eine Liste der Smartcardleser (verwendet WinSCard-API) und die Liste der smartcards, die in jedem dieser Karten eingefügt wurden.
   3. Listet jede Karte auf, um zu überprüfen, ob ein von Gruppenrichtlinie gesteuertes Anmeldezertifikat (Signieren) vorhanden ist. Wenn das Zertifikat vorhanden ist, kopiert der Smartcard-Anmeldeinformationsanbieter ihn in einen temporären sicheren Cache auf dem Terminal.
   4. Benachrichtigt die Anmelde-UI, dass sie über neue Anmeldeinformationen verfügt.

3. Die Anmelde-UI fordert die neuen Anmeldeinformationen vom Smartcard-Anmeldeinformationsanbieter an. Als Antwort stellt der Smartcard-Anmeldeinformationsanbieter die Anmeldeinformationen für jedes Anmeldezertifikat bereit, für das eine entsprechende Anmeldekachel angezeigt wird. Der Benutzer wählt eine Smartcard-basierte Anmeldezertifikatkachel aus, und Windows zeigt ein PIN-Dialogfeld an.

4. Der Benutzer gibt die PIN ein, und klickt auf "Los". Der Smartcard-Anmeldeinformationsanbieter verschlüsselt die PIN.

5. Der Anmeldeinformationsanbieter, der sich im LogonUI-Prozess (System) befindet, sammelt die PIN. Als Teil des Verpackens von Anmeldeinformationen im Smartcard-Anmeldeinformationsanbieter werden die Daten in einer KERB_CERTIFICATE_LOGON Struktur verpackt (definiert in CredentialProviders.h). Der Hauptinhalt der KERB_CERTIFICATE_LOGON Struktur sind Smartcard-PIN, cspdata (enthält Lesername, Containername usw.), Benutzername und Domänenname. Der Benutzername ist erforderlich, wenn sich die Anmeldedomäne nicht in derselben Gesamtstruktur befindet, da ein Zertifikat mehreren Benutzerkonten zugeordnet werden kann.

6. Der Anmeldeinformationsanbieter umschließt jetzt die Daten (z. B. verschlüsselte PIN, Containername, Lesername und Kartenschlüsselspezifikation) und wird an LogonUI zurückgesendet.

7. LogonUI stellt die Daten in LSA mit Winlogon für LSALogonUser dar.

8. LSA ruft Kerberos-Authentifizierungspaket (Kerberos-SSP) auf, um eine Kerberos-Authentifizierungsdienstanforderung (KRB_AS_REQ) mit einem Vorabauthentifikator (wie in RFC 4556 angegeben: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (https://go.microsoft.com/fwlink/?LinkId=93352)) zu erstellen.
   Wenn die Authentifizierung mithilfe eines Zertifikats mit einer wichtigen Digitalen Signatur verwendet wird, besteht die Vorauthentifizierungsdaten aus dem öffentlichen Zertifikat des Benutzers, und das Zertifikat wird digital mit dem entsprechenden privaten Schlüssel signiert.
   Wenn die Authentifizierung mit einem Zertifikat mit einer Schlüsselverwendung von Schlüsselenzipherment besteht, besteht die Vorauthentifizierungsdaten aus dem öffentlichen Zertifikat des Benutzers, und das Zertifikat wird mit dem entsprechenden privaten Schlüssel verschlüsselt.

9. Um die Anforderung digital zu signieren (gemäß RFC 4556), wird ein Aufruf an den entsprechenden CSP für einen privaten Schlüsselvorgang vorgenommen. Da der private Schlüssel in diesem Fall in einer Smartcard gespeichert ist, wird das Smartcard-Untersystem aufgerufen, und der erforderliche Vorgang wird abgeschlossen. Das Ergebnis wird an den Kerberos-SSP zurückgesendet.

10. Der Kerberos-SSP sendet eine Authentifizierungsanforderung (gemäß RFC 4556) an den KDC-Dienst (Key Distribution Center), der auf einem Domänencontroller ausgeführt wird, um ein Ticket-Bewilligungsticket (TGT) anzufordern.

11. Die KDC findet das Kontoobjekt des Benutzers im Active Directory, wie in Clientzertifikatzuordnungen beschrieben, und verwendet das Zertifikat des Benutzers, um die Signatur zu überprüfen.

12. Die KDC überprüft das Zertifikat des Benutzers (Uhrzeit, Pfad und Sperrstatus), um sicherzustellen, dass das Zertifikat aus einer vertrauenswürdigen Quelle stammt. Die KDC verwendet CryptoAPI (CAPI2), um einen Zertifizierungspfad vom Zertifikat des Benutzers zu einem Stammzertifizierungsstelle-Zertifikat zu erstellen, das sich im Stammspeicher des Domänencontrollers befindet. Die KDC verwendet dann CryptoAPI (CAPI2), um die digitale Signatur auf dem Authentifizierungsator zu überprüfen, der als signierte Daten in den Feldern vor der Authentifizierung enthalten war. Der Domänencontroller überprüft die Signatur und verwendet den öffentlichen Schlüssel aus dem Zertifikat des Benutzers, um zu beweisen, dass die Anforderung vom Besitzer des privaten Schlüssels stammt, der dem öffentlichen Schlüssel entspricht. Die KDC überprüft außerdem, ob der Aussteller vertrauenswürdig ist und im NTAUTH-Zertifikatspeicher angezeigt wird.

13. Der KDC-Dienst ruft Benutzerkontoinformationen aus Active Directory ab. Die KDC erstellt eine TGT basierend auf den Benutzerkontoinformationen, die sie aus Active Directory abruft. Die TGT enthält den Sicherheitsbezeichner (SID), die SIDs für universelle und globale Domänengruppen, zu denen der Benutzer gehört, und (in einer umgebung mit mehreren Domänen) die SIDs für alle universellen Gruppen, deren Mitglied der Benutzer ist. Die Autorisierungsdatenfelder des TGT enthalten die Liste der SIDs.

14. Der Domänencontroller gibt den TGT als Teil der KRB_AS_REP Antwort an den Client zurück.

    Hinweis

    Das KRB_AS_REP Paket besteht aus:

    Privilege-Attributzertifikat (PAC)

    Sicherheitsbezeichner des Benutzers (SID)

    SIDs aller Gruppen, von denen der Benutzer Mitglied ist

    Eine Anforderung für den Ticket-Bewilligungsdienst (TGS)

    Vorauthentifizierungsdaten

    Die Antwort lautet gemäß RFC 4556. TGT wird mit dem Masterschlüssel des KDC verschlüsselt, und der Sitzungsschlüssel wird mit einem temporären Schlüssel verschlüsselt. Dieser temporäre Schlüssel wird basierend auf RFC 4556 abgeleitet. Mit CAPI2-APIs wird der temporäre Schlüssel entschlüsselt. Wenn sich der private Schlüssel für dasselbe im Rahmen des Entschlüsselungsprozesses auf einer Smartcard befindet, wird der Aufruf an das Smartcard-Subsystem mithilfe des angegebenen Kryptografiedienstanbieters zurückgestellt, um das Zertifikat zu extrahieren, das dem öffentlichen Schlüssel des Benutzers entspricht. (Programmgesteuerte Aufrufe umfassen CryptAcquireContext, CryptSetProvParam mit der PIN, CryptgetUserKey, CryptGetKeyParam für das Zertifikat.) Nachdem der temporäre Schlüssel abgerufen wurde, entschlüsselt der \ Kerberos-SSP den Sitzungsschlüssel.

15. Der Client überprüft die Antwort aus dem KDC (Uhrzeit, Pfad und Sperrstatus). Sie überprüft zuerst die Signatur des KDC durch den Aufbau eines Zertifizierungspfads vom Zertifikat des KDC zu einer vertrauenswürdigen Stammzertifizierungsstelle, und anschließend wird der öffentliche Schlüssel des KDC verwendet, um die Antwortsignatur zu überprüfen.

16. Nachdem ein TGT abgerufen wurde, ruft der Client ein ServiceTicket an den lokalen Computer ab, um sich beim Computer anzumelden.

17. Bei Erfolg speichert LSA die Tickets und gibt Erfolg an den LSALogonUser zurück. Bei dieser Erfolgsmeldung werden Benutzerprofil, Gruppenrichtlinie und andere Aktionen ausgeführt.

18. Sobald das Benutzerprofil geladen wurde, nimmt CertPropSvc dieses Ereignis ab, liest die Zertifikate aus der Karte (einschließlich der Stammzertifikate) vor und füllt sie dann in den Zertifikatspeicher des Benutzers (MYSTORE).

19. CSP zur Smartcard-Ressourcen-Manager-Kommunikation erfolgt im LRPC-Kanal.

20. Bei erfolgreicher Authentifizierung werden Zertifikate asynchron vom Zertifikatverteilungsdienst (CertPropSvc) an den Speicher des Benutzers (MYSTORE) weitergegeben.

21. Wenn die Karte entfernt wird, werden Zertifikate im temporären sicheren Cachespeicher entfernt. Die Zertifikate sind nicht mehr für die Anmeldung verfügbar, aber sie bleiben der Zertifikatspeicher des Benutzers (MYSTORE).

Hinweis

Eine SID ist ein Sicherheitsbezeichner, der für jeden Benutzer oder jede Gruppe erstellt wird, wenn ein Benutzerkonto oder ein Gruppenkonto innerhalb der lokalen Sicherheitskontendatenbank auf Windows NT oder höheren Computern oder in Active Directory erstellt wird. Die SID ändert sich nie, auch wenn das Benutzer- oder Gruppenkonto umbenannt wird.

Weitere Informationen zu Kerberos finden Sie unter How the Kerberos Version 5 Authentication Protocol Protocol (https://go.microsoft.com/fwlink/?LinkID=27175).

Standardmäßig überprüft die KDC, dass das Zertifikat des Clients die EKU-szOID_KP_SMARTCARD_LOGON der Smartcard-Clientauthentifizierung enthält. Es gibt jedoch eine Richtlinie, mit der die KDC nicht die SC-LOGON EKU (SCLogonEKUNotRequired – Siehe Tabelle 7) erfordert. SC-LOGON EKU ist für Kontozuordnungen, die auf dem öffentlichen Schlüssel basieren, nicht erforderlich.

KDC-Zertifikat

Active Directory-Zertifikatdienste bieten drei Arten von Zertifikatvorlagen:

• Domänencontroller
• Domänencontrollerauthentifizierung
• Kerberos-Authentifizierung (neu in Windows Server® 2008)

Abhängig von der Konfiguration des Domänencontrollers wird eine dieser Zertifikattypen als Teil des AS_REP-Pakets gesendet. Weitere Informationen zu Zertifikatvorlagen finden Sie unter Active Directory-Zertifikatserververbesserungen in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=83212).

Clientzertifikatzuordnungen

Die Zertifikatzuordnung basiert auf dem UPN, das im Feld subjectAltName (SAN) des Zertifikats enthalten ist. Clientzertifikate, die die SubjectAltName-Erweiterung im Zertifikat nicht enthalten, werden ebenfalls unterstützt.

SSL/TLS kann Zertifikate zuordnen, die nicht ÜBER SAN verfügen, und die Zuordnung erfolgt mit den AltSecID-Attributen für Clientkonten. Die von SSL/TLS-Clientauthentifizierung verwendete X509 AltSecID ist das Formular "X509:<I>"<Ausstellername>"<S>"<Betreffname>. Hier werden der <Ausstellername und <der Antragstellername>> aus dem Clientzertifikat entnommen, wobei "\r" und "\n" durch "," ersetzt werden.

Abbildung 17 CRL-Verteilungspunkte

Abbildung 18 UPN im Feld "Alternativer Antragstellername"

Abbildung 19 Betreff- und Problemfelder

Diese Kontozuordnung wird von der KDC unterstützt. Das KDC unterstützt auch sechs weitere Zuordnungsmethoden. Die folgende Abbildung zeigt einen Fluss der Von KDC verwendeten Benutzerkontenzuordnungslogik.

Abbildung 20 Hoher Fluss der Zertifikatverarbeitung für die Anmeldung

Das Zertifikatobjekt wird analysiert, um nach bestimmten Inhalten zu suchen, um eine Benutzerkontozuordnung auszuführen. Wenn auch ein Benutzername mit dem Zertifikat angegeben wird, wird der Benutzername verwendet, um das Kontoobjekt zu suchen. Dieser Vorgang ist am schnellsten, da der Zeichenfolgenabgleich auftritt. Wenn nur das Zertifikatobjekt bereitgestellt wird, werden eine Reihe von Vorgängen ausgeführt, um den Benutzer zu suchen, um den Benutzer einem Kontoobjekt zuzuordnen. Wenn keine Domäneninformationen für die Authentifizierung verfügbar sind, wird die lokale Domäne standardmäßig verwendet. Wenn eine andere Domäne für die Nachschlagevorgänge verwendet werden soll, sollte ein Domänennamenhinweis bereitgestellt werden, um die Zuordnung und Bindung auszuführen. Die Zuordnung basierend auf generischen Attributen ist nicht möglich, da keine generische API zum Abrufen von Attributen aus einem Zertifikat vorhanden ist.

Derzeit gewinnt die erste Methode, die ein Konto erfolgreich findet, und die Suche wird beendet. Wenn jedoch zwei Zuordnungsmethoden dasselbe Zertifikat unterschiedlichen Benutzerkonten zuordnen, wenn der Client den Client nicht über die Zuordnungshinweise angibt, handelt es sich um einen Konfigurationsfehler.

Weitere Informationen zum Zuordnen von Zertifikaten zu Benutzerkonten finden Sie unter Deploying a Public Key Infrastructure (https://go.microsoft.com/fwlink/?LinkId=93737).

Abbildung 21 veranschaulicht den Prozess der Zuordnung von Benutzerkonten für die Anmeldung im Verzeichnis, indem sie verschiedene Einträge im Zertifikat betrachten. NT_AUTH Richtlinie wird in CertVerifyCertificateChainPolicy (https://go.microsoft.com/fwlink/?LinkId=93738) unter CERT_CHAIN_POLICY_NT_AUTH am besten beschrieben.

Abbildung 21 Zertifikatverarbeitungslogik

Smartcardanmeldung eines einzelnen Benutzers mit einem Zertifikat in mehreren Konten

Ein einzelnes Benutzerzertifikat kann mehreren Konten zugeordnet werden. Ein Benutzer kann sich beispielsweise bei seinem Benutzerkonto anmelden und sich auch als Domänenadministrator anmelden. Die Zuordnung erfolgt mithilfe der erstellten AltSecID basierend auf Attributen von Clientkonten. Informationen zur Auswertung dieser Zuordnung finden Sie unter Clientzertifikatzuordnungen.

Hinweis

Da jedes Konto einen anderen Benutzernamen hat, empfiehlt es sich, das X509Hints Gruppenrichtlinie-Objekt zu aktivieren, um die Benutzerinformationen bereitzustellen, bei denen er/sie sich anmelden möchte.

Im Folgenden werden die Bedingungen für die Anmeldung basierend auf dem Zertifikatinhalt aufgeführt:

1. Wenn kein UPN im Zertifikat vorhanden ist:
   1. Die Anmeldung kann in der lokalen Gesamtstruktur oder in einer anderen Gesamtstruktur auftreten, wenn ein einzelner Benutzer mit einem Zertifikat sich bei verschiedenen Konten anmelden muss.
   2. Ein Hinweis muss angegeben werden, wenn die Zuordnung nicht eindeutig ist (mehrere Benutzer, die demselben Zertifikat zugeordnet sind).
2. Wenn ein UPN im Zertifikat vorhanden ist:
   1. Das Zertifikat kann nicht mehreren Benutzern in derselben Gesamtstruktur zugeordnet werden.
   2. Das Zertifikat kann mehreren Benutzern in verschiedenen Gesamtstrukturen zugeordnet werden. Um benutzer in anderen Gesamtstrukturen zu anmelden, muss dem Benutzer ein X509-Hinweis bereitgestellt werden.

Smartcardanmeldung mehrerer Benutzer in einem einzigen Konto

Eine Gruppe von Benutzern kann sich bei einem einzelnen Konto anmelden (z. B. ein Administratorkonto). Für dieses Konto werden Benutzerzertifikate zugeordnet, damit sie für die Anmeldung aktiviert sind.

Mehrere unterschiedliche Zertifikate können auch einem einzelnen Konto zugeordnet werden (damit dies ordnungsgemäß funktioniert, kann das Zertifikat keine UPNs haben). 

Wenn z. B. Zertifikat1 CN=CNName1 hat, hat Zertifikat2 CN=User1 und Certificate3 CN=User2, kann die AltSecID dieser Zertifikate mithilfe der Active Directory-Benutzer und -Computer Namenszuordnung einem einzelnen Konto zugeordnet werden.

Smartcardanmeldung über Gesamtstrukturen

Damit die Kontozuordnung über Gesamtstrukturen hinweg funktioniert, insbesondere in Fällen, in denen nicht genügend Informationen für das Zertifikat verfügbar sind, kann der Benutzer einen Hinweis eingeben (in Form eines Benutzernamens wie "Domäne\Benutzer" oder eines vollqualifizierten UPNs wie z User@DNSNameOfDomain.com. B. "Domain\User").

Hinweis

Damit das Hinweisfeld während der Smartcardanmeldung angezeigt wird, muss der X509HintsNeeded-Registrierungsschlüssel auf dem Client festgelegt werden, um die Anzeige eines zusätzlichen Hinweisfelds auf die Anmeldebenutzeroberfläche mit dem PIN-Feld zu aktivieren (siehe Tabelle 7).

OCSP-Unterstützung für PKINIT

Das in RFC 2560 definierte Onlinezertifikatstatusprotokoll (OCSP) ermöglicht Es Anwendungen, zeitnahe Informationen zum Sperrstatus eines Zertifikats abzurufen. Da OCSP-Antworten klein und gut gebunden sind, können eingeschränkte Clients OCSP verwenden, um die Gültigkeit der Zertifikate für Kerberos-KDC zu überprüfen, um die Übertragung großer Zertifikatsperrlisten (CRLs) zu vermeiden und Bandbreite auf eingeschränkten Netzwerken zu speichern.

Microsofts KDC versucht immer, die OCSP-Antworten abzurufen und sie bei Verfügbarkeit zu verwenden. Es gibt keine Richtlinie, die verwendet werden kann, um dies zu deaktivieren. CAPI2-APIs für OCSP zwischenspeichert OCSP-Antworten und den Status der Antworten. KDC unterstützt nur OCSP-Antwort für Signierzertifikate.

Windows Clients versuchen immer, die OCSP-Antworten anzufordern und in der Antwort zu verwenden, wenn sie verfügbar sind. Es gibt keine Richtlinie, die verwendet werden kann, um dies zu deaktivieren.

Zertifikatsperrunterstützung

In Tabelle 12 werden die Schlüssel und die entsprechenden Werte zum Deaktivieren der CRL-Überprüfung (auf dem Draht) am KDC oder Client aufgeführt. Beide Einstellungen sind erforderlich.

Tabelle 12 CRL-Überprüfung von Registrierungsschlüsseln

Schlüssel	BESCHREIBUNG
HKLM\SYSTEM\CCS\Services\Kdc\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors	Type = DWORD Value = 1
HKLM\SYSTEM\CCS\Control\LSA\Kerberos\Parameters\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors	Type = DWORD Value = 1

Anforderungen für Das Smartcard-Stammzertifikat für die Verwendung mit dem Domänenbeitritt

Es gibt einige spezifische Bedingungen, die das Smartcardzertifikat erfüllen muss, damit die Smartcard-basierte Domänenverknüpfung funktioniert.

• Smartcardzertifikat muss ein Betrefffeld enthalten, das den DNS-Domänennamen im DN enthält. Wenn dies nicht der Fall ist, schlägt die Lösung für die entsprechende Domäne fehl, und die TS- und Domänenbeitritt mit Smartcard schlägt fehl.

oder

• Smartcardzertifikat muss einen UPN enthalten, bei dem der Domänenteil des UPNs in die tatsächliche Domäne aufgelöst werden muss. Beispielsweise würde UPN "username@engineering.corp.contoso.com" funktionieren, aber "username@engineering.contoso.com" würde nicht funktionieren, da der Kerberos-Client die entsprechende Domäne nicht finden konnte.

Die Problemumgehung besteht darin, einen Hinweis (aktiviert über die GPO-Einstellung X509HintsNeeded, wie in Tabelle 7 angegeben), in der Anmeldeinformationen-Benutzeroberfläche für die Domänenbeitrittsumgebung anzugeben.

Wenn der Clientcomputer nicht mit der Domäne verbunden ist (oder wenn er einer anderen Domäne beigetreten ist), kann der Client die Serverdomäne nur auflösen, indem er den DN im Zertifikat (nicht das UPN) betrachtet. Damit dieses Szenario funktioniert, benötigt das Zertifikat einen vollständigen Betreff (einschließlich "DC=...") für die Auflösung von Domänennamen.

Um Stammzertifikate auf der Smartcard für die aktuell verbundene Domäne bereitzustellen, können Sie den folgenden Befehl verwenden:

certutil –scroots

Terminaldienste und Smartcards

In Vista wurden smartcard-Umleitungslogik und WinSCard kombiniert, um mehrere umgeleitete Sitzungen in einem einzigen Prozess zu unterstützen.

Die Smartcardunterstützung mit Terminaldiensten ist erforderlich, um viele Szenarien zu ermöglichen. Dazu zählen unter anderem folgende Einstellungen:

• Die Möglichkeit zum RAS in einer schnellen Benutzerumschaltung (oder remote mithilfe von Terminaldiensten) Umgebung. Ein Benutzer kann keine umgeleitete Smartcard-basierte RAS-Verbindung herstellen. Dies ist, dass der Verbindungsversuch nicht erfolgreich ist, wenn der Benutzer schnell wechselt oder von einer Terminaldienste-Sitzung aus.
• EFS kann den Smartcardleser des Benutzers nicht aus dem LSA-Prozess in fast User Switching oder in einer Terminaldienste-Sitzung finden. Daher kann EFS keine Benutzerdateien entschlüsseln.

Umleitung des Terminalservers

In einem Terminalserverszenario verwendet ein Benutzer einen Remoteserver für die Ausführung von Diensten. Die Smartcard ist jedoch lokal für das System, das der Benutzer verwendet. In einem Smartcard-Anmeldeszenario wird der Smartcarddienst des Remoteservers (SCardSvr.exe oder SVCHost.exe) entsprechend an den Smartcardleser gesprochen (oder umgeleitet), der mit dem Remotesystem verbunden ist, von dem der Benutzer versucht, sich anzumelden.

Abbildung 22 Terminalserverumleitung

Hinweise zum Umleitungsmodell:

1. Das beschriebene Szenario ist eine Remoteanmeldungssitzung auf einem Terminalservercomputer. In der Remotesitzung (als "Clientsitzung" bezeichnet), führt der Benutzer die Netznutzung /Smartcard aus.
2. Die Pfeile stellen den Fluss der PIN dar, die der Benutzer aus dem Eingabeaufforderungsprozess, cmd.exe, an die Smartcard des Benutzers in einem Leser eingibt, der an den Terminaldienste-Clientcomputer angeschlossen ist.
3. Die Authentifizierung wird von der LSA in Sitzung 0 ausgeführt.
4. Die Krypto-API-Arbeit wird in der LSA (lsass.exe) durchgeführt. Dies ist möglich, da rdpdr.sys pro Sitzung statt pro Prozess, Kontext zulassen.
5. Die WinScard - und SCRedir-Komponenten , die eng gekoppelt wurden, aber separate Module vor Vista, werden nun in ein Modul gerollt. Die ScHelper-Bibliothek ist ein Krypto-API-Wrapper, der für Kerberos spezifisch ist.
6. Die Umleitungsentscheidung wird pro Smartcardkontext basierend auf der Sitzung des Threads getroffen, die den SCardEstablishContext-Aufruf ausführt.
7. Änderungen an WinSCard.dll Implementierung wurden in Vista vorgenommen, um die Umleitung von Smartcards zu ermöglichen.

Einmaliges Anmelden des Terminalservers

Als Teil der Compliance von Common Criteria (CC) muss der MSTSC-Client konfigurierbar sein, um Anmeldeinformationen-Manager zum Abrufen und Speichern des Kennworts oder der Smartcard-PIN des Benutzers zu verwenden. CC erfordert, dass Anwendungen keinen direkten Zugriff auf das Kennwort oder die PIN des Benutzers haben.

CC erfordert insbesondere, dass das Kennwort/die PIN die LSA niemals klar lässt. Auf ein verteiltes Szenario angewendet, sollte es zulassen, dass das Kennwort/die PIN zwischen einem vertrauenswürdigen LSA und einem anderen reisen kann, solange es während der Übertragung nicht klar ist.

In der Windows Vista Terminal Services SSO-Lösung müssen sich Benutzer bei verwendung einer Smartcard für jede neue Terminaldienstesitzung anmelden (keine SSO-Unterstützung). Der Benutzer wird jedoch nicht mehr als einmal zur Eingabe einer PIN aufgefordert, um eine Terminaldienstesitzung einzurichten. Nachdem der Benutzer beispielsweise auf ein Microsoft Word Dokumentsymbol doppelklicken, das sich auf einem Remotecomputer befindet, wird der Benutzer aufgefordert, eine PIN einzugeben. Diese PIN wird mithilfe eines sicheren Kanals übergeben, den der SSP für Anmeldeinformationen eingerichtet hat. Die PIN wird über den sicheren Kanal zurück an den Terminaldienste-Client weitergeleitet und an Winlogon übergeben, und der Benutzer sieht keine zusätzliche Benutzeroberfläche (keine zusätzlichen Eingabeaufforderungen für die PIN, es sei denn, die PIN ist falsch, oder es gibt Fehler im Zusammenhang mit Smartcards).

Terminaldienste und Smartcardanmeldung

Der Zweck dieses Features besteht darin, Benutzern das Anmelden mit einer Smartcard zu ermöglichen, indem Sie eine PIN auf der Clientseite der Terminaldienste eingeben und ihn auf eine Weise an den Server übergeben, die der Authentifizierung basierend auf Benutzername und Kennwort ähnelt.

Die Smartcardanmeldung mit Terminaldiensten wurde erstmals in Windows XP eingeführt. Sie ist in früheren Versionen nicht verfügbar. In Windows XP konnte sich der Benutzer nur mit einem Zertifikat aus dem Standardcontainer anmelden.

Hinweis

Wenn ein Windows Vista-Terminaldiensteclient verwendet wird und ein Windows 2003 Server verwendet wird, wird nur ein einzelnes Zertifikat auf einer Smartcard im Standardcontainer unterstützt. Verwenden Sie nur Windows Vista- und Windows Server 2008-Computer, um Windows Vista-Unterstützung für mehrere Zertifikate und Domänenhinweise bereitzustellen.

Zusätzlich zur Aktivierung der erforderlichen Gruppenrichtlinien müssen Richtlinien, die für Terminaldienste spezifisch sind, für die Smartcard-basierte Anmeldung aktiviert werden.

Um die Smartcardanmeldung auf einem Terminaldiensteserver zu aktivieren, muss das KDC-Zertifikat auf dem lokalen Clientcomputer der Terminaldienste vorhanden sein. Wenn sich der Computer nicht in derselben Domäne oder Arbeitsgruppe befindet, kann das folgende Befehlszeilentool zum Bereitstellen des Zertifikats verwendet werden.

Format:

certutil –dspublish NTAuthCA "DSCDPContainer"

Der DSCDPContainer CN ist in der Regel der Computername der Zertifizierungsstelle.

Beispiel:

certutil –dspublish NTAuthCA<CertFile>"CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=engineering,DC=contoso,DC=com"

Terminaldienste und Smartcardanmeldung über Domänen hinweg

Szenario: RAS in Unternehmen

Um dieses Szenario zu aktivieren, muss das Stammzertifikat für die Domäne auf der Smartcard bereitgestellt werden. Um dies auf der Smartcard von einem in eine Domäne eingebundenen Computer bereitzustellen, führen Sie die folgenden Schritte in der Befehlszeile aus:

certutil –scroots update

Für Terminaldienste über Domänen hinweg muss auch das KDC-Zertifikat des Terminaldiensteservercomputers im NTAUTH-Speicher des Clientcomputers vorhanden sein. Führen Sie zum Hinzufügen des Speichers die folgenden Schritte in der Befehlszeile aus:

certutil –addstore –enterprise NTAUTH<CertFile>

Dabei <ist CertFile> das Stammzertifikat des KDC-Zertifikatausstellers.

Hinweis

Wenn Sie den SSP für Anmeldeinformationen auf Windows Vista verwenden, um sich mit einer Smartcard von einem nicht domänenbezogenen Computer anzumelden, muss die Smartcard die Stammzertifizierung des Domänencontrollers enthalten. Ein sicherer PKI-Kanal kann nicht ohne die Stammzertifizierung des Domänencontrollers eingerichtet werden.

Die domänenübergreifende Terminaldienste-Anmeldung funktioniert nur, wenn der UPN im Zertifikat das folgende Formular verwendet: <Something>@<DomainDNSName>

UPN im Zertifikat muss eine echte Domäne enthalten, die aufgelöst werden kann. Andernfalls hat Kerberos keine Vorstellung davon, wo sie gehen. Die Aktivierung von GPO X509-Domänenhinweisen ist eine Möglichkeit dazu. Weitere Informationen zu dieser Einstellung finden Sie in Tabelle 7.

Einstellungen für Terminaldienste und Smartcard-Anmeldung Gruppenrichtlinie

Windows erzwingt die Einstellungen für die Smartcard-Anmeldung mit Terminaldiensten, nachdem er die SSP- und lokale Sicherheitsrichtlinie (mit secpol.msc festgelegt) erzwingt.

Tabelle 13 Terminaldienste und Smartcard-Anmeldeeinstellungen Gruppenrichtlinie

Richtlinie	Einstellung
Smartcard-Anmeldung ist die einzige unterstützte Anmeldemethode	HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation Wertname: AllowFreshCredentials Werttyp: Binärdatei Werteinstellung: 1
Der Benutzer verfügt auch über ein entsprechendes Kennwort-aktiviertes Konto	HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation Wertname: AllowFreshCredentialsWhenNTLMOnly Werttyp: Binärdatei Werteinstellung: 1

Wenn Sie Terminaldienste mit Smartcard-Anmeldung verwenden, können Sie standard- und gespeicherte Anmeldeinformationen nicht delegieren. Die folgenden Gruppenrichtlinie Einstellungen werden unter HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation ignoriert:

• AllowDefCredentials
• AllowDefCredentialsWhenNTLMOnly
• AllowSavedCredentials
• AllowSavedCredentialsWhenNTLMOnly

Schnelle Benutzerumschaltung

Dies gilt nur für die aktive Sitzung.

Debuggen und Entwicklerinformationen

Entwickler können Tools und Dienste in Windows Vista verwenden, um Zertifikatprobleme zu identifizieren.

Certutil

Auf der Smartcard verfügbare Zertifikate auflisten

Befehl zum Auflisten von Zertifikaten, die auf der Smartcard verfügbar sind: certutil –scinfo

Die Eingabe einer PIN ist für diesen Vorgang nicht erforderlich. Das Drücken von Escape bei jedem PIN-Dialogfeld funktioniert, da das Ziel ist, die öffentlichen Zertifikate auf der Karte zu lesen.

Löschen von Zertifikaten auf der Smartcard

Wenn Sie ein Zertifikat auf der Karte löschen, löschen Sie tatsächlich einen Container, der diesem Zertifikat entspricht. Jedes Zertifikat wird in einen Container eingeschlossen. Um beispielsweise einen Container zu löschen, können Sie den folgenden Befehl verwenden:

Certutil –delkey –csp "Microsoft Base SmartCard Crypto Provider" "38f813f2-ec3b-4e96-ba19-38b830923be9"

Informationen zum Bereitstellen eines Domänenstammzertifikats auf einer Smartcard finden Sie unter SmartCard-Stammzertifikatanforderungen für Benutzer mit einem Domänenbeitritt.

Informationen zum Veröffentlichen von Zertifikaten im NTAUTH-Speicher finden Sie unter Terminaldienste und SmartCard-Anmeldung.

Kerberos-Debuggen und Ablaufverfolgung

Sie können die folgenden Ressourcen verwenden, um mit der Problembehandlung mit Kerberos zu beginnen:

• Problembehandlung bei Kerberos-Fehlern (https://go.microsoft.com/fwlink/?LinkId=93730).
• Problembehandlung bei der Kerberos-Delegation (https://go.microsoft.com/fwlink/?LinkId=93731).
• Das Tool zum Ablaufverfolgungsprotokoll im Windows 2000 Resource Kit (https://go.microsoft.com/fwlink/?LinkId=93732) ist ein Hilfsprogramm, das Sie zum Debuggen von Kerberos-Authentifizierungsfehlern verwenden können.

Um mit der Ablaufverfolgung zu beginnen, können Sie tracelog.exe verwenden. Verschiedene Komponenten verwenden unterschiedliche Steuerelement-GUIDs.

NTLM

Führen Sie zum Aktivieren der Ablaufverfolgung für die NTLM-Authentifizierung die folgenden Schritte in der Befehlszeile aus:

tracelog.exe -kd -rt -start ntlm -guid #5BBB6C18-AA45-49b1-A15F-085F7ED0AA90 -f .\ntlm.etl -flags 0x15003 -ft 1

Führen Sie folgendes in der Befehlszeile aus, um die Ablaufverfolgung für die NTLM-Authentifizierung zu beenden:

tracelog -stop ntlm

Kerberos

Führen Sie zum Aktivieren der Ablaufverfolgung für die Kerberos-Authentifizierung die folgenden Schritte in der Befehlszeile aus:

tracelog.exe -kd -rt -start kerb -guid #6B510852-3583-4e2d-AFFE-A67F9F223438 -f .\kerb.etl -flags 0x43 -ft 1

Führen Sie folgendes in der Befehlszeile aus, um die Ablaufverfolgung für die Kerberos-Authentifizierung zu beenden:

tracelog.exe -Stop Kerb

KDC

Führen Sie zum Aktivieren der Ablaufverfolgung für die KDC die folgenden Schritte in der Befehlszeile aus:

tracelog.exe -kd -rt -start kdc -guid #1BBA8B19-7F31-43c0-9643-6E91F79A06B -f .\kdc.etl -flags 0x803 -ft 1

Um die Ablaufverfolgung für die KDC zu beenden, führen Sie folgendes in der Befehlszeile aus:

tracelog.exe -stop kdc

Hinweis

Um die Ablaufverfolgung remote zu beenden, führen Sie folgendes in der Befehlszeile aus: logman.exe -s<ComputerName>

Der Standardspeicherort für logman.exe ist %systemroot%system32\. Verwenden Sie die Option -s , um einen Computernamen anzugeben.

Konfigurieren der Ablaufverfolgung mit der Registrierung

Sie können die Ablaufverfolgung auch konfigurieren, indem Sie Registrierungswerte bearbeiten.

Tabelle 14 Kerberos-Ablaufverfolgungsregistrierungseinstellungen

Methode	Registrierungsschlüsseleinstellung
NTLM	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 Wertname: NtLmInfoLevel Werttyp: DWORD Wertdaten: c0015003
Kerberos	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Wertname: KerbDebugLevel Werttyp: DWORD Wertdaten: c0000043 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos Wertname: LogToFile Werttyp: DWORD Wertdaten: 00000001 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters Wertname: LogToFile Werttyp: DWORD Wertdaten: 00000001
KDC	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc Wertname: KdcDebugLevel Werttyp: DWORD Wertdaten: c0000803

Wenn Sie tracelog.exe verwendet haben, suchen Sie in Ihrem aktuellen Verzeichnis nach der Protokolldatei kerb.etl/kdc.etl/ntlm.etl. Andernfalls suchen Sie nach den generierten Ablaufverfolgungsprotokolldateien an den folgenden Speicherorten, wenn Sie die in Tabelle 13 angezeigten Registrierungsdateien verwendet haben:

• NTLM: %systemroot%\tracing\msv1_0
• Kerberos: %systemroot%\tracing\kerberos
• KDC: %systemroot%\tracing\kdcsvc

Um Ereignisablaufverfolgungsdateien zu entschlüsseln, können Sie Tracefmt (tracefmt.exe) verwenden. Tracefmt ist ein Befehlszeilentool, das Ablaufverfolgungsnachrichten aus einer Ereignisablaufverfolgungsprotokolldatei (.etl) oder einer Echtzeitablaufverfolgungssitzung formatiert und anzeigt. Tracefmt kann die Nachrichten im Eingabeaufforderungsfenster anzeigen oder in einer Textdatei speichern. Es befindet sich im Unterverzeichnis \tools\tracing des Microsoft Windows Driver Kit (WDK). Weitere Informationen zu Tracefmt finden Sie unter Tracefmt bei MSDN (https://go.microsoft.com/fwlink/?LinkId=93734).

Smartcarddienst

So überprüfen Sie, ob der Smartcarddienst ausgeführt wird

1. Drücken Sie STRG+ALT+DEL, und klicken Sie dann auf "Task-Manager starten".

2. Klicken Sie im Dialogfeld Windows Task-Manager auf die Registerkarte "Dienste".

3. Klicken Sie auf die Spalte "Name" , um die Liste alphabetisch zu sortieren, und geben Sie dann s ein.

4. Suchen Sie in der Spalte "Name " nach SCardSvr, und suchen Sie dann unter der Spalte "Status ", um zu sehen, ob der Dienst ausgeführt oder beendet wird.

So starten Sie den Smartcarddienst neu

1. Klicken Sie auf die Schaltfläche "Start", geben Sie cmd ein, klicken Sie mit der rechten Maustaste auf cmd.exe, und klicken Sie dann auf "Als Administrator ausführen".

2. Wenn das Dialogfeld Benutzerkontensteuerung eingeblendet wird, bestätigen Sie die angegebene Aktion und klicken dann auf Weiter.

3. Geben Sie an der Eingabeaufforderung den Net Stop SCardSvr ein.

4. Geben Sie an der Eingabeaufforderung net start SCardSvr ein.

Sie können den folgenden Befehl in der Eingabeaufforderung verwenden, um zu überprüfen, ob der Dienst ausgeführt wird:

sc queryex scardsvr

Im folgenden Beispiel wird der Befehl ausgeführt:

SERVICE_NAME: scardsvr
    TYPE        : 20 WIN32_SHARE_PROCESS
    STATE       : 4 RUNNING
                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
    WIN32_EXIT_CODE  : 0 (0x0)
    SERVICE_EXIT_CODE : 0 (0x0)
    CHECKPOINT     : 0x0
    WAIT_HINT     : 0x0
    PID        : 1320
    FLAGS       :
C:\>

Smartcardleser

So überprüfen Sie, ob der Smartcardleser angeschlossen und ordnungsgemäß funktioniert

1. Klicken Sie auf die Schaltfläche "Start", klicken Sie mit der rechten Maustaste auf "Computer", und klicken Sie dann auf "Eigenschaften".

2. Klicken Sie unter "Aufgaben" auf Geräte-Manager.

3. Erweitern Sie in Geräte-Manager Smartcardleser, wählen Sie den Smartcardleser aus, über den Sie Informationen wünschen, und klicken Sie dann auf "Eigenschaften".

   Hinweis

   Wenn der Smartcardleser in Geräte-Manager nicht aufgeführt ist, klicken Sie im Menü "Aktion" auf "Nach Hardwareänderungen suchen".

CAPI2-Diagnose

CAPI2 Diagnostics ist ein Feature in Windows Vista und Windows Server 2008, das Administratoren bei der Problembehandlung bei PKI-Problemen unterstützt. CAPI2 Diagnostics protokolliert Ereignisse im Windows Ereignisprotokoll, das detaillierte Informationen zur Überprüfung der Zertifikatkette, Zertifikatspeichervorgänge und Signaturüberprüfung enthält. Diese Informationen erleichtern die Identifizierung der Ursachen von Problemen und reduziert die Zeit, die für die Diagnose erforderlich ist.

Weitere Informationen zur CAPI2-Diagnose finden Sie unter Problembehandlung bei PKI-Problemen auf Windows Vista (https://go.microsoft.com/fwlink/?LinkId=89570).

References

1. Alias des Anmeldeinformationenanbieters – credprov@microsoft.com
2. Technische Referenz für Anmeldeinformationen (https://go.microsoft.com/fwlink/?LinkId=93340)
3. Windows Vista SDK-Dokumentation (https://go.microsoft.com/fwlink/?LinkId=93342)
4. Microsoft Base SmartCard Kryptografiedienstanbieter (Base CSP) für Windows 2000, 2003 und XP (https://go.microsoft.com/fwlink/?LinkId=93341)
5. SmartCard Minitreiberspezifikation (https://go.microsoft.com/fwlink/?LinkId=93343)
6. Smart Card Mini Driver (Card Module) API und Header-Dateidokumentation auf MSDN (https://go.microsoft.com/fwlink/?LinkId=18885); Feedback-Alias: CardMod@microsoft.com ; Headerdateidownload verfügbar als Teil des CNG SDK (https://go.microsoft.com/fwlink/?LinkId=93344)
7. SmartCard-Zertifizierungsanforderungen (https://go.microsoft.com/fwlink/?LinkId=93345)
8. PC/SC-Arbeitsgruppe (https://go.microsoft.com/fwlink/?LinkId=93346)
9. WinSCard-API-Referenz (https://go.microsoft.com/fwlink/?LinkId=93347)
10. OSCP-Unterstützung für PKINIT (https://go.microsoft.com/fwlink/?LinkId=93348)
11. Enterprise SmartCard-Bereitstellung im Microsoft Windows SmartCard Framework (https://go.microsoft.com/fwlink/?LinkId=93349)
12. Sitzung 0 in Windows Vista (https://go.microsoft.com/fwlink/?LinkId=93350)
13. Globale Plattformspezifikationen (https://go.microsoft.com/fwlink/?LinkId=93351)
14. Problembehandlung bei PKI-Problemen auf Windows Vista (https://go.microsoft.com/fwlink/?LinkId=89570)
15. RFC 4556: Public Key Kryptografie für die initiale Authentifizierung in Kerberos (PKINIT) (https://go.microsoft.com/fwlink/?LinkId=93352)
16. Verbesserungen des Active Directory-Zertifikatservers in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=83212)
17. Smart Card Infrastructure Blog, für neueste Informationen und Feedback (https://go.microsoft.com/fwlink/?LinkId=96591)