Zertifikatanforderungen und Enumeration

• Gilt für::

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

In diesem Thema für IT-Experten und Smartcardentwickler wird beschrieben, wie Zertifikate für die Smartcardanmeldung verwaltet und verwendet werden.

Wenn eine Smartcard 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 Smartcard-Ressourcen-Manager-Datenbank sucht nach dem Kryptografiedienstanbieter (Cryptographic Service Provider, CSP) der Smartcard.

2. Ein qualifizierter Containername wird mit dem Namen des Smartcardlesers erstellt und an den CSP übergeben. Das Format ist \\.<Reader name>\

3. CryptAcquireContext wird aufgerufen, um einen Kontext für den Standardcontainer abzurufen. Wenn ein Fehler auftritt, ist die Smartcard für die Smartcardanmeldung nicht verwendbar.

4. Der Name des Containers wird mithilfe des parameters PP_CONTAINER mit CryptGetProvParam abgerufen.

5. Mithilfe des in Schritt 3 abgerufenen Kontexts wird der CSP nach dem parameter PP_USER_CERTSTORE abgefragt. Weitere Informationen finden Sie unter Smartcardarchitektur. Wenn der Vorgang erfolgreich ist, wird der Name eines Zertifikatspeichers zurückgegeben, und der Programmablauf wird mit Schritt 8 übersprungen.

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 Speicherzertifikatspeicher 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 gültig sein, basierend auf der Computersystemuhr (nicht abgelaufen oder mit einem zukünftigen Datum gültig).
   2. Das Zertifikat darf sich nicht im AT_SIGNATURE Teil eines Containers befinden.
   3. Das Zertifikat muss über einen gültigen Benutzerprinzipalnamen (UPN) verfügen.
   4. Das Zertifikat muss über die Verwendung des Schlüssels für die digitale Signatur verfügen.
   5. Das Zertifikat muss über die Smartcard-Anmelde-EKU verfügen.

   Jedes Zertifikat, das diese Anforderungen erfüllt, wird dem Benutzer mit dem UPN des Zertifikats (oder der E-Mail-Adresse oder dem Betreff, abhängig vom Vorhandensein der Zertifikaterweiterungen) angezeigt.

9. Der Prozess wählt dann ein Zertifikat aus, und die PIN wird eingegeben.

10. LogonUI.exe packt die Informationen und sendet sie an Lsass.exe, um den Anmeldeversuch zu verarbeiten.

11. Wenn erfolgreich, LogonUI.exe wird geschlossen. Dadurch wird der in Schritt 3 abgerufene Kontext freigegeben.

Smartcard-Anmeldeflow in Windows

Die meisten Probleme während der Authentifizierung treten aufgrund von Änderungen des Sitzungsverhaltens auf. Wenn Änderungen auftreten, ruft die lokale Sicherheitsbehörde (LSA) den Sitzungskontext nicht erneut ab. Die Sitzungsänderung wird stattdessen vom Kryptografiedienstanbieter verarbeitet.

Clientzertifikate, die keinen UPN im subjectAltName Feld (SAN) des Zertifikats enthalten, können für die Anmeldung aktiviert werden. Dies unterstützt eine größere Vielfalt von Zertifikaten und unterstützt mehrere Anmeldezertifikate auf derselben Karte.

Die Unterstützung für mehrere Zertifikate auf derselben Karte ist standardmäßig aktiviert. Neue Zertifikattypen müssen über Gruppenrichtlinien aktiviert werden.

Wenn Sie die Richtlinie Signaturschlüssel zulassen aktivieren, die für Anmeldeinformationsanbieter gültig sind, werden alle Zertifikate, die auf der Smartcard mit einem reinen Signaturschlüssel verfügbar sind, auf dem Anmeldebildschirm aufgeführt. Auf diese Weise können Benutzer ihre Anmeldeoberfläche auswählen. Wenn die Richtlinie deaktiviert oder nicht konfiguriert ist, werden smartcard-signaturschlüsselbasierte Zertifikate nicht auf dem Anmeldebildschirm aufgeführt.

Das folgende Diagramm veranschaulicht, wie die Smartcardanmeldung in den unterstützten Versionen von Windows funktioniert.

Smartcard-Anmeldeflow

Im Folgenden werden die Schritte aufgeführt, die während einer Smartcardanmeldung ausgeführt werden:

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

