Integración de Active Directory de SLES 15 con SSSD: Guía paso a paso

Para un host típico de SUSE Linux Enterprise Server 15 que necesita que los usuarios del dominio inicien sesión, SUSE documenta YaST User Logon Management con SSSD como la mejor opción en la mayoría de los entornos de Active Directory. SSSD proporciona la identidad de Linux y la ruta de autenticación PAM, mientras que Active Directory sigue siendo la fuente para las cuentas y la autenticación Kerberos. Winbind es más adecuado cuando su diseño depende de NTLM o de la compatibilidad con confianza entre bosques. Si prefiere la automatización, SUSE también documenta la unión con realmd; es una herramienta de detección y pertenencia al dominio, así que confirme qué software cliente y política de acceso configurará su sistema antes de usarla a gran escala.

Este tutorial sigue la Guía de seguridad y protección de SLES 15 SP7, revisada el 6 de octubre de 2026. Los Service Packs de SUSE pueden variar, y las instrucciones a continuación son un procedimiento basado en la documentación, no una garantía de que los comandos se hayan ejecutado en su dominio. Reemplace el dominio y los nombres de host de ejemplo con los valores de su entorno. Pruebe primero en una máquina SLES no crítica y mantenga una cuenta de administrador local disponible en caso de que la autenticación de dominio esté mal configurada.

Elija el método de integración que mejor se adapte al trabajo.

SUSE describe la opción YaST con soporte SSSD como adecuada para la mayoría de las uniones a Active Directory e indica Winbind para casos que requieren NTLM o relaciones de confianza entre bosques. Estos son puntos de partida prácticos, no un sustituto para probar necesidades específicas de la aplicación, como el servicio de archivos Samba, las reglas sudo, la búsqueda de claves SSH o las colisiones de nombres de dominio múltiples. Para un conjunto de inicios de sesión Linux estándar, comience con SSSD a menos que un requisito documentado indique otra opción.

Qué preparar antes de integrar SLES con Active Directory

• Nombre de host estable: Elija el nombre de host completo deseado y asegúrese de que se resuelva correctamente en su red y en Active Directory. Coordine cualquier convención de nomenclatura de cuentas de equipo con el equipo de directorio.
• DNS compatible con Active Directory: El cliente SLES debe consultar un servidor DNS que pueda resolver la zona de Active Directory y sus registros de servicio (SRV). El uso exclusivo de un resolvedor público suele provocar fallos en la detección de dominios.
• Sincronización horaria: Kerberos depende de que el cliente y los controladores de dominio tengan relojes sincronizados con precisión. Confirme la sincronización NTP antes de solucionar problemas de contraseñas o SSSD.
• Acceso a la red de los controladores de dominio: Confirme que el firewall y el enrutamiento permiten los protocolos y puertos requeridos por el diseño de Active Directory de su organización, incluidos DNS, Kerberos, LDAP y cualquier tráfico necesario para el catálogo global o el cambio de contraseñas. No abra todos los puertos indiscriminadamente; solicite al administrador de Active Directory/red que proporcione las reglas aprobadas.
• Identidad de inscripción autorizada: Utilice una cuenta autorizada para agregar o reutilizar objetos informáticos en la unidad organizativa correcta. Evite el uso rutinario de una cuenta con privilegios elevados cuando tenga disponibles derechos de unión delegados.
• Acceso de recuperación: Mantenga un inicio de sesión de administrador local probado y una forma de acceder a la consola. No convierta el dominio en la única ruta de acceso al servidor antes de validar la nueva ruta de inicio de sesión.

SUSE hace hincapié en la necesidad de DNS accesible desde Active Directory y en la hora precisa para Kerberos. Su guía indica que un dominio que termina en .localpuede entrar en conflicto con DNS multicast en algunos escenarios de unión. Si su Active Directory utiliza ese sufijo, consulte las implicaciones para su versión de SLES y la configuración de red con el administrador del directorio antes de modificar la nomenclatura o la configuración del resolvedor.

hostnamectl --static
hostname -f
timedatectl status
getent hosts ad01.corp.example.com
host -t SRV _ldap._tcp.dc._msdcs.corp.example.com

Es posible que el hostcomando requiera el paquete de utilidades DNS en una instalación mínima. Estas comprobaciones no garantizan que todas las rutas de firewall necesarias estén abiertas; ayudan a detectar problemas comunes de resolución de nombres y de sincronización antes de la inscripción.

