Resta con me, so che questo è sciatto, ma qui c'è il retroscena:
Abbiamo un partner che utilizza Jira e utilizza spnego con un back-end di autenticazione personalizzato che prevede l'appartenenza a determinati gruppi nel token. Supponendo che il token presentato soddisfi i requisiti, all'utente viene concesso l'accesso SSO a Jira.
Abbiamo un trust esterno non transitivo a due vie da uno dei nostri domini figlio con questo partner. Poiché si tratta di un trust esterno vecchio e croccante e non di un trust forestale selettivo, AD non conserva le informazioni necessarie affinché Kerberos funzioni per altri scopi oltre agli accessi interattivi tra i domini.
Per questo servizio è stato registrato un SPN, ma i clienti al mio fianco non sono in grado di individuare questo SPN perché non è possibile effettuare un referral Kerberos. Questo è, ovviamente, un problema poiché fa sì che i client torni a NTLM e non SSO.
La soluzione proposta è di creare un account di servizio su nostro e registrare un SPN dalla nostra parte per lo stesso servizio identico al loro. Le password dovranno essere identiche su ciascun lato. Ciò annullerà la necessità di un referral per trovare il SPN appropriato dal momento che lo stiamo effettivamente rispecchiando dalla nostra parte e "ingannando" i clienti di nostro figlio nell'usarlo anziché da quello giusto dalla loro parte. Propongono inoltre di abbassare l'algoritmo di crittografia per questi account con mirroring su RC4 anziché su AES.
È qui che la mia conoscenza inizia a vacillare, non so perché sia necessario ridurre l'algoritmo di crittografia a RC4. Inoltre, non so quali potrebbero essere le implicazioni sulla sicurezza.
Quali sono le implicazioni e perché non possiamo limitarci ad utilizzare AES per fare in modo che funzioni?