Produktdokumentation
XenApp and XenDesktop
7.15 LTSR
PDF anzeigen

Federated Authentication Service: Problembehandlung bei Windows-Anmeldeproblemen

June 10, 2026
Beitrag von: 
C

Dieser Artikel beschreibt die Protokolle und Fehlermeldungen, die Windows bereitstellt, wenn sich ein Benutzer mit Zertifikaten und/oder Smartcards anmeldet. Diese Protokolle liefern Informationen, die Sie zur Behebung von Authentifizierungsfehlern verwenden können.

Zertifikate und Public-Key-Infrastruktur

Windows Active Directory verwaltet mehrere Zertifikatspeicher, die Zertifikate für sich anmeldende Benutzer verwalten.

  • NTAuth-Zertifikatspeicher: Zur Authentifizierung bei Windows muss die CA, die Benutzerzertifikate direkt ausstellt (d. h. keine Verkettung wird unterstützt), im NTAuth-Speicher abgelegt werden. Um diese Zertifikate anzuzeigen, geben Sie im Programm certutil Folgendes ein: certutil –viewstore –enterprise NTAuth.
  • Stamm- und Zwischenzertifikatspeicher: Normalerweise können Zertifikatsanmeldesysteme nur ein einziges Zertifikat bereitstellen. Wenn also eine Kette verwendet wird, muss der Zwischenzertifikatspeicher auf allen Computern diese Zertifikate enthalten. Das Stammzertifikat muss im Speicher für vertrauenswürdige Stammzertifikate (Trusted Root Store) liegen, und das vorletzte Zertifikat muss im NTAuth-Speicher liegen.
  • Anmeldezertifikaterweiterungen und Gruppenrichtlinien: Windows kann so konfiguriert werden, dass die Überprüfung von EKUs und anderen Zertifikatsrichtlinien erzwungen wird. Siehe die Microsoft-Dokumentation: https://docs.microsoft.com/de-de/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 erweiterte Schlüsselverwendung (EKU) für die Smartcard-Anmeldung enthalten.
AllowSignatureOnlyKeys Standardmäßig filtert Windows private Zertifikatsschlüssel heraus, die keine RSA-Entschlüsselung zulassen. Diese Option überschreibt diesen Filter.
AllowTimeInvalidCertificates Standardmäßig filtert Windows abgelaufene Zertifikate heraus. Diese Option überschreibt diesen Filter.
EnumerateECCCerts Ermöglicht die Authentifizierung mit elliptischen Kurven.
X509HintsNeeded Wenn ein Zertifikat keinen eindeutigen Benutzerprinzipalnamen (UPN) enthält oder dieser mehrdeutig sein könnte, können Benutzer mit dieser Option ihr Windows-Anmeldekonto manuell angeben.
UseCachedCRLOnlyAnd, IgnoreRevocationUnknownErrors Deaktiviert die Überprüfung des Widerrufs (normalerweise auf dem Domänencontroller festgelegt).
  • Domänencontroller-Zertifikate: Um Kerberos-Verbindungen zu authentifizieren, müssen alle Server über entsprechende „Domänencontroller“-Zertifikate verfügen. Diese können über das MMC-Snap-In-Menü „Zertifikate (Lokaler Computer) – Persönlicher Speicher“ angefordert werden.

UPN-Name und Zertifikatszuordnung

Es wird empfohlen, dass Benutzerzertifikate einen eindeutigen Benutzerprinzipalnamen (UPN) in der Erweiterung „Alternativer Antragstellername“ enthalten.

UPN-Namen in Active Directory

Standardmäßig hat jeder Benutzer in Active Directory einen impliziten UPN, der auf dem Muster <samUsername>@<domainNetBios> und <samUsername>@<domainFQDN> basiert. Die verfügbaren Domänen und FQDNs sind im RootDSE-Eintrag für die Gesamtstruktur enthalten. Beachten Sie, dass eine einzelne Domäne mehrere im RootDSE registrierte FQDN-Adressen haben kann.

Zusätzlich hat jeder Benutzer in Active Directory einen expliziten UPN und altUserPrincipalNames. Dies sind LDAP-Einträge, die den UPN für den Benutzer angeben.

