Ich muss einen WCF-Dienst programmgesteuert aufrufen. Der Dienst kann mit NTLM- oder Kerberos-Authentifizierung gehostet werden und muss unter beiden ausgeführt werden. Das heißt, wenn die Verbindung mit dem Dienst über Kerberos fehlschlägt, sollte es auf NTLM zurückgreifen.
Hier ist der Code, den ich für die Kerberos-Authentifizierung verwende (falls der Service in SharePoint 2010 gehostet wird und von einem Webpart aus aufgerufen wird):
%Vor%Wenn eine Methode auf dem Proxy aufgerufen wird, wenn sie in einer NTLM-Umgebung ausgeführt wird, wird folgender Fehler angezeigt:
Die HTTP-Anfrage ist nicht autorisiert mit Client-Authentifizierungsschema 'Verhandeln'. Der Authentifizierungsheader Vom Server wurde 'NTLM' empfangen.
Hinweis: Die URL befindet sich möglicherweise in einer anderen Webanwendung auf einem anderen Server. Ich kann nicht überprüfen, unter welcher Authentifizierung die Webanwendung des Webparts ausgeführt wird, und nehme an, dass sie mit der des WCF-Dienstes identisch ist.
Wie kann ich (automatisch oder manuell) sicherstellen, dass die Authentifizierung bei einem Fehler von Kerberos auf NTLM zurückfällt?
Aktualisierung:
Wie bereits erwähnt, tritt der Authentifizierungsfehler auf, wenn eine Webmethode aufgerufen wird. Ich möchte jedoch nicht so lange warten, da mehrere Web-Methoden im Service von mehreren Stellen aus aufgerufen werden. Ich möchte die Authentifizierung an dem Punkt testen, an dem der Proxy konfiguriert ist (im Code-Snippet oben).
Ich habe versucht, proxy.Open() zu verwenden, aber das scheint den Fehler nicht zu verursachen.
Ich habe keine Möglichkeit gefunden, dies automatisch zu tun. Stattdessen habe ich der Anwendung eine Benutzeroberfläche hinzugefügt, wo der Typ der Authentifizierung ausgewählt werden muss.
Das ist ein bisschen kurvig, aber warum fällt es auf NTLM zurück? Ich hatte erhebliche Schwierigkeiten mit der Sicherheit im Active Directory und WCF alle im Zusammenhang mit Service Principal Names (SPNs).
Kerberos schlägt fehl, wenn Sie den Dienst als etwas anderes als den Netzwerkdienst ausführen, es sei denn, Sie haben einen SPN in der Domäne für Ihren Dienst deklariert. Um den SPN zu setzen, benötigen Sie das windows server administrative kit mit dem Befehl setspn.
%Vor%Dadurch kann Kerberos Client-Anmeldeinformationen für Ihren Dienst innerhalb der Domäne freigeben.
Bitte lesen Sie etwas, da Sie Kerberos für andere Dienste, die auf der gleichen Box ausgeführt werden, abhängig von Ihrer Einrichtung brechen können.
(Ich erkenne, dass der ursprüngliche Beitrag sehr alt ist.)
Können Sie etwas anderes als BasicHttpBinding (wie WsHttpBinding) verwenden? Laut diesem Artikel ist BasicHttpBinding die einzige Ausnahme von der Bindung Objekte, indem es nicht automatisch verhandelt. Aus diesem Grund hat allowNTLM keine Wirkung.
Ich hatte die gleiche Fehlermeldung, die ich über hier und löste es durch Erstellen eines dynamischen Endpunkts wie folgt:
%Vor%Ich habe den WCF-Dienst als spezifischen Active Directory-Benutzer und nicht als Standard NETWORK_SERVICE ausgeführt.
Ich nehme an, dass Sie den vollständigen DNS-Namen des Servers als die Adresse des Dienstes verwenden. Versuchen Sie, den NETBIOS-Namen oder die IP-Adresse zu verwenden. Das sollte es zwingen, NTLM zu benutzen.
Wenn Sie wissen, welches Protokoll der Server verwendet, können Sie Ihre App so konfigurieren, dass sie entweder den vollständigen Namen oder die IP verwendet.
Hoffe, dass das für dich funktioniert.
Tags und Links wcf authentication kerberos sharepoint ntlm