Problembehandlung von Windows-Anmeldeproblemen mit dem Verbundauthentifizierungsdienst

In diesem Artikel werden die Protokolle und Fehlermeldungen beschrieben, die in Windows verfügbar sind, wenn sich Benutzer mit Zertifikaten und/oder Smartcards anmelden. Die Protokolle enthalten Informationen, die bei der Problembehandlung von Authentifizierungsfehlern hilfreich sein können.

Zertifikate und Public Key-Infrastruktur

Windows Active Directory unterhält mehrere Zertifikatspeicher, in denen Zertifikate für Benutzer verwaltet werden, die sich anmelden.

  • NTAuth-Zertifikatspeicher: Für die Authentifizierung bei Windows muss die Zertifizierungsstelle, die Benutzerzertifikate sofort ausstellt (Verkettung wird nicht unterstützt), im NTAuth-Speicher platziert werden. Geben Sie zum Anzeigen dieser Zertifikate im certutil-Programm Folgendes ein: certutil –viewstore –enterprise NTAuth.
  • Speicher für Stamm- und Zwischenzertifikate: Normalerweise können Zertifikatanmeldesysteme nur ein einzelnes Zertifikat zur Verfügung stellen. Wenn eine Kette verwendet wird, muss daher der Zwischenzertifikatspeicher auf allen Maschinen diese Zertifikate enthalten. Das Stammzertifikat muss im vertrauenswürdigen Stammspeicher und das vorletzte Zertifikat muss im NTAuth-Speicher sein.
  • Anmeldezertifikat-Erweiterungen und Gruppenrichtlinie: Windows kann so konfiguriert werden, dass die Überprüfung von EKUs und anderen Zertifikatrichtlinien erzwungen wird. Informationen finden Sie in der Microsoft-Dokumentation auf https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10)?redirectedfrom=MSDN.
Registrierungsrichtlinie Beschreibung
AllowCertificatesWithNoEKU Wenn deaktiviert, müssen Zertifikate die Smartcard-Anmeldung “Erweiterte Schlüsselverwendung” (Enhanced Key Usage, EKU) enthalten.
AllowSignatureOnlyKeys Standardmäßig filtert Windows die privaten Schlüssel aus Zertifikaten heraus, die RSA-Entschlüsselung nicht zulassen. Diese Option setzt den Filter außer Kraft.
AllowTimeInvalidCertificates Standardmäßig filtert Windows abgelaufene Zertifikate heraus. Diese Option setzt den Filter außer Kraft.
EnumerateECCCerts Aktiviert die Authentifizierung mit elliptischen Kurven.
X509HintsNeeded Mit dieser Option können Benutzer ihr Windows-Anmeldekonto manuell angeben, wenn ein Zertifikat keinen eindeutigen Benutzerprinzipalnamen (UPN) enthält oder der Name mehrdeutig ist.
UseCachedCRLOnlyAnd, IgnoreRevocationUnknownErrors Deaktiviert die Überprüfung von Sperrlisten (normalerweise auf dem Domänencontroller festgelegt).
  • Domänencontrollerzertifikate: Zum Authentifizieren von Kerberos-Verbindungen müssen alle Server entsprechende Domänencontrollerzertifikate haben. Diese können mit dem MMC-Snap-In-Menü “Local Computer Certificate Personal Store” angefordert werden.

Zuordnung von UPN-Namen und Zertifikaten

Es wird empfohlen, dass die Erweiterung des alternativen Antragstellernamens in Benutzerzertifikaten einen eindeutigen UPN (Benutzerprinzipalname) enthält.

UPN-Namen in Active Directory

Standardmäßig hat jeder Benutzer in Active Directory eine implizite UPN entsprechend den Mustern <samUsername>@<domainNetBios> und <samUsername>@<domainFQDN>. Die verfügbaren Domänen und FQDNs sind im RootDSE-Eintrag für die Gesamtstruktur enthalten. Für eine einzelne Domäne können mehrere FQDN-Adressen im RootDSE registriert sein.

Darüber hinaus hat jeder Benutzer in Active Directory eine explizite UPN und altUserPrincipalNames. Dies sind LDAP-Einträge, die den UPN für den Benutzer angeben.

Wenn Benutzer anhand der UPN gesucht werden, sucht Windows zuerst in der aktuellen Domäne (basierend auf der Identität des Prozesses bei der Suche nach der UPN) nach expliziten UPNs und dann nach alternativen UPNs. Wenn keine Übereinstimmungen gefunden werden, wird nach der impliziten UPN gesucht, die möglicherweise in anderen Domänen in der Gesamtstruktur aufgelöst wird.

Zertifikatszuordnungsdienst

