Freigeben über

Authentifizierungsfehler von Nicht-Windows NTLM- oder Kerberos-Servern

  • Artikel

Dieser Artikel enthält eine Lösung für mehrere Authentifizierungsfehlerprobleme, bei denen NTLM- und Kerberos-Server keine Windows 7- und Windows Server 2008 R2-basierten Computer authentifizieren können. Dies wird durch Unterschiede in der Art und Weise verursacht, wie Kanalbindungstoken behandelt werden.

Ursprüngliche KB-Nummer: 976918

Symptome

Windows 7 und Windows Server 2008 R2 unterstützen standardmäßig erweiterten Schutz für integrierte Authentifizierung, die Unterstützung für Kanalbindungstoken (CBT) enthält.

Sie können ein oder mehrere der folgenden Symptome erleben:

  • Windows-Clients, die die Kanalbindung unterstützen, können nicht von einem Windows-Kerberos-Server authentifiziert werden.
  • NTLM-Authentifizierungsfehler von Proxyservern.
  • NTLM-Authentifizierungsfehler von Nicht-Windows NTLM-Servern.
  • NTLM-Authentifizierungsfehler, wenn es einen Zeitunterschied zwischen client und DC oder Arbeitsgruppenserver gibt.

Ursache

Windows 7 und Windows Server 2008 R2 unterstützen erweiterten Schutz für integrierte Authentifizierung. Dieses Feature verbessert den Schutz und die Behandlung von Anmeldeinformationen beim Authentifizieren von Netzwerkverbindungen mithilfe der integrierten Windows-Authentifizierung (IWA).

Dies ist standardmäßig aktiviert. Wenn ein Client versucht, eine Verbindung mit einem Server herzustellen, wird die Authentifizierungsanforderung an den verwendeten Dienstprinzipalnamen (Service Principal Name, SPN) gebunden. Wenn die Authentifizierung auch innerhalb eines TLS-Kanals (Transport Layer Security) erfolgt, kann sie an diesen Kanal gebunden werden. NTLM und Kerberos stellen zusätzliche Informationen in ihren Nachrichten bereit, um diese Funktionalität zu unterstützen.

Außerdem deaktivieren Windows 7- und Windows 2008 R2-Computer LMv2.

Lösung

Wenden Sie sich bei Fehlern, bei denen nicht Windows NTLM- oder Kerberos-Server fehlschlagen, wenn CBT empfangen wird, beim Anbieter nach einer Version, die CBT ordnungsgemäß verarbeitet.

Bei Fehlern, bei denen Nicht-Windows NTLM-Server oder Proxyserver LMv2 erfordern, wenden Sie sich an den Anbieter auf eine Version, die NTLMv2 unterstützt.

Problemumgehung

Wichtig

Dieser Abschnitt, diese Methode bzw. diese Aufgabe enthält eine Beschreibung der Schritte zum Bearbeiten der Registrierung. Durch die falsche Bearbeitung der Registrierung können schwerwiegende Probleme verursacht werden. Daher müssen Sie sicherstellen, dass Sie diese Schritte sorgfältig ausführen. Für weiteren Schutz sichern Sie die Registrierung, bevor Sie sie ändern. Anschließend können Sie die Registrierung wiederherstellen, wenn ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie unter: Sichern und Wiederherstellen der Registrierung Windows.

Erstellen Sie zum Steuern des erweiterten Schutzverhaltens den folgenden Registrierungsunterschlüssel:

  • Schlüsselname: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA
  • Wertname: SuppressExtendedProtection
  • Type: DWORD

Für Windows-Clients, die kanalbindung unterstützen, die nicht von Windows-Kerberos-Servern authentifiziert werden, die das CBT nicht ordnungsgemäß verarbeiten:

  1. Legen Sie den Registrierungseintragswert auf 0x01 fest. Dadurch wird Kerberos so konfiguriert, dass CBT-Token für nicht gepatchte Anwendungen ausgegeben werden.
  2. Wenn das Problem dadurch nicht behoben wird, legen Sie den Registrierungseintragswert auf 0x03 fest. Dadurch wird Kerberos nie so konfiguriert, dass CBT-Token ausgegeben werden.

Notiz