Bei der Suche nach Benutzern anhand des UPN sucht Windows zuerst in der aktuellen Domäne (basierend auf der Identität des Prozesses, der den UPN nachschlägt) nach expliziten UPNs, dann nach alternativen UPNs. Wenn es keine Übereinstimmungen gibt, wird der implizite UPN nachgeschlagen, der möglicherweise zu verschiedenen Domänen in der Gesamtstruktur aufgelöst wird.

Zertifikatszuordnungsdienst

Wenn ein Zertifikat keinen expliziten UPN enthält, bietet Active Directory die Möglichkeit, ein exaktes öffentliches Zertifikat für jede Verwendung in einem „x509certificate“-Attribut zu speichern. Um ein solches Zertifikat einem Benutzer zuzuordnen, kann ein Computer dieses Attribut direkt abfragen (standardmäßig in einer einzelnen Domäne).

Eine Option wird dem Benutzer bereitgestellt, um ein Benutzerkonto anzugeben, das diese Suche beschleunigt und es auch ermöglicht, diese Funktion in einer domänenübergreifenden Umgebung zu verwenden.

Wenn mehrere Domänen in der Gesamtstruktur vorhanden sind und der Benutzer keine Domäne explizit angibt, legt das Active Directory rootDSE den Speicherort des Zertifikatszuordnungsdienstes fest. Dieser befindet sich normalerweise auf einem globalen Katalogserver und verfügt über eine zwischengespeicherte Ansicht aller x509-Zertifikatattribute in der Gesamtstruktur. Dieser Computer kann verwendet werden, um ein Benutzerkonto in jeder Domäne effizient zu finden, basierend nur auf dem Zertifikat.

Auswahl des Anmelde-Domänencontrollers steuern

Wenn eine Umgebung mehrere Domänencontroller enthält, ist es nützlich zu sehen und einzuschränken, welcher Domänencontroller für die Authentifizierung verwendet wird, damit Protokolle aktiviert und abgerufen werden können.

Auswahl des Domänencontrollers steuern

Um Windows zu zwingen, einen bestimmten Windows-Domänencontroller für die Anmeldung zu verwenden, können Sie die Liste der Domänencontroller, die ein Windows-Computer verwendet, explizit festlegen, indem Sie die lmhosts-Datei konfigurieren: \Windows\System32\drivers\etc\lmhosts.

An diesem Speicherort befindet sich normalerweise eine Beispieldatei namens „lmhosts.sam“. Fügen Sie einfach eine Zeile hinzu:

1.2.3.4 DC-NetBIOS-Name #PRE #DOM:meinedomäne

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

Nach einem Neustart verwendet der Windows-Computer diese Informationen, um sich bei mydomain anzumelden. Beachten Sie, dass diese Konfiguration rückgängig gemacht werden muss, wenn das Debugging abgeschlossen ist.

Verwendeten Domänencontroller identifizieren

Bei der Anmeldung setzt Windows eine MSDOS-Umgebungsvariable mit dem Domänencontroller, der den Benutzer angemeldet hat. Um dies zu sehen, starten Sie die Eingabeaufforderung mit dem Befehl: echo %LOGONSERVER%.

Protokolle, die sich auf die Authentifizierung beziehen, werden auf dem Computer gespeichert, der von diesem Befehl zurückgegeben wird.

Kontoüberwachungsereignisse aktivieren

Standardmäßig aktivieren Windows-Domänencontroller keine vollständigen Kontoüberwachungsprotokolle. Dies kann über Überwachungsrichtlinien in den Sicherheitseinstellungen im Gruppenrichtlinien-Editor gesteuert werden. Nach der Aktivierung erzeugt der Domänencontroller zusätzliche Ereignisprotokollinformationen in der Sicherheitsereignisprotokolldatei.

lokalisiertes Bild

Zertifikatsvalidierungsprotokolle

Zertifikatsgültigkeit prüfen

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

CAPI-Protokollierung aktivieren

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

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

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

CAPI-Protokolle

Meldung Beschreibung
Kette erstellen LSA hat CertGetCertificateChain aufgerufen (enthält Ergebnis)
Sperrung überprüfen LSA hat CertVerifyRevocation aufgerufen (enthält Ergebnis)
X509-Objekte Im ausführlichen Modus werden Zertifikate und Zertifikatsperrlisten (CRLs) nach AppData\LocalLow\Microsoft\X509Objects ausgegeben.
Kettenrichtlinie überprüfen LSA hat CertVerifyChainPolicy aufgerufen (enthält Parameter)