Wenn ein Zertifikat keine explizite UPN enthält, kann Active Directory für jede Verwendung ein genaues öffentliches Zertifikat in einem “x509certificate”-Attribut speichern. Um ein solches Zertifikat in einen Benutzer aufzulösen, kann ein Computer eine direkte Abfrage für dieses Attribut durchführen (standardmäßig in einer einzelnen Domäne).

Der Benutzer hat die Option, ein Benutzerkonto anzugeben, das die Suche beschleunigt. Dieses Feature kann außerdem in einer domänenübergreifenden Umgebung verwendet werden.

Wenn die Gesamtstruktur mehrere Domänen enthält und der Benutzer eine Domäne nicht explizit angibt, kann der Speicherort des Zertifikatzuordnungsdiensts mit Active Directory rootDSE angegeben werden. Dies ist normalerweise auf einer Maschine des globalen Katalogs und umfasst die zwischengespeicherte Anzeige aller x509certificate-Attribute in der Gesamtstruktur. Mit diesem Computer kann ein Benutzerkonto basierend auf dem Zertifikat effizient in jeder Domäne gesucht werden.

Steuern der Domänencontrollerauswahl für die Anmeldung

Wenn eine Umgebung mehrere Domänencontroller umfasst, ist es sinnvoll einzuschränken, welcher Domänencontroller für die Authentifizierung verwendet wird, damit Protokolle aktiviert und abgerufen werden können.

Steuern der Domänencontrollerauswahl

Sie können Windows zur Verwendung eines bestimmten Windows-Domänencontrollers für die Anmeldung zwingen, indem Sie durch Konfigurieren der Datei lmhosts eine explizite Liste mit Domänencontrollern festlegen, die eine Windows-Maschine verwendet: \Windows\System32\drivers\etc\lmhosts.

In diesem Speicherort ist normalerweise eine Beispieldatei namens “lmhosts.sam”. Fügen Sie einfach eine Zeile hinzu:

1.2.3.4 dcnetbiosname #PRE #DOM:mydomai

“1.2.3.4” ist die IP-Adresse des Domänencontrollers “dcnetbiosname” in der Domäne “mydomain”.

Nach einem Neustart verwendet die Windows-Maschine diese Informationen, um sich bei “mydomain” anzumelden. Diese Konfiguration muss zurückgesetzt werden, wenn das Debuggen abgeschlossen ist.

Identifizieren des verwendeten Domänencontrollers

Bei der Anmeldung platziert Windows eine MSDOS-Umgebungsvariable in dem Domänencontroller, der den Benutzer angemeldet hat. Zum Anzeigen starten Sie die Befehlszeile mit dem folgenden Befehl: echo %LOGONSERVER%.

Authentifizierungsprotokolle werden auf dem Computer gespeichert, den dieser Befehl zurückgibt.

Aktivieren von Kontoüberwachungsereignissen

Standardmäßig aktivieren Windows-Domänencontroller keine vollständigen Überwachungsprotokolle für Konten. Überwachungsprotokolle können mit Überwachungsrichtlinien in den Sicherheitseinstellungen im Gruppenrichtlinien-Editor gesteuert werden. Wenn sie aktiviert sind, schreibt der Domänencontroller zusätzliche Ereignisprotokollinformationen in die Protokolldatei.

lokalisiertes Bild

Zertifikatüberprüfungsprotokolle

Überprüfen der Zertifikatgültigkeit

Wenn ein Smartcardzertifikat als DER-Zertifikat (kein privater Schlüssel erforderlich) exportiert wird, können Sie es mit folgendem Befehl überprüfen: certutil –verify user.cer

Aktivieren der CAPI-Protokollierung

Öffnen Sie auf dem Domänencontroller und den Benutzermaschinen die Ereignisanzeige und aktivieren Sie die Protokollierung für Microsoft/Windows/CAPI2/Operational Logs.

Sie können die CAPI-Protokollierung mit den Registrierungsschlüsseln hier steuern: CurrentControlSet\Services\crypt32.

Wert Beschreibung
DiagLevel (DWORD) Ausführlichkeitsgrad (0 bis 5)
DiagMatchAnyMask (QUADWORD) Ereignisfilter (0xffffff für alle)
DiagProcessName (MULTI_SZ) Nach Prozessname filtern (z. B. LSASS.exe)

CAPI-Protokolle

Meldung Beschreibung
Build Chain LSA-Aufruf: CertGetCertificateChain (einschließlich Ergebnis)
Verify Revocation LSA-Aufruf: CertVerifyRevocation (einschließlich Ergebnis)
X509 Objects Im ausführlichen Modus werden Zertifikate und Zertifikatsperrlisten (CRLs) im Verzeichnis \AppData\LocalLow Microsoft\X509Objects ausgegeben
Verify Chain Policy LSA-Aufruf: CertVerifyChainPolicy (einschließlich Parameter)

