How does a web browser (IE8) determine the token to send for the Authorization: Negotiate request header?

3
votes

I am installing spnego on a java app server that will authenticate users against Active Directory. I've followed all of the directions closely, and the AD Preauth account has the java app server FQDN in the servicePrincipalName attribute. We already have another java app server with spnego installed that works correctly (I did not do that install and they are no longer here).

I've developed a simple java EE 6 web app to test that spnego is working correctly (jsp page with request.getRemoteUser() ). I correctly get my username response when I run this app on the existing server. When I run it on the new server I'm setting up, I get the following error:

java.lang.UnsupportedOperationException: NTLM specified. Downgraded to Basic Auth (and/or SSL) but downgrade not supported.

Using Fiddler to inspect the sessions, The Authorization: Negotiate token request to the correctly working server is a huge string (the Kerberos token I believe?). The Authorization: Negotiate token request to the non-working server is only 56 characters long (so, NTLM token?). When the server receives that NTLM token, I believe that's when the error is thrown.

I've inspected the responses from the earlier negotiation sessions, but can't find where the server is asking for Kerberos vs. NTLM tokens. How does the browser determine what do send?

Additional details: Java App Server machine: Windows 2008 R2, Java 1.7, Glassfish 3.1.2.2

Client Machine: Windows 7 Enterprise, IE8 on a standard corporate windows domain

Thanks.

1
httpjakarta-eespnego

1 Answers

0
votes
  • The servicePrincipalName isn't just the FQDN; it needs to include the service as well. Like: HTTP/MYSERVER.MYDOMAIN.COM.
  • The address you're visiting in your web browser must match that FQDN. In fact, you can add any IP in your OS HOSTS file to match this FQDN and it should work OK (even if the IP is 127.0.0.1 and you want to test SPNEGO-Kerberos locally)
  • From the command-prompt of the browser OS, run: klist get HTTP/MYSERVER.MYDOMAIN.COM, and verify you get a ticket. My guess is that this will fail.

Assuming the third point fails, then you have a larger problem with Kerberos configuration (not your browser/webserver), either on your client OS or your KDC.