Debuggen von Windows-Authentifizierungsfehlern

Bei verwendung der Windows-Authentifizierung als Sicherheitsmechanismus verarbeitet die SSPI (Security Support Provider Interface) Sicherheitsprozesse. Wenn Sicherheitsfehler auf der SSPI-Ebene auftreten, werden sie von Windows Communication Foundation (WCF) angezeigt. Dieses Thema enthält ein Framework und eine Reihe von Fragen zur Diagnose der Fehler.

Eine Übersicht über das Kerberos-Protokoll finden Sie unter Kerberos Erläutert; eine Übersicht über SSPI finden Sie unter SSPI.

Für die Windows-Authentifizierung verwendet WCF in der Regel den Negotiate Security Support Provider (SSP), der die kerberos-gegenseitige Authentifizierung zwischen Client und Dienst durchführt. Wenn das Kerberos-Protokoll nicht verfügbar ist, greift WCF standardmäßig auf NT LAN Manager (NTLM) zurück. Sie können WCF jedoch so konfigurieren, dass nur das Kerberos-Protokoll verwendet wird (und eine Ausnahme ausgelöst wird, wenn Kerberos nicht verfügbar ist). Sie können WCF auch so konfigurieren, dass eingeschränkte Formen des Kerberos-Protokolls verwendet werden.

Debugging-Methodik

Die grundlegende Methode lautet wie folgt:

Bestimmen Sie, ob Sie die Windows-Authentifizierung verwenden. Wenn Sie ein anderes Schema verwenden, gilt dieses Thema nicht.
Wenn Sie sicher sind, dass Sie die Windows-Authentifizierung verwenden, bestimmen Sie, ob Ihre WCF-Konfiguration Kerberos direct oder Negotiate verwendet.
Nachdem Sie festgestellt haben, ob Ihre Konfiguration das Kerberos-Protokoll oder NTLM verwendet, können Sie Fehlermeldungen im richtigen Kontext verstehen.

Verfügbarkeit des Kerberos-Protokolls und NTLM

Der Kerberos-SSP erfordert, dass ein Domänencontroller als Kerberos-Schlüsselverteilungscenter (Kerberos Key Distribution Center, KDC) fungiert. Das Kerberos-Protokoll ist nur verfügbar, wenn sowohl der Client als auch der Dienst Domänenidentitäten verwenden. In anderen Kontokombinationen wird NTLM verwendet, wie in der folgenden Tabelle zusammengefasst.

Die Tabellenüberschriften zeigen mögliche Kontotypen an, die vom Server verwendet werden. In der linken Spalte werden mögliche Kontotypen angezeigt, die vom Client verwendet werden.

	Lokaler Benutzer	Lokales System	Domänenbenutzer	Domänencomputer
Lokaler Benutzer	NTLM	NTLM	NTLM	NTLM
Lokales System	Anonymes NTLM	Anonymes NTLM	Anonymes NTLM	Anonymes NTLM
Domänenbenutzer	NTLM	NTLM	Kerberos	Kerberos
Domänencomputer	NTLM	NTLM	Kerberos	Kerberos

Insbesondere umfassen die vier Kontotypen Folgendes:

Lokaler Benutzer: Computergeschütztes Benutzerprofil. Beispiel: MachineName\Administrator oder MachineName\ProfileName.
Lokales System: Das integrierte Konto SYSTEM auf einem Computer, der nicht mit einer Domäne verknüpft ist.
Domänenbenutzer: Ein Benutzerkonto in einer Windows-Domäne. Beispiel: DomainName\ProfileName.
Domänencomputer: Ein Prozess mit Computeridentität, der auf einem Computer ausgeführt wird, der einer Windows-Domäne beigetreten ist. Beispiel: MachineName\Network Service.

Hinweis

Die Dienstanmeldeinformationen werden erfasst, wenn die Open Methode der ServiceHost Klasse aufgerufen wird. Die Clientanmeldeinformationen werden immer gelesen, wenn der Client eine Nachricht sendet.

Häufige Probleme bei der Windows-Authentifizierung

In diesem Abschnitt werden einige allgemeine Windows-Authentifizierungsprobleme und mögliche Abhilfemaßnahmen erläutert.

Kerberos-Protokoll

SPN/UPN-Probleme mit dem Kerberos-Protokoll

