Debuggen von Windows-Authentifizierungsfehlern

Artikel
02/27/2011

Bei Verwendung der Windows-Authentifizierung als Sicherheitsmechanismus wickelt die Security Support Provider-Schnittstelle (SSPI) Sicherheitsprozesse ab. Wenn Sicherheitsfehler auf der SSPI-Schicht auftreten, werden sie von Windows Communication Foundation (WCF) festgestellt. 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 Explained (Seite möglicherweise auf Englisch); eine Übersicht über SSPI finden Sie unter (Seite möglicherweise auf Englisch).

Für die Windows-Authentifizierung verwendet WCF normalerweise die SSP-Aushandlung (Negotiate Security Support Provider), bei der die gegenseitige Kerberos-Authentifizierung zwischen Client und Dienst ausgeführt wird. 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 dass 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.

Debugmethodik

Die grundlegende Methode lautet wie folgt:

Bestimmen Sie, ob Sie die Windows-Authentifizierung verwenden. Wenn Sie ein anderes Schema verwenden, ist dieses Thema irrelevant.
Wenn Sie sicher sind, dass Sie die Windows-Authentifizierung verwenden, bestimmen Sie, ob Ihre WCF-Konfiguration Kerberos direkt 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 von NTLM

Der Kerberos SSP erfordert einen Domänencontroller, der als 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 Tabellenheader zeigen mögliche vom Server verwendete Kontotypen. Die linke Spalte zeigt mögliche vom Client verwendete Kontotypen.

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

Zu den vier Kontotypen gehören im Einzelnen:

Lokaler Benutzer: Nur Computerbenutzerprofil. 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 auf einer Windows-Domäne. Beispiel: DomainName\ProfileName.
Domänencomputer: Ein Prozess mit Computeridentität, der auf einem Computer ausgeführt wird, der mit einer Windows-Domäne verknüpft ist. Beispiel: MachineName\Network Service.

Hinweis:
Die Dienstanmeldeinformationen werden aufgezeichnet, wenn die Open-Methode der ServiceHost-Klasse aufgerufen wird. Die Clientanmeldeinformationen werden immer dann gelesen, wenn der Client eine Nachricht sendet.

Allgemeine Windows-Authentifizierungsprobleme

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

Kerberos-Protokoll

SPN-/UPN-Probleme mit dem Kerberos-Protokoll

Bei Verwendung der Windows-Authentifizierung und des Kerberos-Protokolls oder der Aushandlung durch SSPI muss die vom Clientendpunkt verwendete URL den vollqualifizierten Domänennamen des Diensthosts in der Dienst-URL enthalten. Dies setzt voraus, dass das Konto, unter dem der Dienst ausgeführt wird, Zugriff auf den (Standard-) Dienstprinzipalnamen-Schlüssel (SPN) hat, der beim Hinzufügen des Computers zur Active Directory-Domäne erstellt wird. Dieser Vorgang wird im Allgemeinen durchgeführt, indem der Dienst unter dem Netzwerkdienstkonto ausgeführt wird. Wenn der Dienst keinen Zugriff auf den SPN-Schlüssel des Computers hat, müssen Sie den korrekten SPN oder Benutzerprinzipalnamen (UPN) des Kontos, unter dem der Dienst ausgeführt wird, in der Endpunktidentität des Clients angeben. Weitere Informationen über darüber, wie WCF mit SPN und UPN arbeitet, finden Sie unter Dienstidentität und Authentifizierung.

Eine gängige Praxis für Lastenausgleichszenarien (beispielsweise bei Webfarmen und Webgärten) ist das Definieren eines eindeutigen Kontos für die einzelnen Anwendungen. Anschließend wird dem Konto ein SPN zugewiesen und sichergestellt, dass alle Dienste der Anwendung in diesem Konto ausgeführt werden.

Zum Erhalten eines SPN für das Konto des Diensts müssen Sie Active Directory-Domänenadministrator sein. Weitere Informationen finden Sie unter Technische Kerberos-Ergänzung für Windows (möglicherweise in englischer Sprache).

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

Dieser Fehler tritt auf, wenn die ClientCredentialType-Eigenschaft auf Windows und die NegotiateServiceCredential-Eigenschaft auf false festgelegt ist, wie im folgenden Code dargestellt.

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

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

Zum Beheben des Fehlers führen Sie den Dienst mit einem Domänencomputerkonto, wie Netzwerkdienst, auf einem Computer aus, der mit einer Domäne verknüpft ist.

Delegierung erfordert Anmeldeinformationen-Aushandlung

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