Fehlermeldungen

Fehlercode Beschreibung
Zertifikat nicht vertrauenswürdig Das Smartcard-Zertifikat konnte nicht unter Verwendung von Zertifikaten in den Zwischen- und vertrauenswürdigen Stammzertifikatspeichern des Computers erstellt werden.
Fehler bei der Zertifikatssperrprüfung Die CRL für die Smartcard konnte nicht von der Adresse heruntergeladen werden, die vom CRL-Verteilungspunkt des Zertifikats angegeben wurde. Wenn die Sperrprüfung vorgeschrieben ist, verhindert dies eine erfolgreiche Anmeldung. Siehe den Abschnitt Zertifikate und Public Key-Infrastruktur.
Fehler bei der Zertifikatnutzung Das Zertifikat ist nicht für die Anmeldung geeignet. Zum Beispiel könnte es sich um ein Serverzertifikat oder ein Signaturzertifikat handeln.

Kerberos-Protokolle

Um die Kerberos-Protokollierung zu aktivieren, erstellen Sie auf dem Domänencontroller und dem Endbenutzercomputer die folgenden Registrierungswerte:

Hive 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 in das Systemereignisprotokoll ausgegeben.

  • Meldungen wie „nicht vertrauenswürdiges Zertifikat“ sollten leicht zu diagnostizieren sein.
  • Zwei Fehlercodes sind informativ und können bedenkenlos ignoriert werden:
    • KDC_ERR_PREAUTH_REQUIRED (wird zur Abwärtskompatibilität mit älteren Domänencontrollern verwendet)
    • Unbekannter Fehler 0x4b

Ereignisprotokollmeldungen

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

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

Domänencontroller-CAPI2-Protokoll

Während einer Anmeldung validiert der Domänencontroller das Zertifikat des Anrufers und erstellt eine Abfolge von Protokolleinträgen in der folgenden Form.

lokalisiertes Bild

Die endgültige Ereignisprotokollmeldung zeigt, wie lsass.exe auf dem Domänencontroller eine Kette basierend auf dem vom VDA bereitgestellten Zertifikat erstellt und deren Gültigkeit (einschließlich des Widerrufs) überprüft. Das Ergebnis wird als „ERROR_SUCCESS“ zurückgegeben.

lokalisiertes Bild

Domänencontroller-Sicherheitsprotokoll

Der Domänencontroller zeigt eine Abfolge von Anmeldeereignissen, wobei das Schlüsselereignis 4768 ist, bei dem das Zertifikat zur Ausstellung des Kerberos Ticket Granting Ticket (krbtgt) verwendet wird.

Die Meldungen davor zeigen, wie das Computerkonto des Servers sich beim Domänencontroller authentifiziert. Die Meldungen danach zeigen, wie das Benutzerkonto, das zum neuen krbtgt gehört, zur Authentifizierung beim Domänencontroller verwendet wird.

lokalisiertes Bild

VDA-Sicherheitsprotokoll

Das VDA-Sicherheitsüberwachungsprotokoll, das dem Anmeldeereignis entspricht, ist der Eintrag mit der Ereignis-ID 4648, der von winlogon.exe stammt.

lokalisiertes Bild

VDA CAPI-Protokoll

Dieses Beispiel-VDA-CAPI-Protokoll zeigt eine einzelne Kettenaufbau- und Verifizierungssequenz von lsass.exe, die das Domänencontroller-Zertifikat (dc.citrixtest.net) validiert.

lokalisiertes Bild

lokalisiertes Bild

VDA-Systemprotokoll

Wenn die Kerberos-Protokollierung aktiviert ist, zeigt das Systemprotokoll den Fehler KDC_ERR_PREAUTH_REQUIRED (der ignoriert werden kann) und einen Eintrag von Winlogon, der anzeigt, dass die Kerberos-Anmeldung erfolgreich war.

lokalisiertes Bild

Fehlermeldungen für Endbenutzer

Dieser Abschnitt listet häufige Fehlermeldungen auf, die einem Benutzer auf der Windows-Anmeldeseite angezeigt werden.

