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).