Hi
I have a very strange problem. It is not fiddler related, but fiddler actually fixes it! But I hope someone here can shed some light on what is going on.
I am trying to have a client (Internet Explorer) connect to a webserver (IIS) with Kerberos authentication. I access the website with the DNS name for the server (myapp.domain.net) as URL. When fiddler is NOT running on the client machine this happens:
1)
Client sends GET request to webserver
2)
Webserver responds with 401 and WWW-authenticate set to Negotiate
3)
Client sends AS request to domain controller
4)
Domain controller sends AS response ticket
5)
Client sends TGS request to domain controller. Inside the request is the
FQDN(iisservermachinename.domain.net) of the webserver.
6)
Domain controller sends S_PRINCIPAL_UNKNOWN to client
7)
Client sends GET request to webserver with an NTLM NEGOTIATE MESSAGE inside
8)
Webserver sends 401 with an NTLM CHALLENGE MESSAGE
9)
Client sends GET request to webserver with NTLM AUTHENTICATE MESSAGE inside
10)
Webserver replies with HTML
This gives NTLM authentication and not the Kerberos authentication I want.
The strange thing is step 5). When fiddler IS running, it puts myapp.domain.net in the TGS ticket instead of iisservermachinename.domain.net. And then everything works because then it hits my AD SPN's.
Can anyone tell something about what is going on here?
6 Answers, 1 is accepted
Kerberos (and Negotiate in general) is unfortunately pretty complex, especially when a proxy gets involved. In some cases, Negotiate will use NTLM when going through a proxy but use Kerberos when going direct.
Furthermore, there are some additional complexities because the client application can use one of several different strategies when constructing the SPN (Service Principal Name); for Microsoft products, these can be controlled by registry keys.
This KB article looks like it might describe what you're encountering:
https://support.microsoft.com/en-us/kb/3022771
"When Internet Explorer accesses the web server through a proxy server, it tries to request the Kerberos ticket based on the CNAME of the web server, instead of the A record."
Regards,
Eric Lawrence
Telerik
Rank 1
[quote]Eric Lawrence said:Hello, Rune--
This KB article looks like it might describe what you're encountering:
https://support.microsoft.com/en-us/kb/3022771
"When Internet Explorer accesses the web server through a proxy server, it tries to request the Kerberos ticket based on the CNAME of the web server, instead of the A record."
Hi Eric. Thanks for your reply.
Isnt it the exact opposite that happens for me? When fiddler is NOT running, IE requests the Kerberos ticket based on iismachinename.domain.net (This is the A-record, right?) and that fails. When Fiddler IS running, then it requests the Kerberos ticket based on myappname.domain.net (This is the CNAME, right?) and that works.
The question is: Is Fiddler doing the right thing and IE doing the wrong thing? Or is it the opposite way arround because then I might have registered my SPN's wrong.
Yes, it sounds like the behavior is opposite what is described in that KB; I know there are several overlapping KB articles and a number of feature control keys.
Unfortunately, this is really a question for Microsoft, as there's nothing Fiddler can do to influence what IE is using.
Regards,
Eric Lawrence
Telerik
Rank 1
Rank 1
Hello Rune,
We are facing similar issue, may I know how did you solve it?
Thanks,
Sabarehs
Rank 1
Had this issue using Amazon AWS Classic ELB load balancer.
Target server SAP Business Objects - Tomcat - Kerberos - on Win 2012R2.
We added the name of the load balancer (internal-xxx-elb-123456789.elb.amazonaws.com) to the SPN configuration and this seems to have fixed the problem.
Another option may be to disable reverse DNS for Kerberos in the krb5.ini file in Tomcat - we didn't test this.