Wenn Sie die Windows-Authentifizierung verwenden und das Kerberos-Protokoll von SSPI verwendet oder ausgehandelt wird, muss die URL, die der Clientendpunkt verwendet, den vollqualifizierten Domänennamen des Diensthosts in der Dienst-URL enthalten. Dabei wird davon ausgegangen, dass das Konto, unter dem der Dienst ausgeführt wird, Zugriff auf den Computerschlüssel (Standarddienstprinzipalname, SPN) hat, der erstellt wird, wenn der Computer der Active Directory-Domäne hinzugefügt wird, was am häufigsten durch Ausführen des Diensts unter dem Netzwerkdienstkonto erfolgt. Wenn der Dienst keinen Zugriff auf den COMPUTER-SPN-Schlüssel hat, müssen Sie den richtigen SPN- oder Benutzerprinzipalnamen (User Principal Name, UPN) des Kontos angeben, unter dem der Dienst in der Endpunktidentität des Clients ausgeführt wird. Weitere Informationen zur Funktionsweise von WCF mit SPN und UPN finden Sie unter Dienstidentität und Authentifizierung.

In Szenarien zum Lastenausgleich, z. B. Webfarmen oder Webgärten, besteht eine gängige Methode darin, ein eindeutiges Konto für jede Anwendung zu definieren, diesem Konto einen SPN zuzuweisen und sicherzustellen, dass alle Dienste der Anwendung in diesem Konto ausgeführt werden.

Um ein SPN für das Konto Ihres Diensts abzurufen, müssen Sie ein Active Directory-Domänenadministrator sein. Weitere Informationen finden Sie in der technischen Ergänzung zu Kerberos für Windows.

Kerberos-Protokoll Direct erfordert, dass der Dienst unter einem Domänencomputerkonto ausgeführt wird

Dies tritt auf, wenn die ClientCredentialType-Eigenschaft auf Windows und die NegotiateServiceCredential-Eigenschaft auf false festgelegt wird, wie im folgenden Code dargestellt.

WSHttpBinding b = new WSHttpBinding();
// By default, the WSHttpBinding uses Windows authentication
// and Message mode.
b.Security.Message.NegotiateServiceCredential = false;

Dim b As New WSHttpBinding()
' By default, the WSHttpBinding uses Windows authentication 
' and Message mode.
b.Security.Message.NegotiateServiceCredential = False

Um abhilfe zu schaffen, führen Sie den Dienst mithilfe eines Domänencomputerkontos aus, z. B. Netzwerkdienst, auf einem in eine Domäne eingebundenen Computer.

Delegierung erfordert eine Anmeldeinformationen-Aushandlung

Um das Kerberos-Authentifizierungsprotokoll mit Delegierung zu verwenden, müssen Sie das Kerberos-Protokoll mit der Aushandlung von Anmeldeinformationen implementieren (manchmal auch als "Multi-Leg" oder "Multi-Step" Kerberos bezeichnet). Wenn Sie die Kerberos-Authentifizierung ohne Anmeldeinformationen-Aushandlung (mitunter als "One-Shot"-Kerberos bezeichnet) implementieren, wird eine Ausnahme ausgelöst.

Führen Sie die folgenden Schritte aus, um Kerberos mit Authentifizierungsverhandlung zu implementieren:

Implementieren Sie die Delegierung durch Festlegen AllowedImpersonationLevel auf Delegation.
SSPI-Aushandlung erforderlich:
1. Wenn Sie Standardbindungen verwenden, legen Sie die NegotiateServiceCredential Eigenschaft auf true.
2. Wenn Sie benutzerdefinierte Bindungen verwenden, legen Sie das AuthenticationMode Attribut des Security Elements auf SspiNegotiated.
Legen Sie fest, dass die SSPI-Aushandlung Kerberos verwenden muss, indem Sie die Verwendung von NTLM nicht zulasssen:
1. Führen Sie dies im Code mit der folgenden Anweisung aus: ChannelFactory.Credentials.Windows.AllowNtlm = false
2. Sie können dies auch in der Konfigurationsdatei tun, indem Sie das allowNtlm-Attribut auf das false setzen. Dieses Attribut ist in den <Fenstern> enthalten.

NTLM-Protokoll

SSP-Aushandlung greift auf NTLM zurück, NTLM ist jedoch deaktiviert

Die AllowNtlm Eigenschaft ist auf false gesetzt, wodurch die Windows Communication Foundation (WCF) nach besten Kräften versucht, eine Ausnahme auszulösen, wenn NTLM verwendet wird. Wenn Sie diese Eigenschaft auf false festlegen, kann möglicherweise nicht verhindert werden, dass NTLM-Anmeldeinformationen übertragen werden.

Im Folgenden wird gezeigt, wie Fallback in NTLM deaktiviert wird.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.Windows.AllowNtlm = false;

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.Windows.AllowNtlm = False

Fehler bei der NTLM-Anmeldung

