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