2. Der Smartcard-Ressourcen-Manager wird asynchron gestartet, und der Smartcard-Anmeldeinformationsanbieter führt Folgendes aus:

   1. Ruft Anmeldeinformationen ab (eine Liste bekannter Anmeldeinformationen oder, wenn keine Anmeldeinformationen vorhanden sind, informationen zum Smartcardleser, die Von Windows erkannt wurden)
   2. Ruft eine Liste der Smartcardleser (mithilfe der WinSCard-API) und die Liste der in die einzelnen Smartcards eingefügten Smartcards ab.
   3. Listet jede Karte auf, um zu überprüfen, ob ein Anmeldezertifikat vorhanden ist, das von der Gruppenrichtlinie gesteuert wird. Wenn das Zertifikat vorhanden ist, kopiert der Smartcard-Anmeldeinformationsanbieter es in einen temporären, sicheren Cache auf dem Computer oder Terminal.

   Hinweis

   Smartcard-Cacheeinträge werden für Zertifikate mit einem Antragstellernamen oder einem Antragstellerschlüsselbezeichner erstellt. Wenn das Zertifikat über einen Antragstellernamen verfügt, wird es mit einem Index gespeichert, der auf dem Antragstellernamen und dem Zertifikataussteller basiert. Wenn ein anderes Zertifikat mit demselben Antragstellernamen und Zertifikataussteller verwendet wird, ersetzt es den vorhandenen zwischengespeicherten Eintrag. Eine Änderung dieses Verhaltens ermöglicht die Bedingung, wenn das Zertifikat keinen Antragstellernamen hat, der Cache mit einem Index erstellt wird, der auf dem Antragstellerschlüsselbezeichner und Zertifikataussteller basiert. Wenn ein anderes Zertifikat über denselben Antragstellerschlüsselbezeichner und Zertifikataussteller verfügt, wird der Cacheeintrag ersetzt. Wenn Zertifikate weder einen Antragstellernamen noch einen Antragstellerschlüsselbezeichner haben, wird kein zwischengespeicherter Eintrag erstellt.

   1. Benachrichtigt die Anmeldebenutzeroberfläche, dass sie über neue Anmeldeinformationen verfügt.

3. Die Anmeldebenutzeroberfläche fordert die neuen Anmeldeinformationen vom Smartcard-Anmeldeinformationsanbieter an. Als Antwort stellt der Smartcard-Anmeldeinformationsanbieter jedes Anmeldezertifikat für die Anmeldebenutzeroberfläche bereit, und die entsprechenden Anmeldekacheln werden angezeigt. Der Benutzer wählt eine Kachel mit smartcardbasiertem Anmeldezertifikat aus, und Windows zeigt ein PIN-Dialogfeld an.

4. Der Benutzer gibt die PIN ein und drückt dann die EINGABETASTE. Der Smartcard-Anmeldeinformationsanbieter verschlüsselt die PIN.

5. Der Anmeldeinformationsanbieter, der sich im LogonUI-System befindet, sammelt die PIN. Im Rahmen des Packens von Anmeldeinformationen im Smartcard-Anmeldeinformationsanbieter werden die Daten in einer KERB_CERTIFICATE_LOGON-Struktur gepackt. Der Hauptinhalt der KERB_CERTIFICATE_LOGON-Struktur sind die Smartcard-PIN, CSP-Daten (z. B. Lesername und Containername), Benutzername und Domänenname. Der Benutzername ist erforderlich, wenn sich die Anmeldedomäne nicht in derselben Gesamtstruktur befindet, da er das Zuordnen eines Zertifikats zu mehreren Benutzerkonten ermöglicht.

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

7. Winlogon stellt die Daten von LogonUI an die LSA mit den Benutzerinformationen in LSALogonUser dar.

