Why does IE not send the Kerberos ticket information to my JBoss on Linux?

Question

I'm trying to implement SSO using a Windows client and JBoss. Own my development PC, JBoss runs on Windows 7, on the development server, it runs on (Red Hat) Linux.

There's a JBoss Negotiation Toolkit which allows me to check whether the Negiation header is arriving correctly.

The BasicNegotiation test works fine as long as I have JBoss running on my own PC, using localhost. The sent header is

Authorization: Negotiate YHgGBisGAQUFAqBuMGygMDAuBgorBgEEAYI3AgIKB... (plus some more bytes)

The test's response is

Negotiation Toolkit Basic Negotiation WWW-Authenticate - Negotiate YHgGBisGAQUFAqBuMGygMDAuBgorBgEEAYI3AgIK...

NegTokenInit Message Oid - SPNEGO Mech Types - {NTLM} {Kerberos V5 Legacy} {Kerberos V5} {1.3.6.1.4.1.311.2.2.30} Req Flags - Mech Token -TlRMTVNTUAABAAAAl7II4gQABAAyAAAACgAKACgAAAAGAbAdAAAAD0lQSUVWMTAwMjVJUElF Mech List Mic -

But on the Linux server, the same test doesn't work. The base reason (I guess) is that the header looks different:

Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==

And then the JBoss Negotiation Toolkit makes a fallback to NTML Authentication, which I don't want and which appears as error in the webapp's output.

Negotiation Toolkit NTLM Negotiation WWW-Authenticate - Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==

NTLM - Negotiate_Message Warning, this is NTLM, only SPNEGO is supported! Negotiate Flags - (encryption56Bit)(explicitKeyExchange)(sessionKeyExchange128Bit) negotiateVersion)(ntlm2)(alwaysSign)(ntlm)(lmKey)(sign)(requestTarget)(oem)(unicode) Domain Name = null - {length=0}{maxLength=0}{offset=0} Workstation Name = null - {length=0}{maxLength=0}{offset=0} Version - ?

I configured both Internet Explorer and Firefox to send the Negotiation header, and they both fail with the Linux server.

What am I doing wrong?

By the way: I read somewhere that Windows always sends the Kerberos Negotiation header on local machines - is that true?

Answer 1

Thanks for the answers. In our case the problem was that we have two Windows domains. I was trying to access the Linux server in the domain A with the Windows Browser in the domain B. Obviously, that doesn't work...

Answer 2

My Internet Explorer used to send a NTLM Header instead of a kerberos one. Reason: Windows had a saved password for the same host in its safe.

The user and password entered in the safe were not the same as the one of my Windows account, but it maked no difference. Only the server name (even not full-qualified) was relevant.

Tanks to http://www.msxfaq.de/verschiedenes/kerberosbrowser.htm for the explanation (in German).

Answer 3

The browser sends an NTLM type-1 token because Kerberos has failed because your AD/DNS setup is incorrect. This behavior is correct. Fix your DNS setup.

Answer 4

Here is a good summary of what can go wrong: https://www.pingidentity.com/support/answers/index.cfm/why-am-i-not-getting-a-kerberos-ticket?id=90640000000CaWgAAK

I always do a wireshark capture to see the communication between the browser and the service, and also between the browser and the AD. In your case the problem could be with the latter. For example once i used http://myGoodLookingDNSAlias address for a service, which was resolved to http://realBadLookingServerName, but i forgot to register the latter. So the browser got a KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN error from the AD, and did not send the ticket.

Regards, András