Why is kerberos defaulting to NTLM in WCF?

Question

Got a simple WCF demo app that has two console projects--host and client. Both are running on my machine (win 7 box). I'm using the netTcpBinding, which uses windows authentication.

The issue is that authentication is downgrading to NTLM from kerberos, and I can't figure out why.

If I use

<clientCredentials>
   <windows allowNtlm="true" />
</clientCredentials>

on the client side, everything is cool. But if I change that to false, I get the following exception:

SecurityNegotiationException: The remote server did not satisfy the mutual authentication requirement.

This suggests that kerberos is failing and since the client won't allow NTLM the call results in an exception being thrown.

Is this an issue with the project, or is it an external issue caused by the configuration of my development machine?

---

Solution:

Apparently, I have to specify the identity of the server within the client configuration. In my case, the server is running under my identity, so I modify the client thusly:

<client>
  <endpoint address="net.tcp://dev7.HurrDurr.com:12345/MyService" 
            binding="netTcpBinding" 
            bindingConfiguration="MyBindingConfigurationLol" 
            behaviorConfiguration="HurrDurrServiceEndpoint" 
            contract="ShaolinCore.ICommunicationService">
    <!-- start changes here -->
    <identity>
      <userPrincipalName value="myusername@mydomain"/>
    </identity>
    <!-- end changes here -->
  </endpoint>
</client>

I'm not sure why this fixes the issue. Okay, now on the client side I fully trust the server (hey, I know that guy!). But since NTLM is less secure than kerberos, why isn't it the other way around? If I don't fully trust the server, I use kerberos, otherwise ntlm is fine.

Or, OTOH, if I don't fully trust the server why does it work at all? "SecurityException: Endpoint identity not set. WCF cannot trust the identity of the server and will not transmit client identity."

Answer 1

When I worked on the IIS4, 5 and 6 development teams we ran into this a lot! For Kerb to work, you need the following conditions to be true:

1) Both parties support kerb (all supported versions of Windows support Kerb today)

2) Machines auth to Active Directory

3) Service Principal Names (SPNs) registered for the server endpoint. In the "good old days" you had to do this by hand using SetSPN.exe. An SPN is just an endpoint that Kerb will connect to; it needs this data to support mutual authn. Most apps will call the approp API to this work for you (DsWriteAccountSpn)

If any of the steps above are not true, Windows will usually default to NTLM, whcih gives you only client authentication.

Hope that helps! - Michael