Tengan paciencia, sé que esto es descuidado, pero aquí está la historia de fondo:
Tenemos un socio que usa Jira y está usando spnego con un back-end de autenticación personalizado que espera cierta membresía de grupo en el token. Suponiendo que el token presentado cumpla con los requisitos, al usuario se le otorga acceso de SSO a Jira.
Tenemos una confianza externa no transitiva bidireccional de uno de nuestros dominios secundarios con este socio. Dado que se trata de una confianza externa antigua y crujiente y no de una confianza de bosque selectiva, AD no mantiene la información necesaria para que Kerberos funcione para otra cosa que no sean inicios de sesión interactivos entre los dominios.
Hay un SPN registrado de su lado para este servicio, pero los clientes de mi lado no pueden encontrar este SPN, porque no es posible una referencia a Kerberos. Esto es, obviamente, un problema, ya que hace que los clientes recurran a NTLM y no se SSO.
La solución alternativa propuesta es crear también una cuenta de servicio en nuestro y registrar un SPN de nuestro lado para el mismo servicio idéntico al de ellos. Las contraseñas deberán ser idénticas en cada lado. Esto anulará la necesidad de una referencia para encontrar el SPN adecuado, ya que efectivamente lo estamos reflejando de nuestro lado y "engañamos" a los clientes de nuestro hijo para que lo usen en lugar del correcto de su lado. También proponen que bajemos el algoritmo de cifrado para estas cuentas duplicadas a RC4 en lugar de AES.
Aquí es donde mi conocimiento comienza a fallar, no sé por qué es necesario el paso de reducir el algoritmo de cifrado a RC4. Tampoco sé cuáles pueden ser las implicaciones de seguridad de ello.
¿Cuáles son las implicaciones y por qué no podemos limitarnos a AES para que esto funcione?