Windows Vista Smartcard-Infrastruktur

Die Windows Vista® SmartCard-Infrastruktur enthält Details zur Microsoft® Windows® Smart Karte-Infrastruktur und zur Funktionsweise intelligenter Karte-bezogene Komponenten in Windows. Dieses Dokument enthält auch Informationen zu Tools zur Problembehandlung und zum Debuggen sowie zu Tools, mit denen IT-Entwickler und Administratoren intelligente Karte starke Authentifizierung im Unternehmen bereitstellen können.

Zielgruppe

Dieses Dokument enthält ausführliche Informationen zur Funktionsweise der Windows Smart Karte-Infrastruktur. Sie benötigen grundlegende Kenntnisse der Public Key-Infrastruktur (PKI) und der Konzepte für intelligente Karte, um die Empfehlungen in diesem Dokument in vollem Umfang nutzen zu können. Dieses Dokument richtet sich an:

• Entwickler und IT-Experten für Unternehmen, die eine Intelligente Karte-Bereitstellung planen oder implementieren. Dazu gehören IT-Direktoren und IT-Mitarbeiter.
• Intelligente Karte Anbieter, die intelligente Karte Minitreiber oder Anmeldeinformationsanbieter schreiben. In diesem Dokument wird das Innere der Windows Smart Karte-Architektur beschrieben und informationen dazu bereitgestellt, wie IT-Abteilungen intelligente Karte-Bereitstellungen planen.

Windows-Smartcardinfrastruktur

Die Unterstützung für intelligente Karte war zunächst in Windows 2000 enthalten. Windows Server 2003 und Windows XP unterstützen auch Smartcards.

Hinweis

Der Smart Karte-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 E-Mails anmelden und verschlüsseln. Es gibt jedoch einige Einschränkungen bei der Implementierung.

Vor Windows Vista:

• Eine intelligente Karte kann nur ein Zertifikat für die Anmeldung unterstützen.
• Nur ein Container auf der intelligenten Karte kann als Standard markiert werden. Zusätzliche Zertifikate können auf dem intelligenten Karte für andere Zwecke, z. B. S/MIME, gespeichert werden.
• Das Ändern der PIN und das Aufheben der Blockierung eines intelligenten Karte wurden nicht nativ unterstützt oder integriert. Daher musste sich ein Benutzer zuerst mit einem Standardbenutzernamen und Kennwort anmelden, um diese Aufgaben auszuführen.

Windows Vista-Verbesserungen

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

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

MSGINA.DLL wurde entfernt, und benutzerdefinierte GINAs werden nicht auf Systemen mit Windows Vista und höheren Versionen geladen. Sowohl der Kennwortanmeldeinformationsanbieter als auch der Anbieter für intelligente Karte Anmeldeinformationen werden standardmäßig bereitgestellt, und die Möglichkeit, benutzerdefinierte Authentifizierungsmechanismen zu unterstützen, erfordert die Erstellung eines benutzerdefinierten Anmeldeinformationsanbieters. 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 Anmeldeoberfläche die Anmeldeinformationen an Winlogon, die für die Kerberos-Authentifizierung verwendet werden sollen.

In Vista unterstützt Winlogon mehrere Anmeldezertifikate und Container auf demselben intelligenten Karte. 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 CAPI-Schnittstellen (Cryptography Application Programming Interface) oben und die WinSCard-APIs unten. (Ausführliche Informationen finden Sie unter Smart Karte-Subsystemarchitektur.)

In der Vergangenheit war das Schreiben eines intelligenten Karte CSP keine triviale Aufgabe. Ein neuer CSP namens Base CSP erleichtert jetzt jedoch das Schreiben eines intelligenten Karte CSP. Der Basis-CSP ermöglicht es Anbietern von intelligenten Karte, Karte spezifische Module zu schreiben, die als Smart Karte Minitreiber bezeichnet werden. Microsoft stellt den Basis-CSP als Teil der Plattform bereit. Ein herunterladbares Paket davon ist für Windows XP SP2, Windows 2000 SP4 und Windows Server 2003 SP1 vorhanden. Ein intelligenter Karte Minitreiber ist eine Schnittstelle, die Microsoft für Anbieter von intelligenten Karte unterstützt, um Implementierungen in ihre intelligenten Karte zu schreiben. Dies entspricht dem Schreiben eines Druckertreibers für einen Drucker.

Die WinSCard-API wurde erweitert, um die Zwischenspeicherung (Speicherung nicht vertraulicher Daten auf Benutzerbasis) auf der Ebene der intelligenten Karte Resource Manager bereitzustellen. Der Smartcard-Ressourcen-Manager wurde früher als Smartcarddienst bezeichnet.

Um zusätzliche kryptografische Algorithmen zu unterstützen und erweiterbare Architektur bereitzustellen, wurde cryptography API: Next Generation (CNG) entwickelt. Architektonisch ist dies parallel zu CAPI. Wie bei CSP befindet sich ein Schlüsselspeicheranbieter (Key Storage Provider, KSP) unterhalb des CNG. Unter Windows Vista wird die implementierung intelligenter Karte KSP standardmäßig bereitgestellt. Die gleiche intelligente Karte Minitreiberschnittstelle, die für Base CSP verfügbar ist, gilt auch für smarte Karte KSP. Smart Karte Minitreiberunterstützung für RSA und Elliptic Curve Cryptography (ECC) ist mit smart Karte KSP verfügbar.

Aufbau

Die Intelligente Karte Registrierungsdatenbank befindet sich unter HKLM\Software\Microsoft\Cryptography\Calais\SmartCard. Diese Datenbank enthält Informationen zu intelligenten Karte und intelligenten Karte-Lesern. Die Infrastruktur für intelligente Karte in Windows umfasst zwei primäre Komponenten:

• Interaktive Windows-Anmeldearchitektur
• Smart Karte-Subsystemarchitektur

Interaktive Windows-Anmeldearchitektur

Vor Windows Vista umfasste die interaktive Windows-Anmeldearchitektur die in Tabelle 1 gezeigten Komponenten.

Tabelle 1 Interaktive Anmeldekomponenten vor Windows Vista

