È possibile questa configurazione Kerberos / AD?

Abbiamo una configurazione IDAM leggermente complicata:

Cioè la macchina e il browser dell'utente finale si trovano in una rete con l'AD padre e la nostra applicazione basata su Jetty e l'AD con cui può parlare (AD locale) siedono nell'altra.

Esiste un trust bidirezionale tra i due AD. Il browser nella rete principale ha il dominio locale in siti attendibili.

L'impostazione del server Jetty è la seguente:

• utilizza un file keytab generato su un'entità nell'AD locale
• è in esecuzione come servizio Windows con un utente definito nell'AD locale
• regno, mappatura dominio-dominio e kdc sono definiti rispetto al dominio dell'AD locale
• usa spnego - isInitiator è impostato su false; doNotPrompt è vero; storeKey è vero

Il problema è:

• come test, l'accesso al server da un browser all'interno della rete locale (cioè collegato all'AD locale) funziona : le informazioni di debug di Kerberos vengono visualizzate nei registri, posso vedere la negoziazione Kerberos corretta nel traffico HTTP e l'utente accede automaticamente . Brillante.

• tuttavia , l'accesso al server da un browser all'interno della rete principale (che è il modo in cui i nostri utenti faranno le cose) non funziona! Il browser recupera una 401 unauth ma poi richiede le credenziali, che una volta inserite danno una schermata vuota. Quindi, facendo clic sulla barra degli indirizzi e premendo Invio si esegue una delle due operazioni, a seconda che le credenziali siano per l'AD remoto o locale:

  • le credenziali AD locali quindi accedono correttamente, con Kerberos da zero nei registri (richiesta GET, risposta 401 non autentica, richiesta intestazioni Kerberos, ecc.)
  • credenziali AD remoti non il log-in (richiesta GET, 401 risposta unauth, quella che appare come un header NTLM: Authorization: Negotiate <60 or so random chars>)

Ad ogni modo, il fatto che sia un suggerimento è sbagliato!

C'è una spiegazione per questi sintomi? Il setup che possiamo fare è quello che vogliamo?

In termini di cosa sopra la descrizione sopra potrebbe essere sbagliata: qualsiasi configurazione che ho menzionato riguardo al server Jetty dovrebbe essere accurata, come ho fatto io. Sono felice di fornire maggiori dettagli. Qualsiasi configurazione riguardante AD o il browser di rete principale è potenzialmente sospetta, perché non è sotto il mio controllo e ho avuto la configurazione segnalata a me piuttosto che vederla da sola.

Senza vedere l'acquisizione dei pacchetti, immagino che l' SPN HTTP / www.website.com debba essere registrato nell'account che esegue l'applicazione. Il team di Microsoft Directory Services ha un ottimo post in più parti che affronta questo argomento al seguente URL.

https://blogs.technet.microsoft.com/askds/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1/

Esegui un'acquisizione di pacchetti (netmon, WireShark) da un client in ogni ambiente per identificare quale SPN viene cercato. Una volta determinato, utilizzare il cmd setspn per registrarlo sull'account che esegue l'applicazione.

FWIW, Kerberos funziona solo sulla LAN. Se qualcuno ha bisogno di accedere dove i controller di dominio non sono accessibili, ti consigliamo di prendere in considerazione un SSO come Shibboleth o ADFS.

EDIT: come menzionato da @ alex-h , i browser dovranno essere configurati per l'autenticazione silenziosa tramite Kerberos.

• Internet Explorer : mentre l'articolo TechNet non è specifico per la tua applicazione, i passaggi sono gli stessi.
• Firefox : uguale al collegamento IE, non corrispondenza esatta ma i passaggi sono gli stessi.

Infine, questo è un problema comune con le distribuzioni di Microsoft Sharepoint. Vogliono che SSO tramite Kerberos avvenga in silenzio una volta che gli utenti si sono autenticati nel dominio. Pertanto, se le risposte sopra riportate non risolvono il problema, prova a controllare i loro forum come il seguente:

Kerberos su Chrome, Safari o FireFox

Prova 1 ° da un browser in cui NTLM non è abilitato (Chrome / Firefox). Sembra che il problema sia che hai abilitato la pre-autenticazione e potrebbe non essere possibile l'attendibilità bidirezionale.

Per la pre autenticazione, dai un'occhiata qui https://support.microsoft.com/en-us/kb/2749007 e qui https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html .