Angezeigte Fehlermeldung Beschreibung und Referenz
Ungültiger Benutzername oder Kennwort Der Computer geht davon aus, dass Sie ein gültiges Zertifikat und einen privaten Schlüssel besitzen, aber der Kerberos-Domänencontroller hat die Verbindung abgelehnt. Siehe den Abschnitt Kerberos-Protokolle dieses Artikels.
Das System konnte Sie nicht anmelden. Ihre Anmeldeinformationen konnten nicht überprüft werden. Der Domänencontroller kann nicht kontaktiert werden, oder der Domänencontroller verfügt nicht über die entsprechenden installierten Zertifikate.
Die Anforderung wird nicht unterstützt Registrieren Sie die Zertifikate „Domänencontroller“ und „Domänencontroller-Authentifizierung“ auf dem Domänencontroller neu, wie in CTX206156 beschrieben. Dies ist normalerweise einen Versuch wert, selbst wenn die vorhandenen Zertifikate gültig zu sein scheinen.
Das System konnte Sie nicht anmelden. Das für die Authentifizierung verwendete Smartcard-Zertifikat wurde nicht als vertrauenswürdig eingestuft. Die Zwischen- und Stammzertifikate sind auf dem lokalen Computer nicht installiert. Anweisungen zur Installation von Smartcard-Zertifikaten auf Computern, die nicht in eine Domäne eingebunden sind, finden Sie unter CTX206156. Siehe auch den 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 Arbeitsgruppen-Benutzerkonto wurde nicht vollständig für die Smartcard-Anmeldung konfiguriert.
Der angeforderte Schlüssel existiert nicht Ein Zertifikat verweist auf einen privaten Schlüssel, der nicht zugänglich ist. Dies kann passieren, wenn eine PIV-Karte nicht vollständig konfiguriert ist und die CHUID- oder CCC-Datei fehlt.
Beim Versuch, die Smartcard zu verwenden, ist ein Fehler aufgetreten Die Smartcard-Middleware wurde nicht korrekt installiert. Anweisungen zur Smartcard-Installation finden Sie unter CTX206156.
Smartcard einlegen Die Smartcard oder das Lesegerät wurde nicht erkannt. Wenn die Smartcard eingelegt ist, weist diese Meldung auf ein Hardware- oder Middleware-Problem hin. Anweisungen zur Smartcard-Installation finden Sie unter CTX206156.
Die PIN ist falsch Die Smartcard hat eine vom Benutzer eingegebene PIN abgelehnt.
Es konnte kein gültiges Smartcard-Zertifikat gefunden werden. Die Erweiterungen des Zertifikats sind möglicherweise nicht korrekt festgelegt, oder der RSA-Schlüssel ist zu kurz (<2048 Bit). Informationen zum Generieren gültiger Smartcard-Zertifikate finden Sie unter CTX206901.
Die Smartcard ist gesperrt Eine Smartcard wurde gesperrt (z. B. hat der Benutzer mehrmals eine falsche PIN eingegeben). Ein Administrator hat möglicherweise Zugriff auf den PIN-Entsperrcode (PUK) für die Karte und kann die Benutzer-PIN mit einem vom Smartcard-Anbieter bereitgestellten Tool zurücksetzen. Wenn der PUK-Code nicht verfügbar oder gesperrt ist, muss die Karte auf die Werkseinstellungen zurückgesetzt werden.
Ungültige Anforderung Ein privater Smartcard-Schlüssel unterstützt die vom Domänencontroller erforderliche Kryptografie nicht. Der Domänencontroller hat beispielsweise möglicherweise eine „Entschlüsselung mit privatem Schlüssel“ angefordert, die Smartcard unterstützt jedoch nur die Signierung. Dies weist normalerweise darauf hin, dass die Erweiterungen des Zertifikats nicht korrekt festgelegt sind oder der RSA-Schlüssel zu kurz ist (<2048 Bit). Informationen zum Generieren gültiger Smartcard-Zertifikate finden Sie unter CTX206901.

Zugehörige Informationen

Federated Authentication Service: Problembehandlung bei Windows-Anmeldeproblemen
June 10, 2026
Beitrag von: 
C
June 10, 2026
Beitrag von: 
C

In diesem Artikel

Feedback zur Site | Your privacy choices footer linkIhre Datenschutzauswahl | Datenschutz und rechtliche Bestimmungen | Cookie-Einstellungen | Einstellungen für die Zustimmung | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.