Mutual authentication using Kerberos
I am currently attempting to understand how to configure a WCF client / WCF service to be mutually authenticated via Kerberos. I would like to self-host the WCF service in a Windows service, running under a Windows domain account (MyDomain\WCFHost). From reading various posts in this forum, my understanding is that using this configuration will cause svcutil to generate the following identity element in the client's configuration:
<identity>
<userPrincipalName value="WCFHost@MyDomain.com"/>
</identity>
One of the requirements I have is for the client to be able to determine whether the WCF service has been spoofed. Using the UPN as part of a mutual authentication sequence appears to be a way of doing this: in order to successfully impersonate the WCF service, any attacker would have to obtain the password of the MyDomain\WCFHost account (as well as changing DNS settings etc). However, when I set all of this up (using the September CTP, with client and server on two different machines) I get the following results:
1. With the UPN at the client end set to WCFHost@MyDomain.com, and the WCF service running as MyDomain\WCFHost, all works OK
2. With the UPN at the client end set to DoesNotExist@MyDomain.com (this account does not exist in the AD), and the WCF service running as MyDomain\WCFHost, client reports error "Security Support Provider Interface (SSPI) authentication failed. The server may not be running in an account with identity 'DoesNotExist@MyDomain.com'."...
3. With the UPN at the client end set to DoesExist@MyDomain.com (this account exists in the AD), and the WCF service running as MyDomain\WCFHost, all works OK
4. With the UPN at the client end set to WCFHost@MyDomain.com, and the WCF service running as MyDomain\AnotherHost (another domain account), all works OK (note that the client proxy was not regenerated following the change of service account)
My question is, is the behaviour in scenarios 3 and 4 correct? I was expecting scenarios 3 and 4 to fail in a similar way to scenario 2 (as there is a mismatch between the UPN specified at the client end and the account used at the server end). I have tried eliminating any possible NTLM authentication by setting allowNtlm to false at the client end, but this has no effect. I have tried this with wsHttpBinding and also with netTcpBinding, but get the same results. Am I missing something really obvious here?
David