Die Clientanmeldeinformationen sind für den Dienst ungültig. Überprüfen Sie, ob der Benutzername und das Kennwort korrekt festgelegt sind und einem Konto entsprechen, das dem Computer bekannt ist, auf dem der Dienst ausgeführt wird. NTLM verwendet die angegebenen Anmeldeinformationen, um sich beim Computer des Diensts anzumelden. Während die Anmeldeinformationen möglicherweise auf dem Computer gültig sind, auf dem der Client ausgeführt wird, schlägt diese Anmeldung fehl, wenn die Anmeldeinformationen auf dem Computer des Diensts nicht gültig sind.

Eine anonyme NTLM-Anmeldung tritt auf, obwohl anonyme Anmeldungen standardmäßig deaktiviert sind.

Beim Erstellen eines Clients wird die AllowedImpersonationLevel Eigenschaft auf Anonymous, wie im folgenden Beispiel gezeigt, festgelegt, aber standardmäßig verbietet der Server anonyme Anmeldungen. Dies tritt auf, da der Standardwert der AllowAnonymousLogons Eigenschaft der WindowsServiceCredential Klasse lautet false.

Der folgende Clientcode versucht, anonyme Anmeldungen zu aktivieren (beachten Sie, dass die Standardeigenschaft ist Identification).

CalculatorClient cc =
    new CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.Windows.AllowedImpersonationLevel =
System.Security.Principal.TokenImpersonationLevel.Anonymous;

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.Windows.AllowedImpersonationLevel = _
System.Security.Principal.TokenImpersonationLevel.Anonymous

Der folgende Dienstcode ändert die Standardeinstellung, um anonyme Anmeldungen vom Server zu aktivieren.

Uri httpUri = new Uri("http://localhost:8000/");
ServiceHost sh = new ServiceHost(typeof(Calculator), httpUri);
sh.Credentials.WindowsAuthentication.AllowAnonymousLogons = true;

Dim httpUri As New Uri("http://localhost:8000/")
Dim sh As New ServiceHost(GetType(Calculator), httpUri)
sh.Credentials.WindowsAuthentication.AllowAnonymousLogons = True

Weitere Informationen zur Delegierung und zum Identitätswechsel finden Sie unter Delegierung und Identitätswechsel.

Alternativ wird der Client als Windows-Dienst mit dem integrierten KontoSYSTEM ausgeführt.

Andere Probleme

Client-Anmeldeinformationen sind nicht korrekt konfiguriert.

Die Windows-Authentifizierung verwendet die WindowsClientCredential Instanz, die von der ClientCredentials Eigenschaft der ClientBase<TChannel> Klasse zurückgegeben wird, nicht die UserNamePasswordClientCredential. Das folgende zeigt ein fehlerhaftes Beispiel.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
cc.ClientCredentials.UserName.UserName = GetUserName(); // wrong!
cc.ClientCredentials.UserName.Password = GetPassword(); // wrong!

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
cc.ClientCredentials.UserName.UserName = GetUserName() ' wrong!
cc.ClientCredentials.UserName.Password = GetPassword() ' wrong!

Das Folgende zeigt das korrekte Beispiel.

CalculatorClient cc = new
    CalculatorClient("WSHttpBinding_ICalculator");
// This code returns the WindowsClientCredential type.
cc.ClientCredentials.Windows.ClientCredential.UserName = GetUserName();
cc.ClientCredentials.Windows.ClientCredential.Password = GetPassword();

Dim cc As New CalculatorClient("WSHttpBinding_ICalculator")
' This code returns the WindowsClientCredential type.            
cc.ClientCredentials.Windows.ClientCredential.UserName = GetUserName()
cc.ClientCredentials.Windows.ClientCredential.Password = GetPassword()

SSPI ist nicht verfügbar.

Die folgenden Betriebssysteme unterstützen die Windows-Authentifizierung nicht, wenn sie als Server verwendet wird: Windows XP Home Edition, Windows XP Media Center Edition und Windows Vista Home Edition.

Entwickeln und Bereitstellen mit unterschiedlichen Identitäten

Wenn Sie Ihre Anwendung auf einem Computer entwickeln und auf einem anderen Computer bereitstellen und unterschiedliche Kontotypen für die Authentifizierung auf jedem Computer verwenden, treten möglicherweise unterschiedliche Verhaltensweisen auf. Angenommen, Sie entwickeln Ihre Anwendung auf einem Windows XP Pro-Computer mithilfe des SSPI Negotiated Authentifizierungsmodus. Wenn Sie ein lokales Benutzerkonto für die Authentifizierung verwenden, wird das NTLM-Protokoll verwendet. Nachdem die Anwendung entwickelt wurde, stellen Sie den Dienst auf einem Windows Server 2003-Computer bereit, auf dem er unter einem Domänenkonto ausgeführt wird. An diesem Punkt kann der Client den Dienst nicht authentifizieren, da er Kerberos und einen Domänencontroller verwendet.

Siehe auch

Last updated on 2025-06-19