Authentifizierungsfehler von Nicht-Windows NTLM- oder Kerberos-Servern

  • Artikel

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

Gilt für: Windows 7 Service Pack 1, Windows Server 2012 R2
Ursprüngliche KB-Nummer: 976918

Symptome

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

Möglicherweise treten eines oder mehrere der folgenden Symptome auf:

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

Ursache

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

Dies ist standardmäßig ON. Wenn ein Client versucht, eine Verbindung mit einem Server herzustellen, wird die Authentifizierungsanforderung an den verwendeten Dienstprinzipalnamen (Service Principal Name, SPN) gebunden. Auch wenn die Authentifizierung in einem TLS-Kanal (Transport Layer Security) stattfindet, 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

Bei Fehlern, bei denen Nicht-Windows-NTLM- oder Kerberos-Server beim Empfang von CBT fehlschlagen, wenden Sie sich an den Anbieter, um eine Version zu erhalten, die CBT ordnungsgemäß behandelt.

Bei Fehlern, bei denen Nicht-Windows NTLM-Server oder Proxyserver LMv2 erfordern, wenden Sie sich an den Hersteller, um eine Version zu erhalten, 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 ist es wichtig, bei der Ausführung der folgenden Schritte sorgfältig vorzugehen. Für zusätzlichen Schutz sichern Sie die Registrierung, bevor Sie sie ändern. Sie können die Registrierung wiederherstellen, wenn ein Problem auftritt. Weitere Informationen zum Sichern und Wiederherstellen der Registrierung finden Sie unter Sichern und Wiederherstellen der Registrierung in Windows .

Um das Verhalten des erweiterten Schutzes zu steuern, erstellen Sie den folgenden Registrierungsunterschlüssel:

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

Für Windows-Clients, die Kanalbindung unterstützen, die nicht von Nicht-Windows Kerberos-Servern authentifiziert werden können, die das CBT nicht ordnungsgemäß verarbeiten:

  1. Legen Sie den Registrierungseintragswert auf 0x01 fest. Dadurch wird Kerberos so konfiguriert, dass keine 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 so konfiguriert, dass keine CBT-Token ausgegeben werden.

Hinweis

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 ignoriert, was auch dann erfolgreich ist, wenn der Initiator Kanalbindungen gemäß RFC 4121 übergeben hat. Weitere Informationen finden Sie unter Ignorieren der eingehenden Kanalbindung, wenn acceptor keines festgelegt hat.

Es wird empfohlen, das folgende Update von der Sun Java-Website zu installieren und den erweiterten Schutz erneut zu aktivieren: Änderungen in 1.6.0_19 (6u19).We recommend you install the following update from the Sun Java site and re-enable extended protection: Changes in 1.6.0_19 (6u19).

Legen Sie für Windows-Clients, die Kanalbindung unterstützen, die nicht von Windows NTLM-Servern authentifiziert werden können, die das CBT nicht ordnungsgemäß behandeln, den Registrierungseintragswert auf 0x01 fest. Dadurch wird NTLM so konfiguriert, dass keine 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 Zeit 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 keiner Zeitschiefe unterliegen.

Was ist CBT (Channel Binding Token)?

Channel Binding Token (CBT) ist Teil des erweiterten Schutzes für die Authentifizierung. CBT ist ein Mechanismus zum Binden eines äußeren sicheren TLS-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 dadurch erreicht, dass der Client den SPN und das CBT manipulationssicher an den Server kommuniziert. Der Server überprüft die erweiterten Schutzinformationen gemäß seiner Richtlinie und lehnt Authentifizierungsversuche ab, für die er nicht glaubt, dass sie das beabsichtigte Ziel waren. Auf diese Weise 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

Artikel zur schnellen Veröffentlichung bieten Informationen direkt aus dem Microsoft-Support-organization. Die hierin enthaltenen Informationen werden als Reaktion auf neue oder einzigartige Themen erstellt oder sollen andere Wissensdatenbank Informationen ergänzen.

Microsoft und/oder seine Lieferanten übernehmen keine Zusicherungen oder Gewährleistungen hinsichtlich der Eignung, Zuverlässigkeit oder Genauigkeit der Informationen, die in den auf dieser Website veröffentlichten Dokumenten und zugehörigen Grafiken (die "Materialien") enthalten sind, für irgendeinen Zweck. Die Materialien können technische Ungenauigkeiten oder typografische Fehler enthalten und können jederzeit ohne Vorankündigung überarbeitet werden.

Microsoft und/oder seine Lieferanten lehnen alle ausdrücklichen, stillschweigenden oder gesetzlichen Zusicherungen, Gewährleistungen und Bedingungen ab, einschließlich, aber nicht beschränkt auf Zusicherungen, Gewährleistungen oder Eigentumsbedingungen, Nichtverletzung, zufriedenstellender Zustand oder Qualität, Handelsüblichkeit und Eignung für einen bestimmten Zweck in Bezug auf die Materialien.