Únase al dominio usando YaST y SSSD.

1. Configure el servidor DNS. Abra YaST y seleccione Configuración de red , luego Nombre de host/DNS . Configure el servidor DNS de Active Directory o un servidor DNS interno que reenvíe correctamente la zona de Active Directory. Guarde los cambios y confirme que el host puede resolver el controlador de dominio y los registros de servicio de Active Directory.
2. Abra la administración de inicio de sesión de usuario. Desde la ventana principal de YaST, inicie la administración de inicio de sesión de usuario y seleccione Cambiar configuración . Este es el módulo de autenticación basado en SSSD que se describe en la guía de SLES 15 SP7; es diferente del módulo de pertenencia a dominio de Windows , que utiliza Winbind.
3. Agregue el dominio de AD. Seleccione Agregar dominio , ingrese el nombre de dominio DNS (por ejemplo corp.example.com, ) y seleccione Microsoft Active Directory para los datos de identidad y la autenticación. Asegúrese de que el dominio esté habilitado. Si la detección automática de DNS no es apropiada en su red, especifique los nombres de host del controlador de dominio aprobados, como se describe en la guía.
4. Verifique el nombre de la máquina y el resultado de la detección. Compare el nombre de host local con el nombre de equipo previsto en Active Directory. Corrija cualquier discrepancia antes de la inscripción. YaST debería detectar un servidor de Active Directory e informar que el cliente aún no está inscrito. Si la detección falla, vuelva a las comprobaciones de DNS, hora, enrutamiento y firewall en lugar de intentar con proveedores de autenticación aleatorios.
5. Regístrese con una cuenta autorizada. Introduzca las credenciales de Active Directory permitidas para unirse al equipo. YaST puede instalar el software que falte durante este proceso. El cuadro de diálogo puede ofrecer la opción de sobrescribir la configuración de Samba; habilítela solo si el cambio es necesario para su configuración de Samba/Active Directory y, si los servicios de Samba ya están en uso, conserve primero la configuración existente.
6. Habilite el comportamiento de inicio de sesión deseado. En Administrar inicio de sesión de usuario de dominio , active el inicio de sesión de usuario de dominio solo después de decidir qué cuentas deben tener acceso. Configure la creación de directorios personales locales si los usuarios los necesitan. SUSE documenta las fallback_homediropciones override_homediry muestra /home/%uun formato posible. En un entorno multidominio, diseñe una ruta única y consulte el manual de SSSD antes de confiar únicamente en un nombre de usuario corto.
7. Guarda, revisa y prueba con un usuario sin privilegios. Aplica la configuración, confirma que el dominio y las opciones seleccionadas sean correctas y, a continuación, prueba una cuenta de dominio normal en la consola o mediante el servicio de inicio de sesión que vayas a utilizar. No realices la prueba únicamente con la cuenta que se conectó al equipo.

¿Cómo se verifica la conexión SSSD?

Verifique que SSSD esté activo, que NSS pueda resolver una identidad de dominio conocida y que el inicio de sesión real sea exitoso. Después de que el usuario de prueba inicie sesión, verifique si hay un ticket Kerberos. SUSE incluye klistentre getent passwdsus comprobaciones de conexión.

systemctl status sssd
getent passwd 'alex@corp.example.com'
id 'alex@corp.example.com'
klist

La cadena de identificación exacta depende de la configuración de nombres de SSSD; algunos entornos utilizan DOMAIN\userun nombre en lugar de un nombre de estilo UPN. Si getentno devuelve ningún registro, verifique que esté consultando el formato de nombre y el dominio configurados y, a continuación, revise los registros del servicio:

sudo journalctl -u sssd --since "15 minutes ago"

Una búsqueda exitosa por sí sola no demuestra que el usuario pueda iniciar sesión, y un ticket Kerberos existente no demuestra que todas las aplicaciones utilicen la pila PAM prevista. Pruebe una nueva sesión, un cambio de contraseña si es necesario, la autorización basada en grupos y la ruta de inicio de sesión SSH o de escritorio correspondiente. Confirme que el acceso esté restringido a las personas a las que deseaba permitirlo.

SSSD o Winbind: ¿qué decisión es la más importante?

