I know a fair amount about how Kerberos Authentication works, but for the life of me I can't explain a strange behavior I am seeing with an IIS-hosted WCF service.
I've set up an extremely simple WCF app that exposes an endpoint using BasicHttpBinding with TransportCredentialOnly. My understanding is that for Kerberos to work, a User Principal Name or Service Principal Name must be specified by the client. For some reason it doesn't seem consistent across different binding types.
When I omit this principal name, on IIS6, NTLM ends up being used. On IIS7, it uses Kerberos. When I specify a User Principal Name on IIS6, Kerberos is used but on IIS7 the calls fail (Wireshark shows an KRB_AP_ERR_BADMATCH error during the Kerberos handshake).
It gets even more fun when I switch the binding to WSHttpBinding with Message security. In that experiment if I don't specify the User Principal Name on IIS6 the call fails, and on IIS7 NTLM gets used. When I specify the UPN, IIS6 fails and II7 ends up using Kerberos. Here's a summary of my findings. If anyone out there can help me wrap my mind around what's happening, I'd be eternally grateful.
Do you know about kernel-mode authentication in IIS 7? It removes the need to use a custom identity for the application pool, and it also (in most cases) removes the need to assign SPNs to the custom identity or host machine.
Here's a blog post that describes when you need to set SPNs when using kernel-mode authentication.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With