开发者

wcf 4 / iis / server 2008 windows authentication anomaly

开发者 https://www.devze.com 2023-03-06 04:58 出处:网络
I have a test WCF 4 service running on an Windows 2008 / IIS 7.5 in a domain. I am using Windows authentication on the binding.

I have a test WCF 4 service running on an Windows 2008 / IIS 7.5 in a domain.

I am using Windows authentication on the binding.

When I access this service from a .net windows client :

var b = new BasicHttpBinding(BasicHttpSecurityMode.TransportCredentialOnly);
b.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;
EndpointAddress a = new EndpointAddress("http://server/TestService.svc");
TestServiceClient tsc = new Tes开发者_StackOverflowtServiceClient(b, a);                                  

It works if I use:

 tsc.ChannelFactory.Credentials.Windows.ClientCredential = new NetworkCredential("bob.jones", "password", "DOMAIN");

It fails if I use:

tsc.ChannelFactory.Credentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;

When it fails I see a 401 in Fiddler : "401 - Unauthorized: Access is denied due to invalid credentials."

Whe it succeeds I see the same 401 but then a 200 and I can see a kerboros ticket in the request and response.

Here is my service config:

<system.serviceModel>

<bindings>
  <basicHttpBinding>
    <binding>
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Windows" proxyCredentialType="Windows"/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />


Seeing that no one else seems interested, I guess I'll have to answer this myself.

There were many little parts to the problem, but I'll just give an overview of what I found :

  1. I had to use the provider "Negotiate:Kerberos" and not "Negotiate".

  2. I had to configure the server principle name (spn) for the domain account I was using for the application pool :

    setspn -A HTTP/ServerName:port Domain\UserName

    setspn -A HTTP/FQDN:port Domain\UserName

  3. Another thing I noticed later on a different service, where the client app didn't specify the exact BasicHttpSecurityMode.TransportCredentialOnly and ClientCredentialType = HttpClientCredentialType.Windows, was that different client machines required "Negotiate" and others required "Negotiate:Kerberos". I haven't figured out if I can control that yet.

0

精彩评论

暂无评论...
验证码 换一张
取 消