8. LSA ruft das Kerberos-Authentifizierungspaket (Kerberos SSP) auf, um eine Kerberos-Authentifizierungsdienstanforderung (KRB_AS_REQ) zu erstellen, die einen Vorauthentifizierungsator enthält (wie in RFC 4556: Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)) angegeben).

   Wenn die Authentifizierung mithilfe eines Zertifikats erfolgt, das eine digitale Signatur verwendet, bestehen die Vorauthentifizierungsdaten aus dem öffentlichen Zertifikat des Benutzers und dem Zertifikat, das digital mit dem entsprechenden privaten Schlüssel signiert ist.

   Wenn die Authentifizierung mithilfe eines Zertifikats erfolgt, das die Schlüsselverschlüsselung verwendet, bestehen die Vorauthentifizierungsdaten aus dem öffentlichen Zertifikat des Benutzers und dem Zertifikat, das mit dem entsprechenden privaten Schlüssel verschlüsselt ist.

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 durchgeführt. Da der private Schlüssel in diesem Fall in einer Smartcard gespeichert wird, wird das Smartcardsubsystem aufgerufen, und der erforderliche Vorgang wird abgeschlossen. Das Ergebnis wird an den Kerberos-Sicherheitssupportanbieter (SSP) zurückgesendet.

10. Der Kerberos-SSP sendet eine Authentifizierungsanforderung für ein Ticket-Granting-Ticket (TGT) (gemäß RFC 4556) an den Schlüsselverteilungscenterdienst (Key Distribution Center, KDC), der auf einem Domänencontroller ausgeführt wird.

11. Das KDC sucht das Kontoobjekt des Benutzers in Active Directory Domain Services (AD DS), wie unter Clientzertifikatanforderungen und Zuordnungen beschrieben, und verwendet das Zertifikat des Benutzers, um die Signatur zu überprüfen.