Fehlermeldungen

Fehlercode Beschreibung
Zertifikat ist nicht vertrauenswürdig Das Smartcardzertifikat konnte nicht mit Zertifikaten aus den Speichern für Zwischenzertifikate und vertrauenswürdige Stammzertifikate erstellt werden.
Certificate revocation check error Die Zertifikatsperrliste für die Smartcard konnte nicht von der Adresse heruntergeladen werden, die vom Zertifikatsperrlisten-Verteilungspunkt angegeben wurde. Wenn die Zertifikatsperrüberprüfung obligatorisch ist, schlagen Anmeldungen fehl. Weitere Informationen finden Sie im Abschnitt Zertifikate und Public Key-Infrastruktur.
Certificate Usage errors Das Zertifikat ist nicht für Anmeldungen geeignet. Es ist möglicherweise ein Serverzertifikat oder ein Signaturzertifikat.

Kerberos-Protokolle

Erstellen Sie folgende Registrierungswerte, um Kerberos-Protokollierung auf dem Domänencontroller und der Maschine des Endbenutzers zu aktivieren:

Struktur Wertname Wert [DWORD]
CurrentControlSet\Control\Lsa\Kerberos\Parameters LogLevel 0x1
CurrentControlSet\Control\Lsa\Kerberos\Parameters KerbDebuglevel 0xffffffff
CurrentControlSet\Services\Kdc KdcDebugLevel 0x1
CurrentControlSet\Services\Kdc KdcExtraLogLevel 0x1f

Die Kerberos-Protokollierung wird im Systemereignisprotokoll aufgezeichnet.

  • Meldungen wie “untrusted certificate” sind in der Regel einfach zu diagnostizieren.
  • Zwei Fehlercodes sind nur zur Information und können ignoriert werden:
    • KDC_ERR_PREAUTH_REQUIRED (für die Abwärtskompatibilität bei älteren Domänencontrollern)
    • Unknown error 0x4b

Ereignisprotokollmeldungen

Dieser Abschnitt beschreibt die auf dem Domänencontroller und der Arbeitsstation erwarteten Protokolleinträge, wenn Benutzer sich mit einem Zertifikat anmelden.

  • CAPI2-Protokoll des Domänencontrollers
  • Sicherheitsprotokoll des Domänencontrollers
  • VDA-Sicherheitsprotokoll
  • VDA-CAPI-Protokoll
  • VDA-Systemprotokoll

CAPI2-Protokoll des Domänencontrollers

Bei einer Anmeldung überprüft der Domänencontroller das Zertifikat des Aufrufenden, wodurch eine Sequenz von Protokolleinträgen wie nachfolgend dargestellt erstellt wird.

lokalisiertes Bild

Die letzte Meldung zeigt, dass lsass.exe auf dem Domänencontroller basierend auf dem vom VDA bereitgestellten Zertifikat eine Kette erstellt und sie auf Gültigkeit überprüft (einschließlich Sperrung). Das zurückgegebene Ergebnis ist “ERROR_SUCCESS”.

lokalisiertes Bild

Sicherheitsprotokoll des Domänencontrollers

Der Domänencontroller zeigt eine Reihe von Anmeldeereignissen an, wobei das Ereignis 4768, die Verwendung des Zertifikats zum Ausstellen des Kerberos Ticket Granting Ticket (krbtgt), das wichtigste ist.

Die vorhergehenden Meldungen zeigen, wie sich das Maschinenkonto des Servers beim Domänencontroller authentifiziert. Die darauffolgenden Meldungen zeigen, wie mit dem Benutzerkonto, das nun zum neuen krbtgt gehört, die Authentifizierung beim Domänencontroller durchgeführt wird.

lokalisiertes Bild

VDA-Sicherheitsprotokoll

Das VDA-Sicherheitsüberwachungsprotokoll, das der Anmeldung entspricht, ist der Eintrag mit der Ereignis-ID 4648, der von winlogon.exe verursacht wurde.

lokalisiertes Bild

VDA-CAPI-Protokoll

Dieses VDA-CAPI-Beispielprotokoll zeigt eine erstellte Kette und eine Überprüfungssequenz von lsass.exe, mit der das Domänencontrollerzertifikat (dc.citrixtest.net) überprüft wurde.

lokalisiertes Bild

lokalisiertes Bild

VDA-Systemprotokoll

