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."

re listed solution: Kerberos is more secure for exactly this reason -- the server is a trusted and known source with a guaranteed identity both in terms of address and process running at that address. A service account running as a different user would not be able to process your request. — Hogan
@hogan I would think that kerb/ntlm is more about authentication than authorization. Let me authenticate with any server using kerb; once I know who the service is, I can decide if I want to deal with them. If I authenticate with kerb I have the identity of the service provided by a trusted third party (AD). If the service is being spoofed, I can tell by that identity and throw an exception if it is not expected. In WCF, it appears a spoofed server would fail kerb and then pass with ntlm. That doesn't seem secure to me. Authenticate with anyone, throw if they aren't who I expected. — user1228

Michael Howard-MSFT Michael Howard-MSFT · Accepted Answer · 2010-02-23T22:16:27

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

Why is kerberos defaulting to NTLM in WCF?

4 Answers