Perché IE non invia le informazioni del ticket Kerberos al mio JBoss su Linux?

Question

Sto cercando di implementare SSO utilizzando un client Windows e JBoss. Possiedo il mio PC di sviluppo, JBoss gira su Windows 7, sul server di sviluppo, gira su Linux (Red Hat).

C'è un JBoss Negotiation Toolkit che mi consente di controllare se l'intestazione di Negazione sta arrivando correttamente.

Il test BasicNegotiation funziona correttamente finché ho JBoss in esecuzione sul mio PC, utilizzando localhost. L'intestazione inviata è

Authorization: Negotiate YHgGBisGAQUFAqBuMGygMDAuBgorBgEEAYI3AgIKB... (più qualche altro byte)

La risposta del test è

negoziazione Toolkit negoziazione di base WWW-Authenticate - Negoziare YHgGBisGAQUFAqBuMGygMDAuBgorBgEEAYI3AgIK ...

NegTokenInit Message Oid - SPNEGO Tipi Mech - {} {NTLM Kerberos V5 Legacy} {Kerberos V5} {} 1.3.6.1.4.1.311.2.2.30 Visione Requisiti Bandiere - Mech Moneta -TlRMTVNTUAABAAAAl7II4gQABAAyAAAACgAKACgAAAAGAbAdAAAAD0lQSUVWMTAwMjVJUElF Mech Lista Mic -

Ma sul Server Linux, lo stesso test non funziona. Il motivo di base (credo) è che l'intestazione sembra diverso:

Authorization: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw==

E poi il JBoss negoziazione Toolkit fa un fallback a NTLM Authentication, che io non voglio e che appare come errore nell'output del webapp.

negoziazione Toolkit NTLM Negoziazione WWW-Authenticate - Negoziare TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbAdAAAADw ==

NTLM - Negotiate_Message Attenzione, questo è NTLM, solo SPNEGO è supportato! Negozia flag - (encryption56Bit) (explicitKeyExchange) (sessionKeyExchange128Bit) negotiateVersion) (ntlm2) (alwaysSign) (ntlm) (lmKey) (sign) (requestTarget) (oem) (unicode) Nome dominio = null - {length = 0 } {maxLength = 0} {offset = 0} Nome workstation = null - {length = 0} {maxLength = 0} {offset = 0} Versione -?

Ho configurato sia Internet Explorer sia Firefox per inviare l'intestazione Negoziazione, ed entrambi falliscono con il server Linux.

Cosa sto sbagliando?

A proposito: ho letto da qualche parte che Windows invia sempre l'intestazione di negoziazione Kerberos su macchine locali - è vero?

Answer 1

Grazie per le risposte. Nel nostro caso il problema era che abbiamo due domini Windows. Stavo cercando di accedere al server Linux nel dominio A con il browser Windows nel dominio B. Ovviamente, questo non funziona ...

Answer 2

Il browser invia un token NTLM di tipo 1 perché Kerberos non è riuscito in quanto la configurazione di AD/DNS non è corretta. Questo comportamento è corretto. Risolvi la tua configurazione DNS.

Answer 3

Ecco una buona sintesi di ciò che può andare storto: https://www.pingidentity.com/support/answers/index.cfm/why-am-i-not-getting-a-kerberos-ticket?id=90640000000CaWgAAK

faccio sempre una cattura Wireshark per vedere la comunicazione tra il browser e il servizio, e anche tra il browser e il dC. Nel tuo caso il problema potrebbe essere con quest'ultimo. Ad esempio, una volta ho usato l'indirizzo http://myGoodLookingDNSAlias per un servizio, che è stato risolto a http://realBadLookingServerName, ma ho dimenticato di registrare quest'ultimo. Quindi il browser ha ricevuto l'errore KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN dall'AD e non ha inviato il ticket.

saluti, András

Answer 4

Il mio Internet Explorer usava inviare un header NTLM invece di uno kerberos. Motivo: Windows aveva una password salvata per lo stesso host nella sua cassaforte.

L'utente e la password immessi nella cassaforte non erano uguali a quelli del mio account Windows, ma non ha fatto alcuna differenza. Solo il nome del server (anche non completo) era pertinente.

Serbatoi a http://www.msxfaq.de/verschiedenes/kerberosbrowser.htm per la spiegazione (in tedesco).