Wenn die Kerberos-Protokollierung aktiviert ist, enthält das Systemprotokoll die Fehlermeldung KDC_ERR_PREAUTH_REQUIRED, die ignoriert werden kann, und einen Eintrag von Winlogon zur erfolgreichen Kerberos-Anmeldung.

lokalisiertes Bild

Endbenutzerfehlermeldungen

In diesem Abschnitt finden Sie allgemeine Fehlermeldungen, die Benutzern auf der Windows-Anmeldeseite angezeigt werden.

Angezeigte Fehlermeldung Beschreibung und Referenz
Ungültiger Benutzername oder Kennwort Der Computer glaubt, dass Sie ein gültiges Zertifikat und einen gültigen privaten Schlüssel haben, aber der Kerberos-Domänencontroller hat die Verbindung zurückgewiesen. Weitere Informationen finden unter Kerberos-Protokolle.
Sie konnten nicht angemeldet werden. Ihre Anmeldeinformationen konnten nicht überprüft werden. Es kann kein Kontakt zum Domänencontroller hergestellt werden oder auf dem Domänencontroller sind nicht die entsprechenden Zertifikate installiert.
Die Anforderung wird nicht unterstützt. Registrieren Sie die Zertifikate “Domain Controller” und “Domain Controller Authentication” auf dem Domänencontroller neu, wie in CTX206156 beschrieben. Dies ist einen Versuch wert, selbst wenn die vorhandenen Zertifikate anscheinend gültig sind.
Sie konnten nicht angemeldet werden. Das für die Authentifizierung verwendete Smartcardzertifikat ist nicht vertrauenswürdig. Die Zwischen- und Stammzertifikate sind nicht auf dem lokalen Computer installiert. Informationen zum Installieren von Smartcardzertifikaten auf nicht in Domänen eingebundenen Computern finden Sie unter CTX206156. Weitere Informationen finden Sie im Abschnitt Zertifikate und Public Key-Infrastruktur in diesem Artikel.
Sie können sich nicht anmelden, da die Smartcard-Anmeldung für Ihr Konto nicht unterstützt wird. Ein Arbeitsgruppenbenutzerkonto wurde für die Smartcard-Anmeldung nicht vollständig konfiguriert.
Der angeforderte Schlüssel ist nicht vorhanden. Ein Zertifikat verweist auf einen privaten Schlüssel, auf den nicht zugegriffen werden kann. Dieser Fall kann eintreten, wenn eine PIV-Karte nicht vollständig konfiguriert ist und die CHUID oder CCC-Datei fehlt.
Fehler beim Verwenden der Smartcard Die Smartcard-Middleware ist nicht ordnungsgemäß installiert. Smartcard-Installationsanweisungen finden Sie unter CTX206156.
Smartcard einlegen Die Smartcard oder der Smartcardleser wurde nicht erkannt. Wenn die Smartcard eingelegt ist, weist diese Meldung auf ein Problem mit der Hardware oder Middleware hin. Smartcard-Installationsanweisungen finden Sie unter CTX206156.
Die PIN ist falsch. Die Smartcard hat die vom Benutzer eingegebene PIN nicht akzeptiert.
Es wurde kein gültiges Smartcardzertifikat gefunden. Die Erweiterungen des Zertifikats sind möglicherweise nicht richtig festgelegt worden oder der RSA-Schlüssel ist zu kurz. (<2048 Bits). Informationen zum Erstellen von gültigen Smartcardzertifikaten finden Sie unter CTX206901.
Die Smartcard ist blockiert. Eine Smartcard wurde gesperrt, z. B. weil der Benutzer mehrmals eine falsche PIN eingegeben hat. Ein Administrator hat möglicherweise Zugriff auf den PIN-Entsperrcode (PUK) für die Smartcard und kann die PIN mit einem Tool zurücksetzen, das beim Smartcardhersteller erhältlich ist. Wenn der Entsperrcode nicht verfügbar ist oder die Sperrung nicht aufgehoben werden kann, muss die Smartcard auf die Werkseinstellungen zurückgesetzt werden.
Ungültige Anforderung Der private Schlüssel einer Smartcard unterstützt die Kryptografie nicht, die der Domänencontroller erfordert. Beispielsweise fordert der Domänencontroller möglicherweise die Entschlüsselung des privaten Schlüssels, aber die Smartcard unterstützt nur das Signieren. Dies weist meist darauf hin, dass die Erweiterungen des Zertifikats nicht ordnungsgemäß festgelegt sind oder dass der RSA-Schlüssel zu kurz ist. (<2048 Bits). Informationen zum Erstellen von gültigen Smartcardzertifikaten finden Sie unter CTX206901.

Verwandte Informationen