12. Das KDC überprüft das Zertifikat des Benutzers (Uhrzeit, Pfad und Sperrstatus), um sicherzustellen, dass das Zertifikat aus einer vertrauenswürdigen Quelle stammt. Das KDC verwendet CryptoAPI, um einen Zertifizierungspfad vom Zertifikat des Benutzers zu einem Zertifikat der Stammzertifizierungsstelle (Ca) zu erstellen, das sich im Stammspeicher auf dem Domänencontroller befindet. Der KDC verwendet dann CryptoAPI, um die digitale Signatur auf dem signierten Authentifikator zu überprüfen, der in den Vorauthentifizierungsdatenfeldern 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 AD DS ab. Das KDC erstellt ein TGT, das auf den Benutzerkontoinformationen basiert, die es aus AD DS abruft. Die Autorisierungsdatenfelder des TGT enthalten die Sicherheits-ID (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.

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

    Hinweis

    Das KRB_AS_REP Paket besteht aus:

    • Berechtigungsattributzertifikat (PAC)
    • SID des Benutzers
    • SIDs aller Gruppen, deren Mitglied der Benutzer ist
    • Eine Anforderung für ticket-granting service (TGS)
    • Vorauthentifizierungsdaten

    TGT wird mit dem Hauptschlüssel des KDC verschlüsselt, und der Sitzungsschlüssel wird mit einem temporären Schlüssel verschlüsselt. Dieser temporäre Schlüssel wird basierend auf RFC 4556 abgeleitet. Mit CryptoAPI wird der temporäre Schlüssel entschlüsselt. Wenn sich der private Schlüssel auf einer Smartcard befindet, wird im Rahmen des Entschlüsselungsprozesses ein Aufruf an das Smartcardsubsystem ausgeführt, indem der angegebene CSP verwendet wird, um das Zertifikat zu extrahieren, das dem öffentlichen Schlüssel des Benutzers entspricht. (Programmgesteuerte Aufrufe für das Zertifikat umfassen CryptAcquireContext, CryptSetProvParam mit der PIN, CryptgetUserKey und CryptGetKeyParam.) 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 (Uhrzeit, Pfad und Sperrstatus). Zunächst wird die Signatur des KDC überprüft, indem ein Zertifizierungspfad vom Zertifikat des KDC zu einer vertrauenswürdigen Stammzertifizierungsstelle erstellt wird. Anschließend 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, das für die Anmeldung beim lokalen Computer verwendet wird.

17. Bei Erfolg speichert LSA die Tickets und gibt eine Erfolgsmeldung an LSALogonUser zurück. Nachdem diese Erfolgsmeldung ausgegeben wurde, wird das Benutzerprofil für das Gerät ausgewählt und festgelegt, die Gruppenrichtlinienaktualisierung wird instanziiert, und andere Aktionen werden ausgeführt.

18. Nachdem das Benutzerprofil geladen wurde, erkennt der Certification Propagation Service (CertPropSvc) dieses Ereignis, liest die Zertifikate von der Smartcard (einschließlich der Stammzertifikate) und füllt sie dann im Zertifikatspeicher des Benutzers (MYSTORE) auf.

19. Die Kommunikation zwischen CSP und Smartcard-Ressourcen-Manager erfolgt im LRPC-Kanal.

20. Bei erfolgreicher Authentifizierung werden Zertifikate vom Zertifikatverteilungsdienst (CertPropSvc) asynchron an den Speicher des Benutzers 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, verbleiben jedoch im Zertifikatspeicher des Benutzers.

Hinweis

Eine SID wird für jeden Benutzer oder jede Gruppe zum Zeitpunkt der Erstellung eines Benutzerkontos oder eines Gruppenkontos in der lokalen Sicherheitskontodatenbank oder in AD DS erstellt. Die SID ändert sich nie, auch wenn das Benutzer- oder Gruppenkonto umbenannt wird.

Weitere Informationen zum Kerberos-Protokoll finden Sie unter Microsoft Kerberos.

Standardmäßig überprüft der KDC, ob das Zertifikat des Clients die EKU für die Smartcardclientauthentifizierung szOID_KP_SMARTCARD_LOGON enthält. Wenn diese Option aktiviert ist, ermöglicht die Gruppenrichtlinieneinstellung Zertifikate ohne Zertifikatsattribut der erweiterten Schlüsselverwendung zulassen , dass der KDC die SC-LOGON-EKU nicht erfordert. SC-LOGON EKU ist für Kontozuordnungen, die auf dem öffentlichen Schlüssel basieren, nicht erforderlich.

KDC-Zertifikat

Active Directory-Zertifikatdienste bieten drei Arten von Zertifikatvorlagen:

• Domänencontroller
• Domänencontrollerauthentifizierung
• Kerberos-Authentifizierung

Abhängig von der Konfiguration des Domänencontrollers wird eines dieser Arten von Zertifikaten als Teil des AS_REP Pakets gesendet.

Anforderungen und Zuordnungen für Clientzertifikate

Die Zertifikatanforderungen werden nach Versionen des Windows-Betriebssystems aufgeführt. Zertifikatzuordnung beschreibt, wie Informationen aus dem Zertifikat dem Benutzerkonto zugeordnet werden.

Zertifikatanforderungen

Komponente	Anforderungen
Speicherort des CRL-Verteilungspunkts	Nicht erforderlich
Schlüsselverwendung	Digitale Signatur
Grundlegende Einschränkungen	Nicht erforderlich
Erweiterte Schlüsselverwendung (EKU)	Der Smartcard-Anmeldeobjektbezeichner ist nicht erforderlich. Anmerkung Wenn eine EKU vorhanden ist, muss sie die Smartcard-Anmelde-EKU enthalten. Zertifikate ohne EKU können für die Anmeldung verwendet werden.
Alternativer Antragstellername	Für die Smartcardanmeldung ist keine E-Mail-ID erforderlich.
Antragsteller	Nicht erforderlich
Schlüsselaustausch (AT_KEYEXCHANGE Feld)	Nicht erforderlich für Smartcard-Anmeldezertifikate, wenn eine Gruppenrichtlinieneinstellung aktiviert ist. (Gruppenrichtlinieneinstellungen sind standardmäßig nicht aktiviert.)
ZERTIFIKATSPERRLISTE	Nicht erforderlich
UPN	Nicht erforderlich
Anmerkungen	Sie können aktivieren, dass jedes Zertifikat für den Anmeldeinformationsanbieter der Smartcard sichtbar ist.

Clientzertifikatzuordnungen

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

SSL/TLS kann Zertifikate ohne SAN zuordnen, und die Zuordnung erfolgt mithilfe der AltSecID-Attribute für Clientkonten. Die X509 AltSecID, die von der SSL/TLS-Clientauthentifizierung verwendet wird, hat das Format "X509: <Issuer Name><Subject Name. Und <Issuer Name><Subject Name> werden aus dem Clientzertifikat übernommen, wobei "\r" und "\n" durch "," ersetzt werden.

Verteilungspunkte der Zertifikatsperrliste

UPN im Feld "Alternativer Antragstellername"

Felder "Betreff" und "Aussteller"

Diese Kontozuordnung wird vom KDC zusätzlich zu sechs anderen Zuordnungsmethoden unterstützt. Die folgende Abbildung veranschaulicht einen Fluss der Benutzerkontenzuordnungslogik, die vom KDC verwendet wird.

Allgemeiner Ablauf der Zertifikatverarbeitung für die Anmeldung

Das Zertifikatobjekt wird analysiert, um nach Inhalten für die Benutzerkontozuordnung zu suchen.

• Wenn ein Benutzername mit dem Zertifikat angegeben wird, wird der Benutzername verwendet, um das Kontoobjekt zu suchen. Dieser Vorgang ist am schnellsten, da der Zeichenfolgenabgleich erfolgt.
• Wenn nur das Zertifikatobjekt angegeben wird, werden mehrere Vorgänge ausgeführt, um den Benutzernamen zu finden, um den Benutzernamen einem Kontoobjekt zuzuordnen.
• Wenn für die Authentifizierung keine Domäneninformationen 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 bereitgestellt 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 beendet die erste Methode, die ein Konto findet, die Suche erfolgreich. Ein Konfigurationsfehler tritt jedoch auf, wenn zwei Methoden unterschiedlichen Benutzerkonten dasselbe Zertifikat zuordnen, wenn der Client den Clientnamen nicht über die Zuordnungshinweise angibt.

Die folgende Abbildung veranschaulicht den Prozess der Zuordnung von Benutzerkonten für die Anmeldung im Verzeichnis, indem verschiedene Einträge im Zertifikat angezeigt werden.

Zertifikatverarbeitungslogik

NT_AUTH Richtlinie wird am besten im Abschnitt CERT_CHAIN_POLICY_NT_AUTH Parameter der CertVerifyCertificateChainPolicy-Funktion beschrieben. Weitere Informationen finden Sie unter CertVerifyCertificateChainPolicy.

Smartcardanmeldung für einen einzelnen Benutzer mit einem Zertifikat in mehreren Konten

Ein einzelnes Benutzerzertifikat kann mehreren Konten zugeordnet werden. Beispielsweise kann sich ein Benutzer bei einem Benutzerkonto anmelden und sich auch als Domänenadministrator anmelden. Die Zuordnung erfolgt mithilfe der erstellten AltSecID basierend auf Attributen aus Clientkonten. Informationen zur Auswertung dieser Zuordnung finden Sie unter Anforderungen und Zuordnungen für Clientzertifikate.

Hinweis

Da jedes Konto über einen anderen Benutzernamen verfügt, empfiehlt es sich, die Gruppenrichtlinieneinstellung Benutzernamenhinweise zulassen (Registrierungsschlüssel X509HintsNeeded ) zu aktivieren, um die optionalen Felder bereitzustellen, mit denen Benutzer ihre Benutzernamen und Domäneninformationen für die Anmeldung eingeben können.

Basierend auf den Informationen, die im Zertifikat verfügbar sind, sind die Anmeldebedingungen:

1. Wenn kein UPN im Zertifikat 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 (z. B. wenn mehrere Benutzer demselben Zertifikat zugeordnet sind).
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. Damit sich ein Benutzer bei anderen Gesamtstrukturen anmelden kann, muss dem Benutzer ein X509-Hinweis bereitgestellt werden.

Smartcardanmeldung für mehrere 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.

Einem einzelnen Konto können mehrere unterschiedliche Zertifikate zugeordnet werden. Damit dies ordnungsgemäß funktioniert, darf das Zertifikat keine UPNs aufweisen.

Wenn z. B. Certificate1 über CN=CNName1, Certificate2 über CN=User1 und Certificate3 über CN=User2 verfügt, kann die AltSecID dieser Zertifikate mithilfe der Zuordnung active Directory-Benutzer und Computernamen einem einzelnen Konto zugeordnet werden.

Gesamtstrukturübergreifende Smartcardanmeldung

Damit die Kontozuordnung gesamtstrukturübergreifend funktioniert, insbesondere in Fällen, in denen nicht genügend Informationen für das Zertifikat verfügbar sind, gibt der Benutzer möglicherweise einen Hinweis in Form eines Benutzernamens ein, z. B. Domäne\Benutzer oder einen vollqualifizierten UPN wie user@contoso.com.

Hinweis

Damit das Hinweisfeld bei der Smartcardanmeldung angezeigt wird, muss die Gruppenrichtlinieneinstellung Benutzernamenhinweis zulassen (Registrierungsschlüssel X509HintsNeeded ) auf dem Client aktiviert sein.

OCSP-Unterstützung für PKINIT

Online Certificate Status Protocol (OCSP), das in RFC 2560 definiert ist, ermöglicht Es Anwendungen, rechtzeitig Informationen über den Sperrstatus eines Zertifikats abzurufen. Da OCSP-Antworten klein und gut gebunden sind, möchten eingeschränkte Clients möglicherweise OCSP verwenden, um die Gültigkeit der Zertifikate für Kerberos auf dem KDC zu überprüfen, um die Übertragung großer CRLs zu vermeiden und Bandbreite in eingeschränkten Netzwerken zu sparen. Informationen zu CRL-Registrierungsschlüsseln finden Sie unter Smartcard-Gruppenrichtlinie und Registrierungseinstellungen.

Die KDCs unter Windows versuchen, OCSP-Antworten abzurufen und zu verwenden, wenn verfügbar. Dieses Verhalten kann nicht deaktiviert werden. CryptoAPI für OCSP speichert OCSP-Antworten und den Status der Antworten zwischen. Der KDC unterstützt nur OCSP-Antworten für das Signaturgeberzertifikat.

Windows-Clientcomputer versuchen, die OCSP-Antworten anzufordern und in der Antwort zu verwenden, wenn sie verfügbar sind. Dieses Verhalten kann nicht deaktiviert werden.

Smartcard-Stammzertifikatanforderungen für die Verwendung bei der Domänenanmeldung

Damit die Anmeldung in einer smartcardbasierten Domäne funktioniert, muss das Smartcardzertifikat die folgenden Bedingungen erfüllen:

• Das KDC-Stammzertifikat auf der Smartcard muss über einen HTTP-Zertifikatssperrlistenverteilungspunkt verfügen, der im Zertifikat aufgeführt ist.
• Für das Smartcard-Anmeldezertifikat muss der HTTP-Zertifikatsperrlistenverteilungspunkt im Zertifikat aufgeführt sein.
• Der CRL-Verteilungspunkt muss über eine gültige, veröffentlichte Zertifikatsperrliste und ggf. eine Delta-Zertifikatsperrliste verfügen, auch wenn der CRL-Verteilungspunkt leer ist.
• Das Smartcardzertifikat muss eine der folgenden Komponenten enthalten:
  • Ein Betrefffeld, das den DNS-Domänennamen im Distinguished Name enthält. Wenn dies nicht der Fall ist, schlägt die Auflösung in eine geeignete Domäne fehl, sodass remotedesktopdienste und die Domänenanmeldung mit der Smartcard fehlschlagen
  • Ein UPN, bei dem der Domänenname in die tatsächliche Domäne aufgelöst wird. Wenn der Domänenname beispielsweise lautet, ist Engineering.Corp.Contosousername@engineering.corp.contoso.comder UPN . Wenn ein Teil des Domänennamens ausgelassen wird, kann der Kerberos-Client die entsprechende Domäne nicht finden.

Gehen Sie wie folgt vor, um die Smartcardanmeldung bei einer Domäne in diesen Versionen zuzulassen:

1. Aktivieren von HTTP-CRL-Verteilungspunkten auf der Zertifizierungsstelle
2. Starten Sie die Zertifizierungsstelle neu.
3. Erneutes Ausstellen des KDC-Zertifikats
4. Ausstellen oder erneutes Ausstellen des Smartcard-Anmeldezertifikats
5. Weitergeben des aktualisierten Stammzertifikats an die Smartcard, die Sie für die Domänenanmeldung verwenden möchten

Die Problemumgehung besteht darin, die Gruppenrichtlinieneinstellung Benutzernamenhinweise zulassen (Registrierungsschlüssel X509HintsNeeded ) zu aktivieren, mit der der Benutzer auf der Benutzeroberfläche der Anmeldeinformationen einen Hinweis für die Domänenanmeldung angeben kann.

Wenn der Clientcomputer nicht mit der Domäne verknüpft ist oder in eine andere Domäne eingebunden ist, kann der Clientcomputer die Serverdomäne nur auflösen, indem er sich den Distinguished Name im Zertifikat und nicht den UPN ansieht. Damit dieses Szenario funktioniert, erfordert das Zertifikat einen vollständigen Betreff, einschließlich DC=<DomainControllerName>, für die Domänennamenauflösung.

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

certutil.exe -scroots update

Weitere Informationen zu dieser Option für das Befehlszeilentool finden Sie unter -SCRoots.