Es gibt ein bekanntes Problem mit Sun Java, das behoben wurde, um die Option zu berücksichtigen, dass der Acceptor alle vom Initiator bereitgestellten Kanalbindungen ignorieren kann, auch wenn der Initiator Kanalbindungen gemäß RFC 4121 übergeben hat. Weitere Informationen finden Sie unter Ignorieren der eingehenden Kanalbindung, wenn der Acceptor keins festgelegt hat.

Es wird empfohlen, das folgende Update von der Sun Java-Website zu installieren und den erweiterten Schutz wieder zu aktivieren: Änderungen in 1.6.0_19 (6u19).

Legen Sie für Windows-Clients, die die Kanalbindung unterstützen, die nicht von Windows NTLM-Servern authentifiziert werden, die das CBT nicht ordnungsgemäß verarbeiten, den Registrierungseintragswert auf 0x01 fest. Dadurch wird NTLM so konfiguriert, dass CBT-Token für nicht gepatchte Anwendungen ausgegeben werden.

Legen Sie für Nicht-Windows NTLM-Server oder Proxyserver, die LMv2 erfordern, auf den Registrierungseintragswert auf 0x01 fest. Dadurch wird NTLM so konfiguriert, dass LMv2-Antworten bereitgestellt werden.

Für das Szenario, in dem der Zeitunterschied zu groß ist:

  1. Korrigieren Sie die Uhr des Clients, um die Uhrzeit auf dem Domänencontroller oder arbeitsgruppenserver widerzuspiegeln.
  2. Wenn das Problem dadurch nicht behoben wird, legen Sie den Registrierungseintragswert auf 0x01 fest. Dadurch wird NTLM so konfiguriert, dass LMv2-Antworten bereitgestellt werden, die nicht zeitverschienen sind.

Was ist CBT (Kanalbindungstoken)?

Kanalbindungstoken (CHANNEL Binding Token, CBT) ist Teil des erweiterten Schutzes für die Authentifizierung. CBT ist ein Mechanismus zum Binden eines äußeren TLS-sicheren Kanals an die innere Kanalauthentifizierung wie Kerberos oder NTLM.

CBT ist eine Eigenschaft des äußeren sicheren Kanals, der zum Binden der Authentifizierung an den Kanal verwendet wird.

Erweiterter Schutz wird durch den Client erreicht, der spN und das CBT auf manipulationssichere Weise an den Server kommuniziert. Der Server überprüft die erweiterten Schutzinformationen in Übereinstimmung mit seiner Richtlinie und lehnt Authentifizierungsversuche ab, für die er nicht der Meinung ist, dass er das beabsichtigte Ziel war. So werden die beiden Kanäle kryptografisch miteinander verbunden.

Erweiterter Schutz wird jetzt in Windows XP, Windows Vista, Windows Server 2003 und Windows Server 2008 unterstützt.

Haftungsausschluss

Schnelle Veröffentlichungsartikel stellen Informationen direkt aus der Microsoft-Supportorganisation bereit. Die hierin enthaltenen Informationen werden als Reaktion auf neue oder eindeutige Themen erstellt oder sollen andere Wissensdatenbank Informationen ergänzen.

Microsoft und/oder deren Lieferanten machen keine Zusicherungen oder Garantien über die Eignung, Zuverlässigkeit oder Genauigkeit der Informationen, die in den Dokumenten und zugehörigen Grafiken enthalten sind, die auf dieser Website (die "Materialien") zu irgendeinem Zweck veröffentlicht wurden. Die Materialien können technische Ungenauigkeiten oder typografische Fehler enthalten und jederzeit ohne Vorheriges überarbeitet werden.

Im maximalen Umfang, der durch geltendes Recht erlaubt ist, lehnt Microsoft und/oder seine Lieferanten alle Vertretungen, Garantien und Bedingungen ab, unabhängig davon, ob ausdrücklich, konkludiert oder gesetzlich, einschließlich, aber nicht beschränkt auf Vertretungen, Garantien oder Bedingungen des Titels, Nichtverletzung, zufriedenstellende Bedingung oder Qualität, Händlerfreundlichkeit und Eignung für einen bestimmten Zweck, in Bezug auf die Materialien.