Why does kerberos not match NTLM in WCF?

Question

Got a simple WCF demo application with two console projects - a host and a client. Both run on my machine (win 7). I am using netTcpBinding, which uses windows authentication.

The problem is that authentication is downgraded to NTLM from kerberos, and I cannot understand why.

If i use

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

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

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

This suggests that kerberos fails, and since the client does not allow NTLM, the call throws an exception.

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

---

Decision:

Apparently, I should indicate the server identifier in the client configuration. In my case, the server runs under my identity, so I change the client this way:

 <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 am not sure why this fixes the problem. OK, now on the client side, I completely trust the server (hey, I know this guy!). But since NTLM is less secure than kerberos, why not? If I do not fully trust the server, I use kerberos, otherwise ntlm is fine.

Or, OTOH, if I do not fully trust the server, why does it work at all? "SecurityException: endpoint identifier not set. WCF cannot trust the server identifier and not pass the client identifier."

Answer 1

When I worked on the IIS4, 5, and 6 development teams, we came across this a lot! For Curb to work, you will need the following conditions:

1) Both sides support curb (all supported versions of Windows Curb support today)

2) auth machines in Active Directory

3) Primary Service Names (SPNs) registered for the server endpoint. In the "good old days" you had to do it manually using SetSPN.exe. SPN is just the endpoint that Curb will connect to; he needs this data to support mutual access. Most applications call the Approp API for this to work for you (DsWriteAccountSpn)

If any of the above steps is not true, Windows will usually use NTLM by default, which only gives you client authentication.

Hope this helps! - Michael

Answer 2

How is the server configured? Do you have <authentication mode="Windows"/> and <identity impersonate="true"/> in the configuration file?

You set the authentication mode using the authentication tag in the configuration file:

 <configuration> <system.web> <authentication mode="Windows" /> </system.web> </configuration> 

Answer 3

Perhaps this MSDN page - Debugging Windows Authentication Errors - will help you understand what is happening - it seems pretty complicated when NTLM and Kerberos are used.

Answer 4

Fyi via MSDN: netTcpBinding: the default binding uses transport security with consistent authentication. This negotiation attempts to use Kerberos, but if it does not work, it will back off and will use the older NTLM protocol . Kerberos is a great choice if you are in a domain environment; to use it, you will need both your service and clients to work under domain accounts. You will also want to configure the service principal name (SPN) for your service.