El dominio AD se unió al servidor Linux equivalente a NLA

Question

Primero, algunos antecedentes.

Hoy en día, si se encuentra en un entorno predominantemente de Windows Server AD con solo una pequeña cantidad de servidores Linux, tiene la opción de autenticarse en los servidores a través de SSH:

1. Administre los servidores Linux a través de SSH con autenticación de certificado (la forma normal de Linux)
2. Una los servidores Linux a su dominio AD (reino+sssd) y adminístrelos a través de SSH con autenticación de nombre de usuario/contraseña

El problema es que la opción 1 deja a los administradores administrar un conjunto de credenciales separado del resto del entorno, y la opción 2 hace que los administradores proporcionen contraseñas directamente a los servidores remotos a través de la red antes de que las máquinas se hayan identificado completamente entre sí.

En el mundo de Windows, esto se resuelve (al menos para RDP, lo cual sé que debería evitarse) mediante la autenticación a nivel de red. Una versión simplificada del proceso se ve así:

1. El usuario comienza a conectarse a la computadora remota.
2. La computadora remota responde con el token de cuenta de computadora AD
3. La computadora local valida el token, ve el soporte NLA y muestra un cuadro de diálogo de credenciales al usuario
4. El usuario completa el diálogo con las credenciales.
5. La computadora local valida las credenciales con el control de dominio (no la computadora remota)
6. El DC proporciona a la computadora local un token de autenticación.
7. La computadora local presenta el token a la computadora remota.
8. La computadora remota valida el token contra el dominio.
9. En caso de éxito, el usuario puede acceder a la computadora remota.

En realidad, el proceso puede ser incluso más simple, donde ya se puede usar el token de autenticación existente creado para el usuario cuando inició sesión por primera vez en la computadora local.

Este es un proceso complejo y ciertamente he cometido errores al describirlo. El punto es que el token de autenticación reemplaza el certificado de la historia de Linux, de modo que el usuario nunca proporciona credenciales reales a una máquina potencialmente desconocida. Además, la dependencia de todas las partes en el DC confiable hace que las cosas sean incluso mejores que la historia de Linux, porque el usuario no debe administrar sus propios certificados, ni siquiera a través de su propio software (más bien, es el software que se le proporciona).

---

Ahora la pregunta. ¿Hay alguna manera de obtener algo similar para autenticar una sesión SSH en un servidor Linux unido a AD, donde el servidor nunca ve las credenciales del usuario pero la experiencia del usuario sigue siendo la validación de credenciales nativa de Windows?

Answer 1

Hay mucho que abordar, pero esencialmente lo que se necesita es un SSH "kerberizado" o lo que sea. NLA también proporciona un paso adicional (no especificado aquí) de no proporcionar una sesión de consola (que es costosa de crear en términos de recursos) hasta que se valide la autenticación.

Más concretamente, aparte de las complejidades, que son prohibitivas, no veo un gran interés en esto porque ya existe una solución. Utilice un host de salto de bastión para conectar los hosts de Linux, no permitiendo el tipo de acceso/puerto(s) de otros. Ese host bastión puede ser Windows y admitir todas las funciones que faltan.

Los hosts de salto de bastión también se están volviendo más comunes en entornos AD para permitir tipos de acceso como RDP a recursos protegidos.

Además, en el ejemplo de RDP, las credenciales en realidad no están protegidas del servidor. Esto se soluciona utilizando el modificador /RemoteGuard.

https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mstsc