Cannot access backend WCF services via a web app using Kerberos Constrained Delegation through Safari

0
votes

I have a scenario wherein my ASP.NET MVC 3 web application hosted in IIS 7/Windows 2008 is accessing a WCF web service from another server, also hosted in IIS/Windows 2008. KCD is setup between the two servers and I have the necessary SPNs set up as well.

I have confirmed this working in IE. Using NetMon, I have also confirmed that KCD is working at the backend. My web app is running under machine account (network service) and the SPNs are setup accordingly for this machine account. The issue is when I use Safari on both my Windows and Mac OS X (Lion) machine, I am getting a 401 Unauthorized error:

The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'.

Looking at NetMon, it is failing because the request to the WCF web service is falling back to NTLM.

Note that both Windows and Mac machines are part of our domain, and I'm using my same Windows credentials on both machines.

I know that Safari supports Kerberos authentication, but there seems to be an issue when delegating from my web app to the WCF service. Is it an issue with Safari, or with WCF?

Thanks in advance!

Update:

In Safari on Mac, when I first access the web application, I can see in Wireshark and NetMon that there is a valid Kerberos token being passed along the HTTP request (i'm not getting a 401 Unauthorized error). But when my web application tries to access the backend web service, I can see in that particular HTTP request that the token being passed along is now an NTLM token.

I'm using basicHttpBinding with TransportCredentialOnly as the security mode - I also specified in web.config the SPN identity of the backend web service's endpoint (HTTP/FQDN of backend web service server). Windows Auth is of course enabled on both IIS sites with "use kernel mode" turned on, and with useAppPoolCredentials set to true on the appHost.config of both sites. Again this is just for Safari on Mac, Firefox and Chrome are both working fine.

2
wcfsafarikerberos
Did you check in wireshark whether Safari sends a delegable/forwardable ticket? – Michael-O
Safari does send a token, but it's an NTLM-based token. Is there any config that needs to be performed to Safari to make it work? Firefox and Chrome works, by the way. – communista
If Safari uses SSPI on Windows and sends a NTLM token, your Kerberos setup is broken. I have answered that type of question several times on Stackoverflow. Please search for, you will find the solution. – Michael-O
Now this is weird - I did a couple more tests and at times, a Kerberos token comes up, but I'm still getting the same error. I ran 20 more tests, and most of the time there's a Kerberos token, but there were 4 instances that an NTLM token came up. – communista
Use Wireshark to analyze the failure, you'll see why Kerberos fails. – Michael-O

2 Answers

1
votes

Looking at the Wireshark traces, it seems that Safari is requesting for a Kerberos ticket that is not forwardable. Due to this flag, the Kerberos ticket is not forwarded / delegated to the next hop, causing the authentication to fall back to NTLM and fail.

Comparing this to the TGS request requested by IE, Firefox and Chrome, they all have a forwardable flag set.

I also tried doing a klist -F in Mac OS X to retrieve tickets that are forwardable, but Safari will still request for a separate ticket that doesn't have the forwardable flag.

Which brings me to a conclusion that Safari on Mac DOES NOT support delegation.

1
votes
  1. Check in Wireshark whether Safari sends a delegable/forwardable ticket.
  2. Are you able to access the backend service directly? Is credential delegation on, I guess the ticket is not delegable? Safari has to request this. Firefox and IE do. The NTLM token passed is a token from your server. There is no delegation support in NTLM. There is something wrong with the target host.