Zertifikatanforderungen und Enumeration

In diesem Thema für IT-Experten und Entwickler von intelligenten Karte wird beschrieben, wie Zertifikate verwaltet und für die Anmeldung mit intelligenten Karte verwendet werden.

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-Datenbank sucht nach dem Kryptografiedienstanbieter (CSP) des intelligenten Karte.

  2. Ein qualifizierter Containername wird mithilfe des Smart Karte-Lesernamens 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 intelligente Karte für die Anmeldung mit intelligenten Karte 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 Smart Karte-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.

Smart Karte-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 demselben Karte.

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

Wenn Sie die Richtlinie Signaturschlüssel zulassen aktivieren, die für Anmeldeinformationsanbieter gültig sind, werden alle Zertifikate, die auf dem smarten Karte 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 smarte Karte signaturschlüsselbasierte Zertifikate nicht auf dem Anmeldebildschirm aufgeführt.

Im folgenden Diagramm wird veranschaulicht, wie die Smart Karte-Anmeldung in den unterstützten Versionen von Windows funktioniert.

Smart Karte-Anmeldeflow.

Smart Karte-Anmeldeflow

Im Folgenden werden die Schritte aufgeführt, die während einer Smart Karte-Anmeldung ausgeführt werden:

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

  2. Der Ressourcen-Manager für intelligente Karte wird asynchron gestartet, und der Anbieter von Anmeldeinformationen für intelligente Karte führt Folgendes aus:

    1. Ruft Anmeldeinformationen ab (eine Liste bekannter Anmeldeinformationen oder, wenn keine Anmeldeinformationen vorhanden sind, die Von Windows erkannten Informationen zum Intelligenten Karte-Leser)
    2. Ruft eine Liste der Smart Karte-Leser (mithilfe der WinSCard-API) und die Liste der smartcards ab, die in den einzelnen Smartcards eingefügt wurden.
    3. Listet jeden Karte auf, um zu überprüfen, ob ein Anmeldezertifikat vorhanden ist, das von Gruppenrichtlinie gesteuert wird. Wenn das Zertifikat vorhanden ist, kopiert der Anbieter von Smart Karte Anmeldeinformationen 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 Anmeldeinformationsanbieter der intelligenten Karte an. Als Antwort stellt der Smart Karte-Anmeldeinformationsanbieter jedes Anmeldezertifikat für die Anmeldebenutzeroberfläche bereit, und die entsprechenden Anmeldekacheln werden angezeigt. Der Benutzer wählt eine Kachel für ein Smart Karte-basiertes Anmeldezertifikat aus, und Windows zeigt ein PIN-Dialogfeld an.

  4. Der Benutzer gibt die PIN ein und drückt dann die EINGABETASTE. Der Anbieter von Smart Karte-Anmeldeinformationen verschlüsselt die PIN.

  5. Der Anmeldeinformationsanbieter, der sich im LogonUI-System befindet, sammelt die PIN. Im Rahmen des Packens von Anmeldeinformationen im Smart Karte-Anmeldeinformationsanbieter werden die Daten in einer KERB_CERTIFICATE_LOGON-Struktur gepackt. Die Standard Inhalte der KERB_CERTIFICATE_LOGON-Struktur sind die Smart Karte 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 Karte Schlü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 einem intelligenten Karte gespeichert wird, wird das Subsystem smart Karte 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 (Zeit, Pfad und Sperrung status), um sicherzustellen, dass das Zertifikat von 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 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. Mit CryptoAPI wird der temporäre Schlüssel entschlüsselt. Wenn sich der private Schlüssel in einem smarten Karte befindet, wird im Rahmen des Entschlüsselungsprozesses ein Aufruf an das Smart Karte-Subsystem 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 (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. 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, Gruppenrichtlinie Aktualisierung instanziiert wird und andere Aktionen ausgeführt werden.

  18. Nachdem das Benutzerprofil geladen wurde, erkennt der Certification Propagation Service (CertPropSvc) dieses Ereignis, liest die Zertifikate aus dem smarten 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 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 das KDC, ob das Zertifikat des Clients die EKU "Smart Karte Clientauthentifizierung" szOID_KP_SMARTCARD_LOGON enthält. Wenn diese Option jedoch aktiviert ist, ermöglicht die Einstellung Zertifikate ohne Zertifikatsattribut für die erweiterte Schlüsselverwendung zulassen Gruppenrichtlinie, 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 Smart Karte Anmeldeobjektbezeichner ist nicht erforderlich.

Hinweis Wenn eine EKU vorhanden ist, muss sie die Smart Karte-Anmelde-EKU enthalten. Zertifikate ohne EKU können für die Anmeldung verwendet werden.
Alternativer Antragstellername Die E-Mail-ID ist für die Anmeldung mit intelligenten Karte nicht erforderlich.
Antragsteller Nicht erforderlich
Schlüsselaustausch (AT_KEYEXCHANGE Feld) Nicht erforderlich für Smart Karte-Anmeldezertifikate, wenn eine Gruppenrichtlinie Einstellung aktiviert ist. (Standardmäßig sind Gruppenrichtlinie Einstellungen nicht aktiviert.)
ZERTIFIKATSPERRLISTE Nicht erforderlich
UPN Nicht erforderlich
Anmerkungen Sie können aktivieren, dass jedes Zertifikat für den Anmeldeinformationsanbieter der intelligenten Karte 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

Verteilungspunkte der Zertifikatsperrliste.

UPN im Feld "Alternativer Antragstellername"

UPN im Feld

Felder "Betreff" und "Aussteller"

Betreff- und Ausstellerfelder.

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

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

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.

Smart Karte Anmeldung für einen einzelnen Benutzer mit einem Zertifikat bei 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 Einstellung Benutzernamenhinweis Gruppenrichtlinie 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.

Smart Karte Anmeldung für mehrere Benutzer bei 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 Certificate1 beispielsweise über CN=CNName1, Certificate2 über CN=User1 und Certificate3 über CN=User2 verfügt, kann die AltSecID dieser Zertifikate mithilfe der Active Directory-Benutzer und -Computer Namenszuordnung 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 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 während der Smart Karte-Anmeldung angezeigt wird, muss die Einstellung Benutzernamenhinweis Gruppenrichtlinie 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 die Sperrung status eines Zertifikats zu erhalten. 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 for OCSP speichert OCSP-Antworten und die 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.

Anforderungen an das Smart Karte-Stammzertifikat für die Verwendung bei der Domänenanmeldung

Damit die Anmeldung in einer smart Karte-basierten Domäne funktioniert, muss das Smart Karte-Zertifikat die folgenden Bedingungen erfüllen:

  • Das KDC-Stammzertifikat auf dem intelligenten Karte muss über einen HTTP-Zertifikatssperrlistenverteilungspunkt verfügen, der im Zertifikat aufgeführt ist.
  • Für das Smart Karte-Anmeldezertifikat muss der HTTP-Zertifikatssperrlistenverteilungspunkt 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 Smart Karte-Zertifikat muss eine der folgenden Komponenten enthalten:
    • Ein Betrefffeld, das den DNS-Domänennamen im Distinguished Name enthält. Andernfalls schlägt die Auflösung in eine geeignete Domäne fehl, sodass remotedesktopdienste und die Domänenanmeldung mit dem smarten Karte 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 Anmeldung von Smart Karte 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 Smart Karte-Anmeldezertifikats
  5. Weitergeben des aktualisierten Stammzertifikats an die intelligente Karte, die Sie für die Domänenanmeldung verwenden möchten

Die Problemumgehung besteht darin, die Einstellung Benutzernamenhinweis Gruppenrichtlinie 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 für eine intelligente Karte 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.