Um Kerberos mit Anmeldeinformationen-Aushandlung zu implementieren, führen Sie die folgenden Schritte aus:

Implementieren Sie die Delegierung, indem Sie AllowedImpersonationLevel auf Delegation festlegen.
SSPI-Aushandlung erforderlich:
1. Wenn Sie Standardbindungen verwenden, legen Sie die NegotiateServiceCredential-Eigenschaft auf true fest.
2. Bei Verwendung von benutzerdefinierten Bindungen legen Sie das AuthenticationMode-Attribut des Security-Elements auf SspiNegotiated fest.
Legen Sie fest, dass die SSPI-Aushandlung Kerberos verwenden muss, indem Sie die Verwendung von NTLM nicht zulasssen:
1. Führen Sie dies mit der folgenden Anweisung in Code aus: ChannelFactory.Credentials.Windows.AllowNtlm = false
2. Sie können diese Einstellung auch in der Konfigurationsdatei vornehmen, indem Sie das allowNtlm-Attribut auf false festlegen. Dieses Attribut ist in <windows> of <clientCredentials> element enthalten.

NTLM-Protokoll

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

Die AllowNtlm-Eigenschaft ist auf false festgelegt, wodurch von Windows Communication Foundation (WCF) ein Best-Effort-Versuch unternommen wird, um bei Verwendung von NTLM eine Ausnahme auszulösen. Durch das Festlegen dieser Eigenschaft auf false wird unter Umständen nicht verhindert, dass NTLM-Anmeldeinformationen über die Verbindung gesendet werden.

Die folgenden Schritte zeigen, wie ein Zurückgreifen auf NTLM deaktiviert wird.

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

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

Fehler bei der NTLM-Anmeldung

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

Anonyme NTLM-Anmeldung wird ausgeführt, anonyme Anmeldungen sind jedoch standardmäßig deaktiviert

Beim Erstellen eines Clients wird die AllowedImpersonationLevel-Eigenschaft auf Anonymous festgelegt, wie im folgenden Beispiel veranschaulicht. Standardmäßig lässt der Server allerdings keine anonymen Anmeldungen zu. Dies tritt auf, da der Standardwert der AllowAnonymousLogons-Eigenschaft der WindowsServiceCredential-Klasse false ist.

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

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

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

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

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

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

Weitere Informationen über zum Identitätswechsel finden Sie unter Delegierung und Identitätswechsel mit WCF.

Alternativ wird der Client als Windows-Dienst ausgeführt und verwendet das integrierte Konto-SYSTEM.

Andere Probleme

Clientanmeldeinformationen werden nicht ordnungsgemäß festgelegt.

Die Windows-Authentifizierung verwendet die WindowsClientCredential-Instanz, die von der ClientCredentials-Eigenschaft der ClientBase-Klasse zurückgegeben wird, nicht UserNamePasswordClientCredential. Im Folgenden wird ein nicht korrektes Beispiel dargestellt.

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

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

Im Folgenden wird ein korrektes Beispiel dargestellt.

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()

CalculatorClient cc = 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 bei Verwendung als Server die Windows-Authentifizierung nicht: Windows XP Home Edition, Windows XP Media Center Edition und Windows Vista Home.

Entwickeln und Bereitstellen mit unterschiedlichen Identitäten

Wenn Sie Ihre Anwendung auf einem bestimmten Computer entwickeln, die Anwendung anschließend auf einem anderen Computer bereitstellen und dabei unterschiedliche Kontotypen für die Authentifizierung verwenden, kann es vorkommen, dass sich das Verhalten von Computer zu Computer unterscheidet. Ein Beispiel: Angenommen, Sie entwickeln Ihre Anwendung auf einem Computer unter Windows XP Pro und verwenden dabei den SSPI Negotiated-Authentifizierungsmodus. Wenn die Authentifizierung unter Verwendung eines lokalen Benutzerkontos erfolgt, wird das NTLM-Protokoll verwendet. Nachdem die Entwicklung der Anwendung abgeschlossen ist, stellen Sie den Dienst für einen Computer unter Windows Server 2003 bereit, wo er im Rahmen eines Domänenkontos ausgeführt wird. Der Dienst kann nun nicht mehr vom Client authentifiziert werden, da nun Kerberos und ein Domänencontroller verwendet werden.

Siehe auch

Verweis

WindowsClientCredential
WindowsServiceCredential
WindowsClientCredential
ClientBase

Konzepte

Delegierung und Identitätswechsel mit WCF
Nicht unterstützte Szenarien

Freigeben über