Para la mayoría de los clientes SLES que necesitan identidades de AD e inicios de sesión interactivos, SSSD es la opción más sencilla, respaldada por la guía de administración de inicios de sesión de usuarios de SUSE. Integra la búsqueda de identidades y la autenticación PAM, y puede almacenar en caché información para garantizar la resiliencia cuando el directorio no está disponible temporalmente. El acceso en caché tiene limitaciones: un primer inicio de sesión no puede depender de una credencial almacenada en caché, y los recursos respaldados por el directorio o los cambios de contraseña aún requieren un controlador de dominio accesible. Establezca y pruebe su política de inicio de sesión sin conexión en lugar de considerar el almacenamiento en caché como una solución completa ante una interrupción total de AD.

Seleccione Winbind cuando un requisito dependa específicamente de la integración de dominios de Samba, NTLM o las relaciones de confianza entre bosques. No se trata simplemente de una casilla de verificación alternativa para SSSD: cada ruta utiliza diferentes demonios y componentes NSS/PAM. Documente qué servicio gestiona las búsquedas de dominio y los inicios de sesión, y evite mezclar ediciones manuales antiguas de PAM/NSS con la configuración administrada por YaST.

Utilice esta herramienta realmdcuando sea importante un flujo de trabajo de shell repetible. La Guía de administración de almacenamiento de SUSE SLES 15 SP7 documenta realm discover --verbosela detección basada en DNS, realm join --verbosela inscripción y realm permitlos permisos de inicio de sesión. Revise el software cliente seleccionado y la configuración de SSSD generada en su versión. Evite el acceso generalizado a "todos" en producción, a menos que sea una política explícita.

Fallos comunes y la siguiente comprobación

• La detección de dominios no devuelve ningún resultado: compruebe el servidor DNS del cliente y el registro AD SRV, y luego confirme que el host puede acceder a los controladores de dominio enumerados.
• Errores de Kerberos a pesar de tener una contraseña correcta: compruebe la sincronización de la hora del sistema, el nombre DNS utilizado para el controlador de dominio y si la cuenta de equipo está habilitada y tiene el nombre correcto.
• El usuario resuelve el problema pero no puede iniciar sesión: confirme que el inicio de sesión de dominio esté habilitado en YaST, verifique las restricciones de acceso y el estado de la cuenta en AD y revise los registros de SSSD/PAM.
• El inicio de sesión funciona, pero falta el directorio personal: confirme que la creación del directorio personal está habilitada y que la ruta configurada es válida y única para el usuario.
• Si la unión falla tras los intentos previos, compruebe si hay objetos de equipo obsoletos, nombres de host duplicados, configuraciones residuales de Winbind o NSS/PAM manuales y contraseñas de máquina incorrectas. Coordine la limpieza con el administrador de Active Directory antes de eliminar un objeto de equipo o borrar los datos locales de SSSD.

¿Cuándo conviene detenerse y optar por un enfoque diferente?

Haga una pausa antes de la implementación si su entorno depende de la confianza entre bosques, NTLM, un rol de servidor Samba, varios bosques con nombres de usuario cortos superpuestos o reglas de acceso complejas que la configuración básica de YaST no contempla. Estas condiciones pueden cambiar el proveedor preferido o requerir configuración SSSD adicional. Pruébelas con cuentas representativas y servicios reales en un sistema de prueba y mantenga el inicio de sesión de recuperación hasta que se haya comprobado la validez de la política.

En resumen: para una estación de trabajo o servidor SLES 15 SP7 estándar que requiera identidades e inicios de sesión de Active Directory, comience con la ruta de administración de inicio de sesión de usuario de YaST con soporte para SSSD. Configure correctamente primero el DNS, la hora, la nomenclatura de host y los permisos de unión; luego verifique la búsqueda de nombres, Kerberos, el inicio de sesión PAM y el ámbito de acceso. Seleccione Winbind para los requisitos específicos de Samba, NTLM o entre bosques que identifique SUSE, y utilícelo realmdcuando su flujo de trabajo de línea de comandos se ajuste mejor a su proceso operativo.

Fuentes: Guía de seguridad y endurecimiento de SUSE SLES 15 SP7: compatibilidad con Active Directory ; Guía de administración de almacenamiento de SUSE SLES 15 SP7: realmd ; SUSE SLES 15 SP7: clientes de autenticación y SSSD ; Notas de la versión de SUSE SLES 15 SP7 .