WCF Die SSPI-Aushandlung (Security Support Provider Interface) ist fehlgeschlagen

Question

Ich benutze einen von mir erstellten Dienst, wenn sowohl der Host als auch der Client auf der gleichen Domäne arbeiten, funktioniert alles einwandfrei. Wenn ich die Client-Anwendung auf den Webserver in der DMZ veröffentlichen Ich bin den folgenden Fehler erhalten:

SOAP security negotiation with 'http://10.0.0.14:3790/Bullfrog/QBService/QBService' for 
target 'http://10.0.0.14:3790/Bullfrog/QBService/QBService' failed. See inner exception 
for more details.The Security Support Provider Interface (SSPI) negotiation failed. 

Hier ist mein Service Haupt wo ich den Dienst

 Uri baseAddress = new Uri("Http://10.0.0.14:3790/Bullfrog/QBService"); 
     ServiceHost selfHost = new ServiceHost(typeof(QBService), baseAddress); 

      try 
      { 
       selfHost.AddServiceEndpoint(
        typeof(IQBService), 
        new WSHttpBinding(), 
        "QBService"); 

       ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); 
       smb.HttpGetEnabled = true; 
       selfHost.Description.Behaviors.Add(smb); 
       selfHost.Open(); 

       Console.WriteLine("The service is ready"); 


      } 
      catch (CommunicationException ce) 
      { 
       //log.Error(ce.Message, ce); 
       Console.WriteLine(ce.Message, ce); 
       selfHost.Abort(); 
      } 

und hier eingestellt ist die Config Abschnitt auf meinem Client

<system.serviceModel> 
<bindings> 
    <wsHttpBinding> 
    <binding name="WSHttpBinding_IQBService" closeTimeout="00:01:00" 
     openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" 
     bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" 
     maxBufferPoolSize="524288" maxReceivedMessageSize="65536" 
     messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" 
     allowCookies="false"> 
     <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
      maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
     <reliableSession ordered="true" inactivityTimeout="00:10:00" 
      enabled="false" /> 
     <security mode="Message"> 
     <transport clientCredentialType="Windows" proxyCredentialType="None" 
      realm="" /> 
     <message clientCredentialType="Windows" negotiateServiceCredential="true" 
      algorithmSuite="Default" /> 
     </security> 
    </binding> 
    </wsHttpBinding> 
</bindings> 
<client> 
    <endpoint address="http://10.0.0.14:3790/Bullfrog/QBService/QBService" 
     binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IQBService" 
     contract="IQBService" name="WSHttpBinding_IQBService"> 
    <identity> 
     <userPrincipalName value="Administrator@bullfrogspas.local" /> 
    </identity> 
    </endpoint> 
</client> 

ich bin sicher, dass die Problem ist, weil es Windows-Authentifizierung verwendet. Irgendwelche Ideen? Danke!

Answer 1

Ich denke nicht, dass dies funktioniert und ich habe keine Umgebung, um es schnell zu testen. SSPI verwendet NTLM oder Kerberos (obligatorisch, wenn die Aushandlung der Dienstanmeldeinformationen nicht verwendet wird), um den Dienst auf dem Client und dem Client auf dem Dienst zu authentifizieren. Sowohl NTLM als auch Kerberos erwarten dieselbe Domäne oder vertrauenswürdige Domänen.

Wenn Sie die Nachrichtensicherheit verwenden möchten, können Sie Ihre Konfiguration so ändern, dass Zertifikate oder Benutzername + Passwort verwendet werden (der Dienst benötigt weiterhin ein Zertifikat). Sie können den Benutzernamen und das Kennwort im aktiven Verzeichnis oder in einem anderen Anmeldedatenspeicher überprüfen.

Denken Sie daran, dass die Nachrichtensicherheit die langsamste ist. Bessere Leistung kann mit Transportsicherheit (HTTPS) erreicht werden - es kann durch Netzwerkgeräte beschleunigt werden. Wenn Sie HTTPS verwenden, können Sie es mit der Standardauthentifizierung kombinieren und Client-Anmeldeinformationen aus Ihrem Code bereitstellen, sodass Sie den Dienst in Ihrer internen Zone aufrufen und die Domänenanmeldeinformationen für die Authentifizierung verwenden. Der Dienst wird anhand seines für HTTPS verwendeten Zertifikats authentifiziert. HTTPS ermöglicht auch eine gegenseitige Zertifikatauthentifizierung, bei der der Client ein Zertifikat an den Dienst sendet - wenn das korrekt konfigurierte Clientzertifikat dem Domänenkonto zugeordnet werden kann. Diese beiden Ansätze ähneln den erwähnten Ansätzen in der Nachrichtensicherheit, aber anstelle des Sendens von Berechtigungsnachweisen im SOAP-Header wird der HTTP-Header verwendet.

Answer 2

Ich denke, Sie sollten den folgenden Code in Ihrer web.config

<identity> 
     <userPrincipalName value="Administrator@bullfrogspas.local" /> 
</identity> 

sagen, da es mein Problem gelöst.