Komponente	BESCHREIBUNG
Windows-Anmeldung	Stellt eine interaktive Anmeldeinfrastruktur bereit.
GINA-Komponente (Graphical Identification and Authentication)	Stellt interaktives Benutzeroberflächenrendering 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 Funktionsweise der interaktiven Anmeldung (https://go.microsoft.com/fwlink/?LinkId=93339).

Architektur des Windows Vista-Anmeldeinformationsanbieters

Tabelle 2 zeigt die Komponenten in der interaktiven Anmeldearchitektur von Windows Vista.

Tabelle 2 Interaktive Windows Vista-Anmeldekomponenten

Komponente	BESCHREIBUNG
Windows-Anmeldung	Stellt eine interaktive Anmeldeinfrastruktur bereit.
Benutzeroberfläche für die Anmeldung	Stellt interaktives Benutzeroberflächenrendering bereit.
Anmeldeinformationsanbieter (Kennwort und intelligente Karte)	Beschreibt Anmeldeinformationen und Serialisierung von Anmeldeinformationen.
LSA	Verarbeitet Anmeldeinformationen.
Authentifizierungspakete	Enthält NTLM und Kerberos. Kommuniziert mit Serverauthentifizierungspaketen, um Benutzer zu authentifizieren.

Abbildung 1 Architektur des Windows-Anmeldeinformationsanbieters

Die interaktiven Windows Vista-Anmeldungen beginnen, wenn der Benutzer STRG+ALT+ENTF drückt. Die Tastenkombination STRG+ALT+ENTF wird als sichere Aufmerksamkeitssequenz (SAS) bezeichnet. Winlogon registriert diese Sequenz während des Startvorgangs, damit andere Programme und Prozesse sie nicht verwenden können. Die Anmeldeoberfläche generiert dann die Kachel aus Informationen, die von den registrierten Anmeldeinformationsanbietern empfangen wurden. Die folgende Abbildung zeigt das Windows Vista-Anmeldedialogfeld.

Abbildung 2 Benutzeroberfläche für die Windows Vista-Anmeldung

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. Bei smarten Karte Anmeldungen sind die Anmeldeinformationen eines Benutzers jedoch auf dem Sicherheitschip des intelligenten Karte enthalten. Ein externes Gerät namens Smart Karte Reader liest den Sicherheitschip. Während einer smarten Karte Anmeldung gibt ein Benutzer anstelle eines Benutzernamens, einer Domäne und eines Kennworts eine persönliche Identifikationsnummer (PIN) ein.

Anmeldeinformationsanbieter sind prozessinterne COM-Objekte, die zum Sammeln von Anmeldeinformationen in Windows Vista und zur Ausführung im lokalen Systemkontext verwendet werden. Zusammenfassend lässt sich sagen, dass die Anmeldeoberfläche interaktives Ui-Rendering bietet, Winlogon eine interaktive Anmeldeinfrastruktur bietet, und Anmeldeinformationsanbieter helfen beim Sammeln und Verarbeiten von Anmeldeinformationen.

In Windows Vista weist Winlogon die Anmeldeoberfläche an, Kacheln anzuzeigen, nachdem sie ein SAS-Ereignis empfangen hat. Die Anmeldeschnittstelle fragt jeden Anmeldeinformationsanbieter nach der Anzahl der Anmeldeinformationen ab, die er aufzählen möchte. Anmeldeinformationsanbieter haben die Möglichkeit, eine dieser Kacheln als Standard anzugeben. Nachdem alle Anbieter ihre Kacheln aufgelistet haben, werden sie auf der Anmeldeoberfläche dem Benutzer angezeigt. Der Benutzer interagiert mit einer Kachel, um seine Anmeldeinformationen anzugeben. Die Anmeldeoberfläche übermittelt diese Anmeldeinformationen für die Authentifizierung.

In Kombination mit unterstützender Hardware können Anmeldeinformationsanbieter das Microsoft Windows-Betriebssystem erweitern, damit sich Benutzer über biometrische (Fingerabdruck, Netzhaut- oder Spracherkennung), Kennwort, PIN, Smart Karte-Zertifikat oder ein beliebiges benutzerdefiniertes Authentifizierungspaket anmelden können, das ein Drittanbieterentwickler erstellen möchte. Unternehmen und IT-Experten können benutzerdefinierte Authentifizierungsmechanismen für alle Domänenbenutzer entwickeln und bereitstellen und möglicherweise explizit von Benutzern verlangen, diesen benutzerdefinierten Anmeldemechanismus zu verwenden.

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

Anmeldeinformationsanbieter können so konzipiert sein, dass sie einmaliges Anmelden (Single Sign-On, SSO), die Authentifizierung von Benutzern bei einem sicheren Netzwerkzugriffspunkt (mithilfe von RADIUS und anderen Technologien) sowie die Computeranmeldung unterstützen. Anmeldeinformationsanbieter unterstützen auch die anwendungsspezifische Erfassung von Anmeldeinformationen und können für die Authentifizierung bei Netzwerkressourcen, den Beitritt von Computern zu einer Domäne oder die Administratorzustimmung für die Benutzerkontensteuerung (User Account Control, UAC) verwendet werden.

Auf einem Computer können mehrere Anmeldeinformationsanbieter gleichzeitig vorhanden sein.

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

• Beschreibung der Anmeldeinformationen, die für die Authentifizierung erforderlich sind.
• Verarbeiten von Kommunikation und Logik mit externen Authentifizierungsstellen.
• Packen von Anmeldeinformationen für die interaktive Und Netzwerkanmeldung.

Die API des Anmeldeinformationsanbieters gestaltet keine Benutzeroberfläche. Es beschreibt, was gerendert werden muss. Nur der Anbieter von Kennwortanmeldeinformationen ist im abgesicherten Modus verfügbar. Der In-Box-Anbieter für intelligente Karte Anmeldeinformationen ist im abgesicherten Modus mit Netzwerk verfügbar.

Weitere Informationen zu Anmeldeinformationsanbietern und deren Verwendung finden Sie in der technischen Referenz zum Anmeldeinformationsanbieter (https://go.microsoft.com/fwlink/?LinkId=93340).

Abbildung 3 veranschaulicht den Ablauf des Windows Vista-Anmeldebildschirms mit PIN-Entsperrung und PIN-Änderung.

Abbildung 3: Entsperren und ÄNDERN der PIN-Benutzeroberfläche

Smart Karte Subsystemarchitektur

Anbieter und Partner sind sehr wichtig für den Erfolg intelligenter Karte-basierten Szenarien. Anbieter bieten Smartcards und smarte Karte Reader, und in vielen Fällen unterscheiden sich die Intelligenten Karte- und Leseranbieter. Lesertreiber werden in die PC/SC-Standardversion 1.0 geschrieben. Jede intelligente Karte muss über einen CSP verfügen, der die CAPI-Schnittstellen oben und die WinSCard-APIs unten verwendet. Das GINA-Modul verfügt auch über die Funktion smart Karte Anmeldung, um die relevante Benutzeroberfläche für die Erfassung der Anmeldeinformationen und das anschließende Marshalling bereitzustellen, das zur Authentifizierung an den LSALogonUser gesendet werden soll.

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

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

Abbildung 4 veranschaulicht, wie CAPI, CSPs, der Basis-CSP und smarte Karte Minitreiber architektonisch mehrschichtig sind.

Abbildung 4 Basis-CSP und Smart Karte Minitreiberarchitektur

Heuristiken für smarte Karte Auswahl

Containerspezifikationsebenen

Als Reaktion auf einen CryptAcquireContext-Aufruf versucht der Basis-CSP, den Container, den der Aufrufer angibt, einem bestimmten Karte und Leser zuzuordnen. Der Aufrufer kann einen Containernamen mit unterschiedlichen Spezifitätsgraden bereitstellen, der in der folgenden Liste dargestellt ist und von spezifischeren bis weniger spezifischen Anforderungen sortiert ist.

Ähnlich wie für die intelligente Karte KSP verwendet NCryptOpenKey das gleiche Format wie in Tabelle 3 dargestellt. Vor dem Öffnen des Schlüssels wird ein Aufruf NCryptOpenStorageProvider(MS_SMART_CARD_KEY_STORAGE_PROVIDER) ausgeführt.

Tabelle 3 Containerspezifikationsebenen

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

In den ersten beiden Fällen, in denen ein Lesername angegeben wird, sucht der Basis-CSP in der Regel nach dem angegebenen Reader und führt den angeforderten Vorgang für den in diesen Reader eingefügten Karte aus. In den zweiten beiden Fällen, in denen kein Smart Karte-Lesername angegeben wird, sucht der Basis-CSP nach einem Karte und Leser, der für die aktuelle Anforderung geeignet ist, beginnend mit Karten, die dem Basis-CSP bereits bekannt sind, bis hin zu allen Smartcards und Lesegeräten, die mit dem Smart Karte Subsystem verfügbar sind.

Für jeden der oben genannten Fälle sucht der Basis-CSP zunächst nach einem übereinstimmenden Karte in der Liste der zwischengespeicherten Karte Daten. Dieser Cache enthält eine Liste von Smartcards und zugeordneten Smart Karte Zustandsinformationen, die der CSP in der aktuellen Sitzung gefunden hat (wobei die Sitzung in der Regel die Lebensdauer des aktuellen Prozesses ist). Wenn ein übereinstimmender intelligenter Karte im Cache gefunden wird, sollte das Karte Handle aktualisiert werden, das dem Cacheelement zugeordnet ist. Dadurch wird bestimmt, ob sich der Karte noch im Reader befindet, da die intelligenten Karte möglicherweise seit der Erstellung des Cacheelements entfernt wurden.

Wenn ein übereinstimmender intelligenter Karte zwischengespeichert gefunden wird, das zwischengespeicherte Smart Karte-Handle jedoch nicht mehr gültig ist, wird die SCardUIDlg-API verwendet, um das Karte-Handle zu aktualisieren. Zusätzliche Informationen, z. B. die Seriennummer der übereinstimmenden smarten Karte, werden SCardUIDlg zur Verfügung gestellt, um Kandidaten-Smartcards schnell zu filtern.

Containervorgänge

Drei Standard Containervorgänge können mithilfe von CryptAcquireContext angefordert werden. Diese lauten wie folgt:

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

Die Heuristiken, die zum Zuordnen eines Benutzerkontexts zu einem bestimmten Karte und Reader verwendet werden, basieren hauptsächlich auf dem angeforderten Containervorgang und der verwendeten Containerspezifikationsebene.

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

Tabellen 4 Einschränkungen des Vorgangs zum Erstellen von Containern

Spezifikation	Einschränkung
Kein hintergrundbezogener Kontext	Bei der Schlüsselcontainererstellung muss immer die Benutzeroberfläche angezeigt werden können, z. B. die PIN-Eingabeaufforderung.
Kein Überschreiben vorhandener Container	Wenn der angegebene Container bereits auf dem ausgewählten intelligenten Karte vorhanden ist, wählen Sie entweder einen anderen Karte aus, oder brechen Sie den Vorgang ab.

Kontextflags

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

Tabelle 5 Einschränkungsflags

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	Auf der intelligenten Karte kann nur auf öffentliche Daten zugegriffen werden.

Zusätzlich zu Containervorgängen und Containerspezifikationen müssen Sie bei Karte Auswahl auch andere Benutzeroptionen berücksichtigen, z. B. die oben genannten CryptAcquireContext-Flags.

Wichtig

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

Erstellen eines neuen Containers im hintergrundlosen 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 hintergrundlosen Kontext erstellen:

1. Rufen Sie CryptAcquireContext auf, und übergeben Sie den Smart Karte Readernamen als Typ II, und geben Sie dabei das flag CRYPT_DEFAULT_CONTAINER_OPTIONAL an.
2. Rufen Sie CryptSetProvParam auf, indem Sie PP_KEYEXCHANGE_PIN oder PP_SIGNATURE_PIN und eine ASCII-PIN mit NULL-Beendigung angeben.
3. Geben Sie den in Schritt 1 abgerufenen Kontext frei.
4. Rufen Sie CryptAcquireContext mit CRYPT_NEWKEYSET auf, indem Sie das Typ-I-Format angeben.
5. Rufen Sie CryptGenKey auf, um den Schlüssel zu erstellen.

Smartcard-Auswahlverhalten

In einigen der folgenden Szenarien kann der Benutzer aufgefordert werden, eine intelligente Karte einzufügen. Wenn der Benutzerkontext im Hintergrund ausgeführt wird, tritt bei diesem Vorgang ein Fehler auf, und es wird keine Benutzeroberfläche angezeigt. Andernfalls kann der Benutzer als Reaktion auf die Benutzeroberfläche entweder eine intelligente Karte einfügen oder auf Abbrechen klicken. Wenn der Benutzer den Vorgang abbricht, schlägt der Vorgang fehl.

Abbildung 5 Intelligentes Karte Auswahlverhalten

Im Allgemeinen wird Karte Auswahlverhalten 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, Smartcards zu filtern und abzugleichen. Aufrufer von CryptAcquireContext stellen Karte übereinstimmenden Informationen bereit. Intern verwendet der Basis-CSP eine Kombination aus intelligenten Karte Seriennummern, Lesernamen und Containernamen, um bestimmte Smartcards zu finden.

Jeder Aufruf von SCardUI* kann zu zusätzlichen Informationen führen, die von einem Kandidaten für intelligente Karte gelesen werden. Die Smart Karte-Auswahlrückrufe des Basis-CSP speichern diese Informationen zwischen.

Die SCardUI*-API wird verwendet, um intelligente Karte Handles zu aktualisieren, da ein intelligentes Karte-Ziel entfernt oder erneut eingefügt werden kann, nachdem ein Karte Handle zwischengespeichert wurde. Die übereinstimmende Seriennummer wird von FindCachedCard() ermittelt, die zusammen mit einer status an FindCard() übergeben wird, die angibt, dass die Suche erfolgreich war, aber das Karte-Handle erneut abgerufen werden muss. (Oder dass die entsprechende Smart Karte Zustandsstruktur zurückgegeben werden könnte, anstatt nur die Seriennummer. Dies würde verhindern, dass der Rückruf die Liste der Karten erneut durchsuchen muss.) FindCard gibt die Seriennummer für den entsprechenden Karte-übereinstimmenden Rückruf mithilfe von SCardUI* an.

Erstellen einer Leser-Übereinstimmung

Für die Containerspezifikationsstufen I und II ist der Auswahlprozess für intelligente Karte weniger komplex, da nur die intelligenten Karte im benannten Reader als Übereinstimmung betrachtet werden können.

1. Suchen Sie den angeforderten Reader. Wenn er nicht gefunden werden kann, schlägt der Prozess fehl. (Hierfür ist eine Cachesuche nach Lesernamen erforderlich.)
2. Wenn sich keine intelligente Karte im Reader befindet, wird der Benutzer aufgefordert, eine intelligente Karte einzufügen (nur im nicht automatischen Modus; wenn der Aufruf im unbeaufsichtigten Modus erfolgt, schlägt er fehl).
3. Nur für Ebene II wird der Name des Standardcontainers für die ausgewählte intelligente Karte bestimmt.
4. Suchen Sie für container operations B (open existing) und C (delete) den angegebenen Container. Wenn der angegebene Container in diesem intelligenten Karte nicht gefunden werden kann, wird der Benutzer aufgefordert, eine intelligente Karte einzufügen.
5. Wenn der angegebene Container bei Containervorgang A (neu erstellen) bereits in diesem intelligenten Karte vorhanden ist, schlägt der Prozess fehl.

Eine intelligente Karte Übereinstimmung herstellen

Für die Containerspezifikationsstufen III und IV wird eine umfassendere Methode verwendet, um eine geeignete Karte mit einem Benutzerkontext abzugleichen, da mehrere zwischengespeicherte Smartcards die angegebenen Kriterien erfüllen können.

Öffnen eines vorhandenen Standardcontainers – kein Reader angegeben

Hinweis

In diesem Szenario müssen Sie den intelligenten Karte KSP mit dem Basis-CSP verwenden.

1. Suchen Sie für jede intelligente Karte, die bereits vom Basis-CSP bekannt ist, nach einem gültigen Standardcontainer. Es wird versucht, die Aktualität des zwischengespeicherten SCARDHANDLE-Elements zu überprüfen. Wenn das Handle für intelligente Karte ungültig ist, sucht der Basis-CSP weiterhin nach einem neuen intelligenten Karte.
2. Wenn keine übereinstimmende Karte im Basis-CSP-Cache gefunden wird, rufen Sie das Smart Karte-Subsystem auf. SCardUIDlgSelectCard() wird mit einem geeigneten Rückruffilter verwendet, um eine übereinstimmende Karte mit einem gültigen Standardcontainer zu finden.

Öffnen sie einen vorhandenen GUID-benannten Container, kein Reader angegeben.

Hinweis

In diesem Szenario müssen Sie den intelligenten Karte KSP mit dem Basis-CSP verwenden.

1. Suchen Sie für jede intelligente Karte, die der Basis-CSP bereits kennt, nach dem angeforderten Container. Versuchen Sie, die Aktualität des zwischengespeicherten SCARDHANDLE-Elements zu überprüfen. Wenn das Karte Handle ungültig ist, wird die Seriennummer des intelligenten Karte an die SCardUI*-API übergeben, um die Suche nach dieser bestimmten intelligenten Karte fortzusetzen (anstatt nur eine allgemeine Übereinstimmung mit dem Containernamen).
2. Wenn keine übereinstimmende Karte im Basis-CSP-Cache gefunden wird, wird ein Aufruf an das Smart Karte-Subsystem durchgeführt. SCardUIDlgSelectCard() wird mit einem entsprechenden Rückruffilter verwendet, um eine übereinstimmende Karte mit dem angeforderten Container zu finden. Wenn bei der Suche in Schritt 1 eine smarte Karte Seriennummer entstanden ist, versucht der Rückruffilter, die Seriennummer und nicht den Containernamen zuzuordnen.

Erstellen eines neuen Containers, kein Reader angegeben

Hinweis

In diesem Szenario müssen Sie den intelligenten Karte KSP mit dem Basis-CSP verwenden.

Wenn die PIN nicht zwischengespeichert wird, ist bei der Containererstellung kein 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 ausführen, um die Benutzer-PIN für nachfolgende Vorgänge zwischenzuspeichern.

1. Aktualisieren Sie für jede intelligente Karte, die dem CSP bereits bekannt ist, die gespeicherte SCARDHANDLE, und führen Sie die folgenden Überprüfungen durch:
   1. Wenn die intelligente Karte entfernt wurde, setzen Sie die Suche fort.
   2. Wenn der intelligente Karte noch vorhanden ist, aber bereits über den benannten Container verfügt, fahren Sie mit der Suche fort.
   3. Wenn die intelligente Karte verfügbar ist, aber ein Aufruf von CardQueryFreeSpace angibt, dass der Karte nicht über genügend Speicherplatz für einen zusätzlichen Schlüsselcontainer verfügt, fahren Sie mit der Suche fort.
   4. Verwenden Sie andernfalls die erste verfügbare intelligente Karte, die die oben genannten Kriterien für die Containererstellung erfüllt.
2. Wenn keine übereinstimmende intelligente Karte im CSP-Cache gefunden wird, rufen Sie das Smart Karte-Subsystem auf. Der Rückruf, der zum Filtern von aufgezählten Smartcards verwendet wird, sollte überprüfen, ob ein potenzieller smarter Karte nicht bereits über den benannten Container verfügt, und dass CardQueryFreeSpace angibt, dass die Karte über ausreichend Speicherplatz für einen zusätzlichen Container verfügt. Wenn keine geeignete Karte gefunden wird, wird die Benutzeroberfläche angezeigt, in der der Benutzer aufgefordert wird, eine intelligente Karte einzufügen.

Löschen eines Containers

1. Wenn der angegebene Containername NULL ist, wird der Standardcontainer gelöscht. Wenn Sie den Standardcontainer löschen, wird ein neuer Standardcontainer willkürlich ausgewählt. Aus diesem Grund wird dieser Vorgang nicht empfohlen.
2. Aktualisieren Sie für jede intelligente Karte, die dem CSP bereits bekannt ist, die gespeicherte SCARDHANDLE, und führen Sie die folgenden Überprüfungen durch.
   1. Wenn der intelligente Karte nicht über den benannten Container verfügt, fahren Sie mit der Suche fort.
   2. Wenn die intelligente Karte über den benannten Container verfügt, das Karte Handle jedoch nicht mehr gültig ist, speichern Sie die Seriennummer der übereinstimmenden smart Karte, und übergeben Sie sie an SCardUI*.
3. Wenn keine übereinstimmende Karte im CSP-Cache gefunden wird, rufen Sie das Smart Karte-Subsystem auf. Der Rückruf, der zum Filtern von aufgezählten Karten verwendet wird, sollte überprüfen, ob ein Kandidat Karte über den benannten Container verfügt. Wenn als Ergebnis der obigen Cachesuche eine Seriennummer angegeben wurde, sollte der Rückruf auf enumerierte Karten nach Seriennummer und nicht nach Containerergebnissen filtern. Wenn der Kontext nicht im Hintergrund ausgeführt wird und keine geeigneten intelligenten Karte gefunden werden, wird die Benutzeroberfläche angezeigt, die den Benutzer auffordert, eine intelligente Karte einzufügen.

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

Zwischenspeichern von Daten

Jeder CSP implementiert den aktuellen Smart Karte-Datencache separat. Der Basis-CSP implementiert beispielsweise einen robusten Zwischenspeicherungsmechanismus, der es einem einzelnen Prozess ermöglicht, Karte E/A-Vorgänge zu minimieren.

Der vorhandene Prozesscache funktioniert wie folgt.

1. Die Anwendung fordert einen CAPI-Vorgang an. Beispielsweise muss ein Benutzerzertifikat aus dem Karte gelesen werden.
2. Der CSP überprüft zunächst seinen Cache auf das Element.
3. Wenn das Element nicht im Cache gefunden wird oder das Element zwischengespeichert, aber nicht auf dem neuesten Stand ist, wird das Element dann aus dem intelligenten Karte gelesen.
4. Nachdem ein Element aus der intelligenten Karte gelesen wurde, wird es dem Cache hinzugefügt. Jede vorhandene veraltete (veraltete) Kopie dieses Elements wird ersetzt.

Das Hauptproblem in der vorhandenen Lösung besteht darin, dass jeder Smartcard-fähige Prozess im System das oben genannte Verhalten duplizieren und seine eigene Kopie der gleichen Daten behalten muss. Das aktuelle Modell reicht nicht aus. Ein Prozess muss in der Lage sein, Karte Daten zu verwenden, die zuvor von anderen Prozessen gelesen wurden.

Der globale Datencache wird im Ressourcen-Manager für intelligente Karte gehostet. Windows Vista umfasst zwei neue öffentliche Windows Smart Karte-API-Aufrufe, SCardWriteCache und SCardReadCache. Diese API-Aufrufe machen globale Datenzwischenspeicherungsfunktionen für Anwendungen verfügbar. Diese API-Aufrufe werden nur auf Windows Vista-Clientcomputern unterstützt.

1. Jede intelligente Karte, die der neuen Smart Karte Minitreiberspezifikation entspricht, verfügt über einen 16-Byte-Karte-Bezeichner. Dieser Wert wird verwendet, um zwischengespeicherte Daten zu einem bestimmten intelligenten Karte eindeutig zu identifizieren. Der Einfachheit halber wird der Standard-Windows-GUID-Typ verwendet.
2. Diese APIs ermöglichen einer Anwendung das Hinzufügen von Daten und das Lesen von Daten aus dem globalen Cache.

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

PIN-Zwischenspeicherung

Der PIN-Cache hilft dem Benutzer, bei jedem Aufheben der Authentifizierung des intelligenten Karte erneut eine PIN eingeben zu müssen. Nachdem eine intelligente Karte authentifiziert wurde, unterscheidet sie sich nicht zwischen hostseitigen Anwendungen. Jede Anwendung kann auf private Daten auf dem intelligenten Karte zugreifen. Um dies zu verringern, wird die intelligente Karte in einen exklusiven Zustand versetzt, wenn sich eine Anwendung beim intelligenten Karte authentifiziert. Dies bedeutet jedoch, dass andere Anwendungen nicht mit dem intelligenten Karte kommunizieren 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 entweder über einen längeren Zeitraum exklusiven Zugriff auf die smarten Karte erfordert oder mehrere Authentifizierungsvorgänge erfordert. Hier kommt der PIN-Cache ins Spiel und ermöglicht eine minimale exklusive Nutzung des intelligenten Karte, ohne dass der Benutzer seine PIN mehrmals eingeben muss.

Hier sehen Sie 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 unterschiedliche Zwecke.

1. Der Benutzer startet Outlook und versucht, eine signierte E-Mail zu senden. Der private Schlüssel befindet sich auf dem intelligenten Karte.
2. Outlook fordert den Benutzer zur Eingabe der smarten Karte PIN auf. Der Benutzer gibt die richtige PIN ein.
3. Für den Signaturvorgang werden E-Mail-Daten an die smarte Karte gesendet. Der Outlook-Client formatiert die Antwort und sendet die E-Mail.
4. Der Benutzer öffnet das Internet Explorer und versucht, auf einen geschützten Standort zuzugreifen, für den die TLS-Clientauthentifizierung erforderlich ist.
5. Internet Explorer fordert den Benutzer zur Eingabe der smarten Karte-PIN auf. Der Benutzer gibt die richtige PIN ein.
6. Der TLS-bezogene Private Key-Vorgang erfolgt auf dem intelligenten Karte, und der Benutzer wird authentifiziert und angemeldet.
7. Der Benutzer kehrt zu Outlook zurück, um eine weitere signierte E-Mail zu senden. Diesmal wird der Benutzer nicht zur Eingabe einer PIN aufgefordert, da die PIN aus dem vorherigen Vorgang zwischengespeichert wird. Wenn der Benutzer den Internet-Explorer erneut verwendet, um einen anderen Vorgang auszuführen, fordert internet Explorer den Benutzer nicht zur Eingabe einer PIN auf.

Der Basis-CSP verwaltet intern einen Prozesscache der PIN, um die Zwischenspeicherung zu aktivieren. Die PIN wird verschlüsselt im Arbeitsspeicher gespeichert. Die Funktionen, die zum Sichern der PIN verwendet werden, sind RtlEncryptMemory, RtlDecryptMemory und RtlSecureZeroMemory. Dadurch werden Puffer auf Null gesetzt, die die PIN enthalten haben.

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

Abbildung 6 Kryptografiearchitektur in Windows Vista

Basis-CSP- und Smart Karte 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 Intelligente Karte KSP-Eigenschaften

Eigenschaft	BESCHREIBUNG
PP_USER_CERTSTORE	Wird verwendet, um einen HCERTSTORE zurückzugeben, der alle Benutzerzertifikate auf dem smarten Karte enthält. Schreibgeschützt (wird nur von CryptGetProvParam verwendet). Anrufer, der für das Schließen des Zertifikatspeichers verantwortlich ist. Mit PKCS_7_ASN_ENCODING oder X509_ASN_ENCODING codiertes Zertifikat CSP sollte KEY_PROV_INFO für Zertifikate festlegen Es sollte davon ausgegangen werden, dass es sich bei dem Zertifikatspeicher um einen Speicher im Arbeitsspeicher handelt. 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 Auflistung von Stammzertifikaten in den smarten Karte zu schreiben oder einen HCERTSTORE zurückzugeben, der Stammzertifikate aus dem smarten Karte Wird hauptsächlich für Domänenbeitritte mit smarten Karte Anrufer, der für das Schließen des Zertifikatspeichers verantwortlich ist
PP_SMARTCARD_READER	Schreibgeschützt (nur CryptGetProvParam) Gibt den Smart Karte-Lesernamen als ANSI-Zeichenfolge zurück, die zum Erstellen eines vollqualifizierten Containernamens (Reader + Container) verwendet wird.
PP_SMARTCARD_GUID	Zurückgeben Karte GUID (auch als Seriennummer bezeichnet), die für jede intelligente Karte Wird vom Zertifikatverteilungsdienst verwendet, um die Quelle eines Stammzertifikats nachzuverfolgen
PP_UI_PROMPT	Wird verwendet, um die Suchzeichenfolge für SCardUIDlgSelectCard Karte Einfügedialog festzulegen Persistent für den gesamten Prozess nach dem Festlegen Schreibgeschützt (wird nur von CryptSetProvParam verwendet)

Auswirkungen von CSPs in Windows Vista

CSP wird in Windows Vista weiterhin unterstützt. Dies wird jedoch nicht empfohlen, insbesondere wenn Sie mit Smartcards kommunizieren möchten. Die Verwendung des vorhandenen Basis-CSP und smart Karte KSP mit dem Smart Karte Minitreibermodell für Smartcards bietet erhebliche Vorteile in Bezug auf Leistung, PIN und Datenzwischenspeicherung. Derselbe Minitreiber kann so konfiguriert werden, dass er sowohl unter CAPI- als auch unter CNG-Ebenen funktioniert und von erweiterter kryptografischer Unterstützung, elliptischer Kurvenkryptografie und AES profitiert.

Wenn eine intelligente Karte sowohl von einem CSP als auch von einem smart Karte Minitreiber registriert wird, wird deren zuletzt installierter Treiber für die Kommunikation mit dem intelligenten Karte verwendet.

Wann sollte ein smarter Karte Minitreiber, CSP oder KSP geschrieben werden?

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

Weitere Informationen zum Schreiben eines intelligenten Karte Minitreibers, CSP oder KSP finden Sie unter Bereitstellung von Unternehmens-Smartcards im Microsoft Windows SmartCard Framework (https://go.microsoft.com/fwlink/?LinkId=93348).

Windows Vista Gruppenrichtlinie Einstellungen

Die folgende Tabelle veranschaulicht die Gruppenrichtlinie Einstellungen, die auf Computerbasis verwendet werden können. Es gibt keine Einstellungen pro Benutzer. Einige dieser Einstellungen können nur auf eine Funktionsdomä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 bearbeiten und auf Computer in der Domäne anwenden. Smart Karte-bezogene Richtlinien sind unter

Computerkonfiguration\Administrative Vorlagen\Windows-Komponenten\Smartcard

Abbildung 7 Smart Karte-bezogene Einstellungen in Gruppenrichtlinie

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

Tabelle 7 Gruppenrichtlinie Einstellungen

Schlüssel	BESCHREIBUNG
AllowSignatureOnlyKeys	Lässt Signaturschlüssel zu, die für die Anmeldung gültig sind. Diese Einstellung gilt auch immer dann, wenn die Anmeldeinformations-Benutzeroberfläche aufgerufen wird. Mithilfe dieser Einstellung können signaturschlüsselbasierte Zertifikate aufgelistet und für die Anmeldung verfügbar sein. 1 (Aktiviert): Alle Zertifikate, die auf dem smarten Karte mit einem signaturgeschützten Schlüssel verfügbar sind, werden auf dem Anmeldebildschirm aufgeführt. 0 (Deaktiviert): Alle verfügbaren smarten Karte signaturschlüsselbasierte Zertifikate werden nicht auf dem Anmeldebildschirm aufgeführt. Nicht konfiguriert: Alle verfügbaren smart Karte signaturschlüsselbasierte Zertifikate werden nicht auf dem Anmeldebildschirm aufgeführt.
AllowCertificatesWithNoEKU	Ermöglicht die Verwendung von Zertifikaten ohne EKU-Satz für die Anmeldung. In früheren Versionen von Windows war die EKU-Erweiterung erforderlich, um den Smart Karte Anmeldeobjektbezeichner vorhanden zu haben. Diese Einstellung steuert diese Einschränkung. 1 (Aktiviert): Nur die smart Karte-basierten Zertifikate, die den Smart Karte Anmeldeobjektbezeichner oder keine EKU-Erweiterung enthalten, werden auf dem Anmeldebildschirm aufgeführt. 0 (Deaktiviert): Nur die smarten Karte-basierten Zertifikate, die den Anmeldeobjektbezeichner der intelligenten Karte enthalten, werden auf dem Anmeldebildschirm aufgeführt. Nicht konfiguriert: Auf dem Anmeldebildschirm werden nur die smart Karte basierenden Zertifikate aufgeführt, die den Anmeldeobjektbezeichner der intelligenten Karte enthalten.
AllowTimeInvalidCertificates	Ermöglicht die Anzeige von Zertifikaten für die Anmeldung, die entweder abgelaufen oder noch nicht gültig sind. In früheren Versionen von Windows mussten Zertifikate eine gültige Zeit enthalten und nicht abgelaufen sein. Das Zertifikat muss weiterhin vom Domänencontroller akzeptiert werden, damit es verwendet werden kann. Diese Einstellung steuert nur, ob das Zertifikat auf dem Clientcomputer angezeigt wird. 1 (aktiviert): Zertifikate werden auf dem Anmeldebildschirm aufgeführt, unabhängig davon, ob sie ungültige Zeiten haben oder ihre Gültigkeitsdauer abgelaufen ist. 0 (deaktiviert): Abgelaufene oder noch nicht gültige Zertifikate werden auf dem Anmeldebildschirm nicht aufgeführt. Nicht konfiguriert: Abgelaufene oder noch ungültige Zertifikate werden auf dem Anmeldebildschirm nicht aufgeführt.
AllowIntegratedUnblock	Hiermit können Sie bestimmen, ob die integrierte Entsperrungsfunktion auf der Anmeldeoberfläche verfügbar ist. Um die integrierte Entsperrungsfunktion verwenden zu können, muss Ihr intelligenter Karte dieses Feature unterstützen. Fragen Sie Ihren Hardwarehersteller, ob Ihr intelligenter Karte dieses Feature unterstützt. 1 (Aktiviert): Die integrierte Funktion zum Aufheben der Blockierung ist verfügbar. 0 (deaktiviert): Die integrierte Entsperrungsfunktion ist nicht verfügbar. Nicht konfiguriert: Die integrierte Entsperrungsfunktion ist nicht verfügbar.
ReverseSubject	Ermöglicht ihnen das Umkehren des Antragstellernamens von seiner Speicherung im Zertifikat, wenn er während der Anmeldung angezeigt wird. Standardmäßig wird der Benutzerprinzipalname (UPN) zusätzlich zum allgemeinen Namen angezeigt, um Benutzern dabei zu helfen, ein Zertifikat von einem anderen zu unterscheiden. Wenn der Zertifikatantragsteller z. B. CN=User1, OU=Users, DN=contoso, DN=com lautet und wenn er einen UPN von user1@contoso.comaufweist, wird "User1" zusammen mit "user1@contoso.com" angezeigt. Wenn der UPN nicht vorhanden ist, wird der gesamte Antragstellername angezeigt. Diese Einstellung steuert die Darstellung dieses Antragstellernamens und muss möglicherweise pro organization angepasst werden. 1 (Aktiviert): Der Antragstellername wird umgekehrt. 0 (deaktiviert): Der Antragstellername wird so angezeigt, wie er im Zertifikat angezeigt wird. Nicht konfiguriert: Der Antragstellername wird umgekehrt.
X509HintsNeeded	Ermöglicht Es Ihnen, zu bestimmen, ob ein optionales Feld während der Anmeldung und Der Rechteerweiterung angezeigt wird, das es einem Benutzer ermöglicht, seinen Benutzernamen oder benutzernamen und seine Domäne einzugeben, wodurch diesem Benutzer ein Zertifikat 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 ihnen, eine bestimmte Zeichenfolge zu verwalten, wird angezeigt, wenn eine intelligente Karte blockiert wird. 1 (Aktiviert): Die angegebene Zeichenfolge wird dem Benutzer angezeigt, wenn die intelligente Karte blockiert wird. Hinweis Sie müssen auch sicherstellen, dass Sie die folgende Einstellung in Gruppenrichtlinie aktivieren: Die Anzeige des Bildschirms "Integrierte Blockierung aufheben" zum Zeitpunkt der Anmeldung zulassen. 0 (Deaktiviert): Die Standardzeichenfolge wird dem Benutzer angezeigt, wenn die intelligente Karte blockiert wird, wenn die integrierte Funktion zum Aufheben der Blockierung aktiviert ist. Nicht konfiguriert: Die Standardzeichenfolge wird dem Benutzer angezeigt, wenn die intelligente Karte blockiert wird, wenn die integrierte Funktion zum Aufheben der Blockierung aktiviert ist.
CertPropEnabledString	Ermöglicht ihnen die Verwaltung der Zertifikatweitergabe, die beim Einfügen eines intelligenten Karte erfolgt. 1 (aktiviert): Die Zertifikatweitergabe erfolgt, wenn Sie Ihre intelligente Karte einfügen. 0 (deaktiviert): Die Zertifikatweitergabe erfolgt nicht, und die Zertifikate werden nicht für Anwendungen wie Outlook zur Verfügung gestellt. Nicht konfiguriert: Die Zertifikatweitergabe erfolgt, wenn Sie Ihre intelligente Karte einfügen.
CertPropRootEnabledString	Ermöglicht Ihnen die Verwaltung der Stammzertifikatweitergabe, die beim Einfügen eines intelligenten Karte erfolgt. 1 (aktiviert): Die Stammzertifikatweitergabe erfolgt, wenn Sie Ihre intelligente Karte einfügen. Hinweis Damit diese Richtlinieneinstellung funktioniert, muss auch die folgende Richtlinieneinstellung aktiviert sein: Aktivieren der Zertifikatweitergabe über intelligente Karte. 0 (deaktiviert): Stammzertifikate werden nicht vom intelligenten Karte weitergegeben. Nicht konfiguriert: Die Stammzertifikatweitergabe erfolgt, wenn Sie Ihre intelligente Karte einfügen.
RootsCleanupOption	Ermöglicht ihnen das Konfigurieren von Stammzertifikaten sauber up. Diese Option befindet sich unter HKLM\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\CertProp. Ermöglicht ihnen die Verwaltung des Bereinigungsverhaltens von Stammzertifikaten. Wenn Sie diese Richtlinieneinstellung aktivieren, erfolgt die Stammzertifikatbereinigung gemäß der ausgewählten Option. Wenn Sie diese Einstellung deaktivieren oder nicht konfigurieren, erfolgt die Stammzertifikatbereinigung bei der Abmeldung. Zu den Bereinigungsoptionen für Stammzertifikate gehören: Keine Bereinigung (Standard) Bereinigung von Zertifikaten beim Entfernen intelligenter Karte Bereinigung von Zertifikaten bei Benutzeranmeldung Hinweis Diese Richtlinie funktioniert in Verbindung mit HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots\Flags. Wenn dies festgelegt ist (standardmäßig deaktiviert), werden Stammzertifikate für die Weitergabe deaktiviert, auch von intelligenten Karte.
Smartcard erforderlich (Computerrichtlinie): Richtlinien für die interaktive Anmeldung. Siehe Abbildung 9.	Erzwingt intelligente Karte, die für die Anmeldung auf Computerbasis erforderlich sind. Dieser Schlüssel befindet sich in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Policies\System\scforceoption. Die folgenden Werte werden unterstützt: 0: Keine Aktion 1: Aktivieren der intelligenten Karte Für die Anmeldung erforderlich
Richtlinie zum Entfernen von Smartcards – Richtlinien für die interaktive Anmeldung. Siehe Abbildung 10.	Hinweis Wenn der Intelligente Karte-Entfernungsrichtliniendienst nicht ausgeführt wird, starten Sie den Dienst mit dem Befehl net start ScPolicySvc, und legen Sie start type auf Auto (sc config scpolicysvc start= auto) fest. Dieser Schlüssel befindet sich in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\scremoveoption. Wenn dies festgelegt ist (standardmäßig aus, 0), wird die Arbeitsstation durch Entfernen des intelligenten Karte gesperrt. Die folgenden Werte werden unterstützt: 0: Keine Aktion 1: Sperren der Arbeitsstation – Benutzersitzung bei smarter Karte Entfernung gesperrt 2: Abmelden – Benutzer, der sich beim Entfernen von smart Karte angemeldet hat 3: Trennen Sie die Remote-Terminalserversitzung – entfernen Sie die intelligente Karte trennt die Sitzung, ohne den Benutzer abzumelden. Dies ermöglicht es dem Benutzer, die intelligente Karte einzufügen und die Sitzung später oder an einem anderen mit einem Intelligenten Karte Leser ausgestatteten Terminal fortzusetzen, ohne sich erneut anmelden zu müssen.
FilterDuplicateCertificates	Hiermit können Sie konfigurieren, ob alle gültigen Anmeldezertifikate angezeigt werden. Während des Zertifikatverlängerungszeitraums kann ein Benutzer mehrere gültige Anmeldezertifikate aus derselben Zertifikatvorlage ausgestellt haben. Dies kann zu Verwirrung darüber führen, 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 das alte noch nicht abgelaufen ist. Zwei Zertifikate werden als identisch festgelegt, wenn sie von derselben Vorlage mit derselben Hauptversion ausgestellt werden, und sie gelten für denselben Benutzer (bestimmt durch ihren UPN). Wenn sich mindestens zwei der "gleichen" Zertifikate auf einem intelligenten Karte befinden und diese Richtlinie aktiviert ist, wird das Zertifikat angezeigt, das für die Anmeldung unter Windows 2000, Windows XP und Windows 2003 Server verwendet wird. Andernfalls wird das Zertifikat mit der am weitesten entfernten Ablaufzeit in der Zukunft angezeigt. Hinweis Diese Einstellung wird nach der folgenden Einstellung angewendet: Zeit ungültige Zertifikate zulassen. 1 (aktiviert): Die Filterung erfolgt. 0 (deaktiviert): Es wird keine Filterung durchgeführt. Nicht konfiguriert: Die Filterung erfolgt.
ForceReadingAllCertificates	Ermöglicht es Ihnen, das Lesen aller Zertifikate aus dem intelligenten Karte zu erzwingen, unabhängig von der unterstützten Funktion, die im CSP festgelegt ist. Diese Richtlinie gilt immer dann, wenn der Smart Karte Anmeldeinformationsanbieter oder die Anmeldeinformationsoberfläche aufgerufen wird. 1 (Aktiviert): Windows versucht, alle Zertifikate auf dem smarten Karte zu lesen, unabhängig vom Featuresatz im CSP. 0 (Deaktiviert): Windows liest nur den Standardcontainer der smarten Karte für die Anmeldung, es sei denn, es unterstützt den Abruf aller Zertifikate in einem einzigen Aufruf. 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 des smarten Karte für die Anmeldung, es sei denn, es unterstützt den Abruf aller Zertifikate in einem einzelnen 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, benötigt der KDC nicht das Smartcardzertifikat, das die Smartcardauthentifizierungs-EKU enthält. Typ: DWORD Standardwert: 0

Hinweis

Während der Bereitstellung sind möglicherweise zusätzliche Richtlinien erforderlich, um die Benutzerfreundlichkeit zu vereinfachen oder die Sicherheit zu verbessern. Einige dieser Richtlinien umfassen:

Deaktivieren der Delegierung für Computer.

Interaktive Anmeldung: Strg+ALT+ENTF nicht erforderlich (nicht empfohlen).

Lokale CSP-Basisrichtlinieneinstellungen

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

Hinweis

Die lokalen Einstellungen für smart Karte KSP befinden sich unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Providers\Microsoft smart Karte Schlüsselspeicheranbieter.

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

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

Schlüssel	BESCHREIBUNG
DefaultPrivateKeyLenBits	Typ: DWORD Standardwert: 00000400 Standardparameter für die Schlüsselgenerierung: 1024-Bit-Schlüssel
RequireOnCardPrivateKeyGen	Wenn dieser Wert festgelegt ist, kann ein auf einem Host generierter Schlüssel in die intelligente Karte importiert werden. Dies wird für Smartcards verwendet, die keine on-Karte-Schlüsselgenerierung unterstützen, oder für die Schlüsseltresor erforderlich ist. Typ: DWORD Standardwert: 000000000. Dadurch wird das Flag für die Anforderung der Karte privaten Schlüsselgenerierung (Standard) festgelegt.
TransactionTimeoutMilliseconds	Typ: DWORD Standardwert: 000005dc1500. 1,5 Sekunden ist das Standardtimeout für das Halten von Transaktionen an der intelligenten Karte.
AllowPrivateECDHEKeyImport	Dieser Wert ermöglicht den Import des privaten ECDHE-Schlüssels zur Verwendung in Schlüsselarchivierungsszenarien. Typ: DWORD Standardwert: 000000000.
AllowPrivateECDSAKeyImport	Dieser Wert ermöglicht den Import des privaten ECDSA-Schlüssels zur Verwendung in Schlüsselarchivierungsszenarien. Typ: DWORD Standardwert: 000000000

Gruppenrichtlinie Richtlinien für Administratoren, die nur smarte Karte Anmeldung bereitstellen

Konfigurieren eines Benutzerkontos für smarte Karte-only-Anmeldung

So konfigurieren Sie ein Benutzerkonto für eine intelligente Karte anmeldung

1. Melden Sie sich bei einem Windows Server-Computer als Domänenadministrator 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, für den Sie die intelligente Karte-only-Anmeldung aktivieren möchten, und klicken Sie dann auf Eigenschaften.

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

6. Aktivieren Sie unter Kontooptionen das Kontrollkästchen Smart Karte für interaktive Anmeldung erforderlich ist, und klicken Sie dann auf OK.

   Abbildung 8 zeigt diese Konfiguration.

Abbildung 8 Keine Delegierung und intelligente Karte Domäneneinstellung für Benutzerkonten erforderlich

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

Abbildung 9 Smart Karte-Einstellung erforderlich (pro Computer erzwungen)

Abbildung 10 zeigt, wie Sie die Richtlinie zum Entfernen von intelligenten Karte aktivieren.

Abbildung 10 Einstellung zum Entfernen von smarten Karte

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

Abbildung 11 Die Einstellung STRG+ALT+ENTF beim Anmeldebildschirm nicht erforderlich

Abbildung 12 zeigt, wie Benutzerkonten oder Computer für die Delegierung aktiviert werden. Es wird dringend empfohlen, alle Änderungen, die Sie an der Delegierung für Benutzer und Computer vornehmen, sorgfältig zu berücksichtigen. Die Sicherheitsrisiken können in einigen Szenarien sehr hoch sein. Die Delegierung kann jedoch nützlich sein, wenn Sie windows Managed Instrumentation (WMI) ausführen.

Abbildung 12 Einstellung zur Delegierung von Benutzern und Computern

Wenn Intelligente Karte Administratoren den Computer verwenden, wird dringend empfohlen, die Delegierung auf dem Computer zu deaktivieren. Abbildung 13 zeigt diese Einstellung in Gruppenrichtlinie.

Abbildung 13 Einstellung "Nicht vertrauen für delegierungsdomänen"

Windows Vista-Dienste

Drei Dienste in Windows Vista ermöglichen intelligente Karte-Verwaltung:

• Smart Karte Resource Manager-Dienst
• Zertifikatweitergabedienst
• Smart Karte-Entfernungsdienst

Smart Karte Resource Manager-Dienst

Der Smart Karte Resource Manager stellt die grundlegende Infrastruktur für alle anderen Smart Karte-Komponenten bereit. Der Intelligente Karte-Ressourcen-Manager verwaltet intelligente Karte Leser und Anwendungsinteraktionen auf dem Computer. Es ist vollständig PC/SC 1.0 kompatibel.

Der Smart Karte Resource Manager wird im Kontext eines lokalen Diensts ausgeführt und als gemeinsamer Dienst des svchost-Prozesses implementiert. Der Smart Karte Resource Manager-Dienst weist die folgende Dienstbeschreibung auf:

<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 Class und ClassGUID angeben, damit winscard.dll als richtiges Klasseninstallationsprogramm aufgerufen werden können:

Class=SmartCardReader

ClassGuid={50DD5230-BA8A-11D1-BF5D-0000F805F530}

Standardmäßig ist der Dienst für den manuellen Modus konfiguriert. Smart Karte Lesertreiberautoren müssen den Dienst so konfigurieren, dass er automatisch startet und einen vordefinierten Einstiegspunkt in winscard.dll aufruft, der den Dienst startet. Mit dieser Methode wird sichergestellt, dass der Dienst aktiviert wird, wenn er benötigt wird, aber auch für die große Mehrheit der Benutzer deaktiviert ist, die keine Smartcards verwenden.

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

Es wird dringend empfohlen, die gesamte Kommunikation mit lesern der intelligenten Karte unter Windows über den Ressourcen-Manager für intelligente Karte zu senden. Es bietet eine umfassende Schnittstelle zum Nachverfolgen, Auswählen und Kommunizieren mit allen Treibern, die sich selbst als Mitglieder der Gerätegruppe für intelligente Karte Leser deklarieren. Der Ressourcen-Manager für intelligente Karte kategorisiert jeden Smart Karte Reader-Slot als eindeutigen Reader. Jeder Slot wird unabhängig von den physischen Eigenschaften des Geräts auch separat verwaltet. Der Ressourcen-Manager für intelligente Karte verarbeitet die folgenden allgemeinen Aktionen:

• Geräteeinführung
• Leserinitialisierung
• Benachrichtigung von Clients über neue Leser
• Serialisieren des Zugriffs auf Leser
• Zugriff auf intelligente Karte
• Tunneln von readerspezifischen Befehlen

Zertifikatverteilungsdienst

Der Zertifikatweitergabedienst wird angewendet, wenn ein angemeldeter Benutzer eine intelligente Karte in einen Leser einfügt, der an den Computer angefügt ist. Diese Aktion bewirkt, dass die Zertifikate aus dem intelligenten Karte 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 Zertifikatverteilungsmodells. Im Diagramm fügt ein angemeldeter Benutzer eine intelligente Karte ein. Der erste Pfeil gibt an, dass der Dienstcontroller CertPropSvc benachrichtigt, wenn sich ein Benutzer angemeldet hat. Bei der Anmeldebenachrichtigung beginnt CertPropSvc mit der Überwachung der Smartcards, die in der Benutzersitzung sichtbar sind. Der Pfeil mit der Markierung R stellt die Möglichkeit einer Remotesitzung und die Verwendung von smart Karte Umleitung dar.

Abbildung 14 Zertifikatweitergabedienst

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

Hinweis

Der Zertifikatverteilungsdienst wird als Abhängigkeit vom Terminaldienstedienst gestartet.

Im Folgenden werden die Eigenschaften des Zertifikatweitergabediensts aufgelistet:

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

Stammzertifikatweitergabe

Die Stammzertifikatweitergabe ist für bestimmte Smart Karte-Bereitstellungsszenarien verantwortlich, in denen noch keine PKI-Vertrauensstellung eingerichtet wurde:

• Beitreten zur Domäne
• Remotezugriff auf ein Netzwerk

In beiden Fällen ist der Computer nicht mit einer Domäne verbunden, und daher wird die Vertrauensstellung nicht von Gruppenrichtlinie verwaltet. Das Ziel besteht jedoch darin, sich bei einem Remoteserver (Domänencontroller oder RADIUS-Server) zu authentifizieren. Die Stammzertifikatverteilung bietet die Möglichkeit, die intelligente Karte zu verwenden, um die fehlende Vertrauenskette einzuschließen.

Beim Einfügen von intelligenten Karte verteilt der Zertifikatweitergabedienst alle Stammzertifikate auf dem Karte an die vertrauenswürdigen Smart Karte Stammcomputerzertifikatspeicher. Dadurch wird eine Vertrauensstellung mit dem Unternehmen hergestellt. Sie können auch eine nachfolgende Bereinigungsaktion verwenden, wenn die intelligente Karte des Benutzers aus dem Reader entfernt wird oder wenn sich der Benutzer abmeldet. Tabelle 7 zeigt, wie dies mit Gruppenrichtlinie konfigurierbar ist.

Weitere Informationen zu Den Anforderungen für Stammzertifikate finden Sie unter Smartcard-Stammzertifikatanforderungen für Benutzer mit einem Domänenbeitritt.

Richtliniendienst für intelligente Karte-Entfernung

Die Richtlinie zum entfernen von intelligenten Karte gilt, wenn sich ein Benutzer mit einem intelligenten Karte angemeldet hat und diese intelligente Karte anschließend aus dem Leser entfernt. Die Aktion, die ausgeführt wird, wenn die intelligente Karte entfernt wird, wird mit Gruppenrichtlinie gesteuert, wie in Tabelle 7 gezeigt.

Abbildung 15 Smart Karte Entfernungsrichtliniendienst

1. In Windows Vista ist Winlogon nicht mehr direkt an der Überwachung von Intelligenten Karte Entfernungsereignissen beteiligt. Die Abfolge der Schritte für die Entfernungsrichtlinie beginnt mit dem Anbieter für intelligente Karte Anmeldeinformationen im Anmeldeprozess der Benutzeroberfläche. Wenn sich ein Benutzer erfolgreich mit einem intelligenten Karte anmeldet, erfasst der Anbieter für intelligente Karte Anmeldeinformationen, wie oft die intelligente Karte eingefügt oder aus dem Leser entfernt wurde (die Aktivitätsanzahl), sowie den Namen des Lesers. Diese Informationen werden dann in der Registrierung zusammen mit dem Sitzungsbezeichner gespeichert, an dem die Anmeldung initiiert wurde. Die Aktivitätsanzahl entspricht den oberen 16 Bits des dwEventState-Felds des Readers, wie aus SCardGetStatusChange ersichtlich.
2. Der Ressourcen-Manager für intelligente Karte benachrichtigt den Smart Karte-Entfernungsrichtliniendienst, dass eine Anmeldung erfolgt ist.
3. ScPolicySvc ruft die Statistiken der intelligenten Karte aus der Registrierung ab, die der Smart Karte-Anmeldeinformationsanbieter gespeichert hat. Diese Statistiken werden verwendet, um sicherzustellen, dass die intelligente Karte nicht entfernt wurde und möglicherweise während der Übergabe zwischen dem Smart Karte Anmeldeinformationsanbieter und ScPolicySvc begann, die intelligente Karte auf Entfernungen zu überwachen. Dieser Aufruf wird umgeleitet, wenn sich der Benutzer in einer Remotesitzung befindet. Nachdem der Benutzer die intelligente Karte entfernt hat oder wenn die intelligente Karte während der Übergabe entfernt wurde, wird ScPolicySvc benachrichtigt.
4. ScPolicySvc ruft den Terminalserver auf, um die entsprechende Aktion auszuführen, wenn die Anforderung darin besteht, den Benutzer abzumelden oder die Sitzung des Benutzers zu trennen. (Dies kann zu Datenverlust führen.) Wenn die Einstellung so konfiguriert ist, dass der Computer gesperrt wird, wenn die intelligente Karte entfernt wird, sendet ScPolicySvc eine Nachricht an Winlogon, um den Computer zu sperren.

Windows Vista-Szenarien

Zertifikatanforderungen für die Smart Karte-Anmeldung

Zertifikatanforderungen für Windows XP und frühere Versionen

Das Smart Karte-Zertifikat hat bestimmte Formatanforderungen, wenn es mit Windows XP und früheren Plattformen verwendet wird.

Tabelle 10 Vor-Windows Vista-Zertifikatanforderungen

Komponente	Anforderung
CRL Distribution Point (CDP)-Speicherort	Der Speicherort muss aufgefüllt, online und verfügbar sein. Beispiel: [1] CRL-Verteilungspunkt Name des Verteilungspunkts: Vollständiger Name: URL=http://server1.contoso.com/CertEnroll/caname.crl
Schlüsselverwendung	Digitale Signatur
Grundlegende Einschränkungen	[Subject Type=End Entity, Path Length Constraint=None] (Optional)
Erweiterte Schlüsselverwendung	Clientauthentifizierung (1.3.6.1.5.5.7.3.2) (Der Objektbezeichner der Clientauthentifizierung ist nur erforderlich, wenn ein Zertifikat für die SSL-Authentifizierung verwendet wird.) Smartcardanmeldung (1.3.6.1.4.1.311.20.2.2)
Alternativer Antragstellername	Anderer Name: Principal Name= (UPN). Beispiel: UPN = user1@contoso.com Die UPN OtherName-OID lautet "1.3.6.1.4.1.311.20.2.3". Der UPN OtherName-Wert muss ASN1-codierte UTF8-Zeichenfolge sein.
Subject	Distinguished name of user. Dieses Feld ist eine obligatorische Erweiterung, aber die Auffüllung dieses Felds ist optional.

Es gibt zwei vordefinierte Typen von privaten Schlüsseln. Diese Schlüssel sind nur Signatur (AT_SIGNATURE) und Schlüsselaustausch (AT_KEYEXCHANGE). Smartcard-Anmeldezertifikate müssen über einen privaten Schlüsseltyp (Key Exchange, AT_KEYEXCHANGE) verfügen, damit die Smartcardanmeldung 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	Smart Karte Anmeldeobjektbezeichner nicht erforderlich. Siehe Tabelle 7.
Alternativer Antragstellername	Die E-Mail-ID ist für smarte Karte Anmeldung nicht erforderlich. Siehe Tabelle 7.
Schlüsselaustausch (feld AT_KEYEXCHANGE)	Für Smart Karte-Anmeldezertifikate nicht erforderlich.

Sie können aktivieren, dass jedes Zertifikat für den Intelligenten Karte Anmeldeinformationsanbieter sichtbar ist. Wenn eine EKU vorhanden ist, muss sie die EKU smart Karte Logon EKU enthalten. Zertifikate ohne EKU können für die Anmeldung verwendet werden.

Wie funktioniert intelligente Karte Anmeldung in Windows?

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

• Jedes Zertifikat muss über einen Benutzerprinzipalnamen (User Principal Name, UPN) verfügen und den Smart Karte Anmeldeobjektbezeichner (auch als OID bezeichnet) im EKU-Attributfeld enthalten. Wenn die EKU vorhanden ist, muss eine intelligente Karte OID für die Anmeldung vorhanden sein. Es gibt eine Gruppenrichtlinieneinstellung, um EKU optional zu machen.

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

  Hinweis

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

• Zertifikate müssen über einen Wert für die Verwendung des Schlüssels für die digitale Signatur verfügen. Diese Anforderung gilt weiterhin für Windows Vista.

Um die Unterstützung für Bereitstellungen von intelligenten Karte 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.

Intelligente Karte-basierte Anmeldung in Windows Vista

Smart Karte Anmeldung unter Windows Vista hat sich in mehreren wichtigen Aspekten geändert. Die wichtigsten Unterschiede werden unten hervorgehoben:

• Die Anmeldung wird beim Einfügen von smart Karte nicht mehr ausgelöst. Benutzer müssen normalerweise STRG+ALT+ENTF drücken, um den Anmeldevorgang zu starten.
• Gültige Zertifikate werden aufgezählt und von allen Smartcards angezeigt und dem Benutzer angezeigt. Die intelligente Karte muss eingefügt werden, bevor der Benutzer die PIN eingeben kann.
• Schlüssel sind nicht mehr darauf beschränkt, sich im Standardcontainer zu befinden, und Zertifikate in verschiedenen Smartcards können ausgewählt werden.
• Auf den CSP wird in lsass.exe zugegriffen (wie unter Smartcard-Anmeldeflow 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 einen schnellen Benutzerwechsel zu ermöglichen, sollten Sie diese Tatsache nicht übersehen.
• ECC-basierte Zertifikate werden für die Anmeldung mit intelligenten Karte in Windows nicht unterstützt. ECC-basiertes PKINIT wird noch als Teil der IETF standardisiert (http://www.ietf.org/html.charters/krb-wg-charter.html).

Zertifikataufzählung

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

Hinweis

Sofern nicht anders angegeben, werden alle Vorgänge im Hintergrund ausgeführt (CRYPT_SILENT wird an CryptAcquireContext übergeben).

1. Die smart Karte Resource Manager-Datenbankabfragen für den CSP des intelligenten Karte.
2. Ein qualifizierter Containername wird mithilfe des abgerufenen Lesernamens erstellt und an den CSP übergeben. Das Format für diesen Namen lautet wie folgt: \\.\<Readername>\
3. CryptAcquireContext wird aufgerufen, um einen Kontext für den Standardcontainer abzurufen. Ein Fehler hier würde dazu führen, dass die intelligente Karte für die Anmeldung mit intelligenten Karte nicht verwendet werden kann.
4. Der Name des Containers wird abgerufen, indem der parameter PP_CONTAINER mithilfe von CryptGetProvParam angefordert wird.
5. Mithilfe des in Schritt 3 abgerufenen Kontexts wird der CSP nach dem parameter PP_USER_CERTSTORE abgefragt, der in Windows Vista hinzugefügt wurde. (Weitere Informationen finden Sie unter Smart Karte-Subsystemarchitektur.) Wenn der Vorgang erfolgreich ist, wird ein Zertifikatspeicher zurückgegeben, und der Programmablauf wird mit Schritt 8 fortgelassen.
6. Wenn der Vorgang in Schritt 5 fehlschlägt, wird der Standardcontainerkontext aus Schritt 3 nach dem schlüssel AT_KEYEXCHANGE abgefragt.
7. Das Zertifikat wird dann mithilfe von KP_CERTIFICATE aus dem Schlüsselkontext abgefragt. Das Zertifikat wird einem In-Memory-Zertifikatspeicher hinzugefügt.
8. Für jedes Zertifikat im Zertifikatspeicher aus Schritt 5 oder Schritt 7 werden die folgenden Überprü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 sich nicht im AT_SIGNATURE Teil eines Containers befinden.
   3. Das Zertifikat muss über einen gültigen UPN verfügen.
   4. Das Zertifikat muss über die Schlüsselverwendung für digitale Signaturen verfügen.
   5. Das Zertifikat muss über die EKU smart Karte Anmeldung verfügen.
      Diese Anforderungen sind die gleichen Anforderungen wie in Windows 2003, werden jedoch 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 E-Mail-Adresse oder Betreff, je nach 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. Bei erfolgreicher Ausführung wird logonUI.exe abgerissen. Dadurch wird der in Schritt 3 abgerufene Kontext freigegeben.

Smart Karte Anmeldeflow in Windows Vista

Die meisten Probleme während der Authentifizierung treten aufgrund des Sitzungsverhaltens auf. Außerdem erfordert die LSA den Kontext nicht erneut; Die Sitzungsänderung wird stattdessen vom CSP verarbeitet.

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

Diese Änderungen sind jedoch nicht standardmäßig aktiviert, mit Ausnahme der 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 im intelligenten Karte mithilfe der Clientauthentifizierungs-EKU filtern. Der Anmeldeinformationsanbieter verfügt auch über die Richtlinie AllowSignatureOnlyKeys (entspricht dem AT_SIGNATURE Schlüsselwert in CAPI), um zu bestimmen, ob die Clientzertifikate basierend auf der Anforderung gefiltert werden müssen, dass das Anmeldezertifikat verschlüsselungsfähig ist, indem der Benutzer Zertifikate anzeigen und auswählen kann, die nur signieren. Diese Richtlinieneinstellungen haben direkten Einfluss auf die Filterung und die resultierende Anzeige von Zertifikaten auf der Anmeldeoberfläche.

Abbildung 16 veranschaulicht, wie intelligente Karte Anmeldung in Windows Vista funktioniert.

Abbildung 16 Smart Karte Anmeldeflow

Flusssequenz:

1. WinLogon fordert die Anmeldeinformationen der Benutzeroberfläche an.

2. Asynchron wird smart Karte Resource Manager gestartet. Der Anmeldeinformationsanbieter für intelligente Karte:

   1. Ruft Anmeldeinformationen ab, eine Liste bekannter Anmeldeinformationen oder keine, oder, dass Windows einen intelligenten Karte-Leser erkannt hat.
   2. Ruft eine Liste der Leser der intelligenten Karte (verwendet die WinSCard-API) und die Liste der smartcards ab, die in die einzelnen Smartcards eingefügt wurden.
   3. Listet jeden Karte auf, um zu überprüfen, ob ein von Gruppenrichtlinie gesteuertes Anmeldezertifikat (Signatur) vorhanden ist. Wenn das Zertifikat vorhanden ist, kopiert der Anbieter für intelligente Karte Anmeldeinformationen es in einen temporären sicheren Cache im Terminal.
   4. Benachrichtigt die Anmeldeoberfläche, dass sie über neue Anmeldeinformationen verfügt.

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

4. Der Benutzer gibt die PIN ein und klickt auf Los. Der Smart Karte Anmeldeinformationsanbieter verschlüsselt die PIN.

5. Der Anmeldeinformationsanbieter, der sich im Anmeldeprozess (System) befindet, erfasst die PIN. Als Teil des Packens von Anmeldeinformationen im Smart Karte Anmeldeinformationsanbieter werden die Daten in einer KERB_CERTIFICATE_LOGON-Struktur (definiert in CredentialProviders.h) verpackt. Die Standard Inhalte der KERB_CERTIFICATE_LOGON-Struktur sind smart Karte PIN, cspdata (enthält Lesername, Containername usw.), Benutzername und Domänenname. 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 Karte Schlüsselspezifikation) und wird zurück an LogonUI gesendet.

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

8. LSA ruft Kerberos Authentication Package (Kerberos SSP) auf, um eine Kerberos-Authentifizierungsdienstanforderung (KRB_AS_REQ) zu erstellen, die einen Präauthentifikator enthält (wie in RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) (https://go.microsoft.com/fwlink/?LinkId=93352)).
   Wenn die Authentifizierung mithilfe eines Zertifikats mit einer Schlüsselverwendung der digitalen Signatur erfolgt, bestehen 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 erfolgt, dessen Schlüsselschlüsselschlüsselung verwendet wird, bestehen 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 Vorgang mit privatem Schlüssel ausgeführt. Da der private Schlüssel in diesem Fall in einem intelligenten Karte gespeichert wird, wird das Untersystem smart Karte aufgerufen, und der erforderliche Vorgang ist abgeschlossen. Das Ergebnis wird zurück an den Kerberos-SSP gesendet.

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 Granting Ticket (TGT) anzufordern.

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

12. Das KDC überprüft das Zertifikat des Benutzers (Zeit, Pfad und Sperrung status), um sicherzustellen, dass das Zertifikat von einer vertrauenswürdigen Quelle stammt. Das KDC verwendet CryptoAPI (CAPI2), um einen Zertifizierungspfad vom Zertifikat des Benutzers zu einem Stammzertifizierungsstellenzertifikat zu erstellen, das sich im Stammspeicher auf dem Domänencontroller befindet. Der KDC verwendet dann CryptoAPI (CAPI2), um die digitale Signatur auf dem Authentifikator zu überprüfen, der als signierte Daten in den Datenfeldern vor der Authentifizierung enthalten war. Der Domänencontroller überprüft die Signatur und verwendet den öffentlichen Schlüssel aus dem Zertifikat des Benutzers, um nachzuweisen, dass die Anforderung vom Besitzer des privaten Schlüssels stammt, der dem öffentlichen Schlüssel entspricht. Der KDC überprüft auch, ob der Aussteller vertrauenswürdig ist und im NTAUTH-Zertifikatspeicher angezeigt wird.

13. Der KDC-Dienst ruft Benutzerkontoinformationen aus Active Directory ab. Das KDC erstellt einen TGT basierend auf den Benutzerkontoinformationen, die er aus Active Directory abruft. Der TGT umfasst den Sicherheitsbezeichner (SID) des Benutzers, 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, denen der Benutzer angehört. Die Autorisierungsdatenfelder des TGT enthalten die Liste der SIDs.

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

    Hinweis

    Das KRB_AS_REP Paket besteht aus:

    Berechtigungsattributzertifikat (PAC)

    Sicherheits-ID (SID) des Benutzers

    SIDs beliebiger Gruppen, denen der Benutzer angehört

    Eine Anforderung für ticket granting service (TGS)

    Vorauthentifizierungsdaten

    Die Antwort lautet gemäß RFC 4556. TGT wird mit dem master Schlü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. Mithilfe von CAPI2-APIs wird der temporäre Schlüssel entschlüsselt. Wenn sich der private Schlüssel für denselben im Rahmen des Entschlüsselungsprozesses auf einer intelligenten Karte befindet, wird der Aufruf an das Smart Karte-Subsystem zurück ausgeführt, indem der angegebene Kryptografiedienstanbieter verwendet wird, 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 vom KDC (Zeit, Pfad und Sperrung status). Zunächst wird die Signatur des KDC überprüft, indem ein Zertifizierungspfad vom Zertifikat des KDC zu einer vertrauenswürdigen Stammzertifizierungsstelle erstellt wird, und dann wird der öffentliche Schlüssel des KDC verwendet, um die Antwortsignatur zu überprüfen.

16. Nachdem ein TGT abgerufen wurde, erhält der Client ein Dienstticket für den lokalen Computer, um sich am Computer anzumelden.

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

18. Nachdem das Benutzerprofil geladen wurde, übernimmt CertPropSvc dieses Ereignis, liest die Zertifikate aus dem Karte (einschließlich der Stammzertifikate) und füllt sie dann im Zertifikatspeicher des Benutzers (MYSTORE) auf.

19. Die Kommunikation zwischen CSP und Smart Karte Resource Manager erfolgt im LRPC-Kanal.

20. Bei erfolgreicher Authentifizierung werden Zertifikate asynchron vom Certificate Propagation Service (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, bleiben aber der Zertifikatspeicher des Benutzers (MYSTORE).

Hinweis

Eine SID ist ein Sicherheitsbezeichner, der für jeden Benutzer oder jede Gruppe erstellt wird, zu dem Zeitpunkt, zu dem ein Benutzerkonto oder ein Gruppenkonto in der lokalen Sicherheitskontodatenbank 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 Funktionsweise des Kerberos-Authentifizierungsprotokolls der Version 5 (https://go.microsoft.com/fwlink/?LinkID=27175).

Standardmäßig überprüft der KDC, ob das Zertifikat des Clients die Smartcard-Clientauthentifizierungs-EKU szOID_KP_SMARTCARD_LOGON enthält. Es gibt jedoch eine Richtlinie, die es dem KDC ermöglicht, die SC-LOGON-EKU nicht erforderlich zu machen (SCLogonEKUNotRequired – siehe Tabelle 7). Die 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)

Je nach Konfiguration des Domänencontrollers wird eines dieser Arten von Zertifikaten als Teil des AS_REP-Pakets gesendet. Weitere Informationen zu Zertifikatvorlagen finden Sie unter Active Directory-Zertifikatservererweiterungen in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=83212).

Clientzertifikatzuordnungen

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

SSL/TLS kann Zertifikate ohne SAN zuordnen, und die Zuordnung erfolgt mithilfe der AltSecID-Attribute für Clientkonten. Die von der SSL/TLS-Clientauthentifizierung verwendete X509 AltSecID hat das Format "X509:<I>"<Ausstellername>"<S>"<Antragstellername>. Hier werden der <Ausstellername> und <der Antragstellername> 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 vom KDC unterstützt. Das KDC unterstützt auch sechs weitere Zuordnungsmethoden. Die folgende Abbildung zeigt einen Ablauf der Von KDC verwendeten Benutzerkontenzuordnungslogik.

Abbildung 20 Allgemeiner Ablauf der Zertifikatverarbeitung für die Anmeldung

Das Zertifikatobjekt wird analysiert, um nach bestimmten Inhalten zu suchen, um die Benutzerkontozuordnung durchzuführen. Wenn auch ein Benutzername mit dem Zertifikat angegeben wird, wird der Benutzername verwendet, um das Kontoobjekt zu suchen. Dieser Vorgang ist der schnellste, da der Zeichenfolgenabgleich erfolgt. 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 standardmäßig die lokale Domäne verwendet. Wenn eine andere Domäne für die Suche verwendet werden soll, sollte ein Domänennamehinweis angegeben werden, um die Zuordnung und Bindung durchzuführen. Eine Zuordnung basierend auf generischen Attributen ist nicht möglich, da es keine generische API zum Abrufen von Attributen aus einem Zertifikat gibt.

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

Weitere Informationen zum Zuordnen von Zertifikaten zu Benutzerkonten finden Sie unter Bereitstellen einer Public Key-Infrastruktur (https://go.microsoft.com/fwlink/?LinkId=93737).

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

Abbildung 21 Zertifikatverarbeitungslogik

Smart Karte Anmeldung eines einzelnen Benutzers mit einem Zertifikat in mehreren Konten

Ein einzelnes Benutzerzertifikat kann mehreren Konten zugeordnet werden. Beispielsweise kann sich ein Benutzer 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 über einen anderen Benutzernamen verfügt, wird empfohlen, die X509Hints Gruppenrichtlinie Object zu aktivieren, um die Benutzerinformationen bereitzustellen, für die er sich anmelden möchte.

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

1. Wenn im Zertifikat kein UPN vorhanden ist:
   1. Die Anmeldung kann in der lokalen Gesamtstruktur oder in einer anderen Gesamtstruktur erfolgen, wenn sich ein einzelner Benutzer mit einem Zertifikat bei verschiedenen Konten anmelden muss.
   2. Ein Hinweis muss angegeben werden, wenn die Zuordnung nicht eindeutig ist (mehr als ein Benutzer, der demselben Zertifikat zugeordnet ist).
2. Wenn im Zertifikat ein UPN 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 den Benutzer in anderen Gesamtstrukturen anmelden zu können, muss dem Benutzer ein X509-Hinweis bereitgestellt werden.

Smart Karte Anmeldung mehrerer Benutzer in einem einzigen Konto

Eine Gruppe von Benutzern kann sich bei einem einzelnen Konto anmelden (z. B. bei einem Administratorkonto). Für dieses Konto werden Benutzerzertifikate zugeordnet, sodass 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 aufweisen). 

Wenn Certificate1 beispielsweise CN=CNName1, Certificate2 CN=User1 und Certificate3 CN=User2 aufweist, kann die AltSecID dieser Zertifikate mithilfe der Zuordnung von Active Directory-Benutzern und -Computern einem einzelnen Konto zugeordnet werden.

Intelligente Karte-Anmeldung über Gesamtstrukturen hinweg

Damit die Kontozuordnung gesamtstrukturübergreifend funktioniert, insbesondere in Fällen, in denen nicht genügend Informationen im Zertifikat verfügbar sind, gibt der Benutzer möglicherweise einen Hinweis ein (in Form eines Benutzernamens wie Domäne\Benutzer oder eines vollqualifizierten UPN wie User@DNSNameOfDomain.com).

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 der Anmeldebenutzeroberfläche mit dem PIN-Feld zu aktivieren (siehe Tabelle 7).

OCSP-Unterstützung für PKINIT

Online Certificate Status Protocol (OCSP), das in RFC 2560 definiert ist, ermöglicht es Anwendungen, rechtzeitig Informationen über die Sperrung eines Zertifikats status abzurufen. Da OCSP-Antworten klein und gut begrenzt sind, möchten eingeschränkte Clients möglicherweise OCSP verwenden, um die Gültigkeit der Zertifikate für Kerberos KDC zu überprüfen, um die Übertragung großer Zertifikatsperrlisten (Certificate Revocation Lists, CRLs) zu vermeiden und Bandbreite in eingeschränkten Netzwerken zu sparen.

Das KDC von Microsoft versucht immer, die OCSP-Antworten abzurufen und zu verwenden, wenn verfügbar. Es gibt keine Richtlinie, die verwendet werden kann, um dies zu deaktivieren. CAPI2-APIs für OCSP zwischenspeichern OCSP-Antworten und die status der Antworten. KDC unterstützt nur OCSP-Antwort für Signaturzertifikate.

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.

Zertifikatsperrungsunterstützung

In Tabelle 12 sind die Schlüssel und die entsprechenden Werte aufgeführt, um die CRL-Überprüfung (an der Leitung) am KDC oder Client zu deaktivieren. Beide Einstellungen sind erforderlich.

Tabelle 12: Überprüfen 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

Smart Karte Stammzertifikatanforderungen für die Verwendung mit Domänenbeitritt

Es gibt einige spezifische Bedingungen, die das Smart Karte-Zertifikat erfüllen muss, damit eine intelligente Karte-basierte Domänenbeitritt funktioniert.

• Smart Karte Zertifikat muss ein Betrefffeld enthalten, das den DNS-Domänennamen im DN enthält. Wenn dies nicht der Fall ist, schlägt die Auflösung in der entsprechenden Domäne fehl, und die TS- und Domänenbeitritte mit Smartcard schlagen fehl.

oder

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

Die Problemumgehung besteht darin, einen Hinweis (aktiviert über die Gruppenrichtlinienobjekteinstellung X509HintsNeeded, wie in Tabelle 7 angegeben) in der Benutzeroberfläche der Anmeldeinformationen für den Domänenbeitritt bereitzustellen.

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

Um Stammzertifikate auf smarten Karte für die aktuell eingebundene Domäne bereitzustellen, können Sie den folgenden Befehl verwenden:

certutil –scroots

Terminaldienste und Smartcards

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

Smart Karte Unterstützung für Terminaldienste ist erforderlich, um viele Szenarien zu ermöglichen. Dazu zählen unter anderem folgende Einstellungen:

• Möglichkeit zum RAS in einer Umgebung mit schnellem Benutzerwechsel (oder remote mithilfe von Terminaldiensten). Ein Benutzer kann keine umgeleitete Smartcard-basierte RAS-Verbindung herstellen. Das heißt, der Verbindungsversuch ist bei einem schnellen Benutzerwechsel oder aus einer Terminaldienstesitzung nicht erfolgreich.
• EFS ist nicht in der Lage, den Intelligenten Karte leser des Benutzers aus dem LSA-Prozess in fast user switching oder in einer Terminal Services-Sitzung zu finden. Daher kann EFS Benutzerdateien nicht entschlüsseln.

Terminalserverumleitung

In einem Terminalserverszenario verwendet ein Benutzer einen Remoteserver zum Ausführen von Diensten. Die intelligente Karte ist jedoch lokal für das System, das der Benutzer verwendet. In einem Szenario mit intelligenter Karte Anmeldung spricht der Smart Karte-Dienst des Remoteservers (SCardSvr.exe oder SVCHost.exe) entsprechend an den Smart Karte Leser, der mit dem Remotesystem verbunden ist, von dem aus der Benutzer sich anmelden möchte.

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 net use /smart Karte aus.
2. Die Pfeile stellen den Ablauf der PIN dar, die der Benutzer vom Eingabeaufforderungsprozess cmd.exe zum intelligenten Karte des Benutzers in einem Leser eingibt, der an den Terminaldienste-Clientcomputer angeschlossen ist.
3. Die Authentifizierungsarbeit wird vom LSA in Sitzung 0 ausgeführt.
4. Die Krypto-API-Arbeit wird in der LSA (lsass.exe) ausgeführt. Dies ist möglich, da rdpdr.sys den Kontext pro Sitzung statt pro Prozess zulässt.
5. Die WinScard - und SCRedir-Komponenten , die vor Vista eng gekoppelt, aber separate Module waren, werden jetzt in einem Modul eingeführt. Die ScHelper-Bibliothek ist ein Kerberos-spezifischer Crypto-API-Wrapper.
6. Die Umleitungsentscheidung wird basierend auf der Sitzung des Threads, die den SCardEstablishContext-Aufruf ausführt, auf einer intelligenten Karte Kontextbasis getroffen.
7. Änderungen an WinSCard.dll Implementierung wurden in Vista vorgenommen, um eine intelligente Karte Umleitung zu ermöglichen.

Einmaliges Anmelden für Terminalserver

Im Rahmen der Common Criteria (CC)-Konformität muss der MSTSC-Client konfigurierbar sein, um das Kennwort oder die smarte Karte PIN des Benutzers mithilfe des Anmeldeinformations-Managers zu erhalten und zu speichern. CC erfordert, dass Anwendungen keinen direkten Zugriff auf das Kennwort oder die PIN des Benutzers haben.

CC erfordert insbesondere, dass das Kennwort/die PIN den LSA niemals im Klaren bleibt. Auf ein verteiltes Szenario angewendet, sollte es dem Kennwort/der PIN erlauben, zwischen einem vertrauenswürdigen LSA und einem anderen zu wechseln, solange es während der Übertragung nicht eindeutig ist.

In der Windows Vista-Terminaldienste-Lösung zum einmaligen Anmelden müssen sich Benutzer bei Verwendung eines intelligenten Karte für jede neue Terminaldienstesitzung anmelden (keine SSO-Unterstützung). Der Benutzer wird jedoch nicht mehrmals zur Eingabe einer PIN aufgefordert, um eine Terminaldienstesitzung einzurichten. Nachdem der Benutzer beispielsweise doppelt auf ein Microsoft Word-Dokumentsymbol geklickt hat, das sich auf einem Remotecomputer befindet, wird der Benutzer zur Eingabe einer PIN aufgefordert. Diese PIN wird über einen sicheren Kanal übergeben, den der Anmeldeinformations-SSP eingerichtet hat. Die PIN wird über den sicheren Kanal zurück an den Terminaldienste-Client weitergeleitet und an Winlogon übergeben, und dem Benutzer wird keine zusätzliche Benutzeroberfläche angezeigt (keine zusätzlichen Eingabeaufforderungen für die PIN, es sei denn, die PIN ist falsch oder es gibt Smart Karte-bezogene Fehler).

Terminaldienste und Smart Karte Anmeldung

Der Zweck dieser Funktion besteht darin, Benutzern die Anmeldung mit einem intelligenten Karte zu ermöglichen, indem sie eine PIN auf der Clientseite der Terminaldienste eingeben und sie auf eine Weise an den Server übergeben, die der Authentifizierung basierend auf Benutzername und Kennwort ähnelt.

Smart Karte Anmeldung mit Terminaldiensten wurde erstmals in Windows XP eingeführt. Es ist in keinem früheren Release verfügbar. In Windows XP konnte sich der Benutzer nur mit einem Zertifikat aus dem Standardcontainer anmelden.

Hinweis

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

Zusätzlich zum Aktivieren der erforderlichen Gruppenrichtlinien müssen für Terminaldienste spezifische Richtlinien für intelligente Karte-basierte Anmeldung aktiviert werden.

Um intelligente Karte Anmeldung bei einem Terminaldienstserver 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"

Domänenübergreifende Anmeldung von Terminaldiensten und smarten Karte

Szenario: RAS in Unternehmen

Um dieses Szenario zu aktivieren, muss das Stammzertifikat für die Domäne auf der intelligenten Karte bereitgestellt werden. Um dies auf dem intelligenten Karte von einem in die Domäne eingebundenen Computer bereitzustellen, führen Sie an der Befehlszeile Folgendes aus:

certutil –scroots update

Bei domänenübergreifenden Terminaldiensten muss das KDC-Zertifikat des Terminaldienste-Servercomputers auch im NTAUTH-Speicher des Clientcomputers vorhanden sein. Führen Sie zum Hinzufügen des Speichers an der Befehlszeile Folgendes aus:

certutil –addstore –enterprise NTAUTH<CertFile>

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

Hinweis

Wenn Sie den Anmeldeinformations-SSP unter Windows Vista verwenden, um sich mit einem intelligenten Karte von einem Computer ohne Domänenbeigetreten zu melden, muss die intelligente Karte die Stammzertifizierung des Domänencontrollers enthalten. Ohne die Stammzertifizierung des Domänencontrollers kann kein sicherer PKI-Kanal eingerichtet werden.

Die Anmeldung domänenübergreifender Terminaldienste funktioniert nur, wenn der UPN im Zertifikat die folgende Form verwendet: <Something>@<DomainDNSName>

Der UPN im Zertifikat muss eine echte Domäne enthalten, die aufgelöst werden kann. Andernfalls hat Kerberos keine Ahnung, wo es hingehen soll. Die Aktivierung von GPO X509-Domänenhinweisen ist ein Weg, dies zu umgehen. Weitere Informationen zu dieser Einstellung finden Sie in Tabelle 7.

Einstellungen für Terminaldienste und smarte Karte anmeldung Gruppenrichtlinie

Windows erzwingt die Einstellungen für intelligente Karte Anmeldung bei Terminaldiensten, nachdem der Anmeldeinformations-SSP und die lokale Sicherheitsrichtlinie (festgelegt mit secpol.msc) erzwungen wurden.

Tabelle 13: Einstellungen für Terminaldienste und smarte Karte Anmeldung Gruppenrichtlinie

Richtlinie	Einstellung
Smart Karte Anmeldung ist die einzige unterstützte Anmeldemethode.	HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation Wertname: AllowFreshCredentials Werttyp: Binär Werteinstellung: 1
Der Benutzer verfügt außerdem über ein entsprechendes Kennwort-aktiviertes Konto.	HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\CredentialsDelegation Wertname: AllowFreshCredentialsWhenNTLMOnly Werttyp: Binär Werteinstellung: 1

Wenn Sie Terminaldienste mit smarter Karte 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.

Debug- und Entwicklerinformationen

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

Certutil

Auflisten von Zertifikaten, die auf der intelligenten Karte

Befehl zum Auflisten von Zertifikaten, die auf der intelligenten Karte 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 darin besteht, die öffentlichen Zertifikate auf der Karte zu lesen.

Löschen von Zertifikaten im intelligenten Karte

Wenn Sie ein Zertifikat auf der Karte löschen, löschen Sie tatsächlich einen Container, der diesem Zertifikat entspricht. Jedes Zertifikat ist in einem 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 einem intelligenten Karte finden Sie unter Smartcard-Stammzertifikatanforderungen für Benutzer mit Domänenbeitritt.

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

Kerberos-Debuggen und Ablaufverfolgung

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

• Behandeln von Kerberos-Fehlern (https://go.microsoft.com/fwlink/?LinkId=93730).
• Problembehandlung bei der Kerberos-Delegierung (https://go.microsoft.com/fwlink/?LinkId=93731).
• Das Tool "Ablaufverfolgungsprotokoll" im Windows 2000 Resource Kit (https://go.microsoft.com/fwlink/?LinkId=93732) ist ein Hilfsprogramm, mit dem Sie Kerberos-Authentifizierungsfehler debuggen können.

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

NTLM

Führen Sie an der Befehlszeile Folgendes aus, um die Ablaufverfolgung für die NTLM-Authentifizierung zu aktivieren:

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

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

tracelog -stop ntlm

Kerberos

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

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

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

tracelog.exe-Stop-Bordstein

KDC

Führen Sie in der Befehlszeile Folgendes aus, um die Ablaufverfolgung für das KDC zu aktivieren:

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

Führen Sie an der Befehlszeile Folgendes aus, um die Ablaufverfolgung für das KDC zu beenden:

tracelog.exe -stop kdc

Hinweis

Um die Ablaufverfolgung remote zu beenden, führen Sie an der Befehlszeile folgendes 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 Einstellungen für die Kerberos-Ablaufverfolgungsregistrierung

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. Wenn Sie andernfalls die in Tabelle 13 angezeigten Registrierungsdateien verwendet haben, suchen Sie an den folgenden Speicherorten nach den generierten Ablaufverfolgungsprotokolldateien:

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

Zum Decodieren von Ereignisablaufverfolgungsdateien können Sie Tracefmt (tracefmt.exe) verwenden. Tracefmt ist ein Befehlszeilentool, das Ablaufverfolgungsmeldungen 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 auf MSDN (https://go.microsoft.com/fwlink/?LinkId=93734).

Smart Karte-Dienst

So überprüfen Sie, ob der Smart Karte-Dienst ausgeführt wird

1. Drücken Sie STRG+ALT+ENTF, 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 , ob der Dienst ausgeführt oder beendet wird.

So starten Sie den Smart Karte-Dienst 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 net stop SCardSvr ein.

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

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

sc queryex scardsvr

Es folgt eine Beispielausgabe aus der Ausführung dieses Befehls:

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 Smart Karte Reader verbunden ist 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 Smart Karte Reader, wählen Sie den intelligenten Karte Reader aus, zu dem Sie Informationen benötigen, und klicken Sie dann auf Eigenschaften.

   Hinweis

   Wenn der Leser für intelligente Karte nicht in Geräte-Manager aufgeführt ist, klicken Sie im Menü Aktion auf Nach Hardwareänderungen überprüfen.

CAPI2-Diagnose

CAPI2-Diagnose ist ein Feature in Windows Vista und Windows Server 2008, das Administratoren bei der Problembehandlung von PKI-Problemen unterstützt. CAPI2-Diagnose protokolliert Ereignisse im Windows-Ereignisprotokoll, das detaillierte Informationen zur Zertifikatkettenüberprüfung, Zertifikatspeichervorgängen und Signaturüberprüfung enthält. Diese Informationen erleichtern die Identifizierung der Grundursachen von Problemen und reduzieren die Zeit, die für die Diagnose benötigt wird.

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

Referenzen

1. Alias "Fragen zum Anmeldeinformationsanbieter" – credprov@microsoft.com
2. Technische Referenz zum Anmeldeinformationsanbieter (https://go.microsoft.com/fwlink/?LinkId=93340)
3. Dokumentation zum Windows Vista SDK (https://go.microsoft.com/fwlink/?LinkId=93342)
4. Microsoft Base SmartCard Cryptographic Service Provider (Base CSP) für Windows 2000, 2003 und XP (https://go.microsoft.com/fwlink/?LinkId=93341)
5. SmartCard Mini driver Specification (https://go.microsoft.com/fwlink/?LinkId=93343)
6. Dokumentation zu SmartCard Mini Driver (Kartenmodul) API und Headerdatei auf MSDN (https://go.microsoft.com/fwlink/?LinkId=18885); Feedbackalias: CardMod@microsoft.com ; Headerdateidownload als Teil des CNG SDK verfügbar (https://go.microsoft.com/fwlink/?LinkId=93344)
7. Smartcard-Zertifizierungsanforderungen (https://go.microsoft.com/fwlink/?LinkId=93345)
8. PC/SC Workgroup (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. Unternehmens-Smartcardbereitstellung 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 unter Windows Vista (https://go.microsoft.com/fwlink/?LinkId=89570)
15. RFC 4556: Kryptografie mit öffentlichem Schlüssel für die Erstauthentifizierung in Kerberos (PKINIT) (https://go.microsoft.com/fwlink/?LinkId=93352)
16. Active Directory-Zertifikatservererweiterungen in Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=83212)
17. SmartCard Infrastructure Blog, für aktuelle Informationen und Feedback (https://go.microsoft.com/fwlink/?LinkId=96591)