Unir un host Linux a Active Directory con realmd y SSSD

Objetivo

Unir un host Linux a un dominio de Active Directory para que las cuentas de AD puedan autenticarse y resolverse localmente, usando realmd para dirigir SSSD en lugar de ensamblar sssd.conf a mano.

Requisitos previos

realmd, sssd y los paquetes de compatibilidad con AD/Kerberos instalados (realmd, sssd-ad/sssd-common, adcli, krb5-workstation/krb5-user según la distribución). Resolución DNS correcta del dominio de AD (registros SRV) y sincronización horaria con los controladores de dominio — la autenticación Kerberos falla fuera de una pequeña tolerancia de desfase de reloj. SSSD es el demonio cliente que guarda en caché los datos de identidad y autenticación de los servicios de directorio, incluido Active Directory, según su propia documentación de proyecto.

Pasos

1. Confirmar que el dominio se puede descubrir por DNS antes de intentar unirse: realm discover example.com. Una salida que enumere el dominio, su tipo (kerberos, active-directory) y los paquetes necesarios confirma los registros SRV y la accesibilidad básica; un fallo aquí significa que hay que corregir el DNS primero, no ajustar SSSD.
2. Unirse al dominio: realm join -U administrator example.com. Esto es lo que realmente crea la cuenta de equipo en AD, escribe el keytab y genera la sección de dominio correspondiente en sssd.conf — realmd gestiona ese archivo, así que conviene evitar editar a mano las secciones de las que es propietario.
3. Restringir los inicios de sesión de inmediato en lugar de dejar el dominio totalmente abierto: realm permit user@example.com para una cuenta, o realm permit -g "Domain Admins@example.com" para un grupo; realm deny --all primero si el valor por defecto debe ser que nadie pueda entrar hasta que se le permita explícitamente.
4. Verificar que una cuenta de AD concreta se resuelve: id user@example.com. Un par UID/GID y las pertenencias a grupos confirman que SSSD está resolviendo la identidad correctamente; un fallo aquí junto con un realm discover correcto apunta al propio servicio SSSD.
5. Comprobar la visión que el propio SSSD tiene de su estado: sssctl domain-list y sssctl domain-status example.com resumen si el dominio está en línea y qué proveedores están activos. id_provider/access_provider en el sssd.conf generado muestran qué backends están realmente configurados.
6. Ante un fallo de inicio de sesión que id no explica, elevar el nivel de depuración en sssd.conf (debug_level = 9 en la sección correspondiente, y luego systemctl restart sssd), reproducir el fallo y recoger los registros con sssctl logs-fetch /tmp/sssd-logs.tar (la ruta del archivo es obligatoria). El nivel 9 es muy detallado y registra información sensible; hay que revertirlo después.

Resultado esperado

id user@example.com devuelve un UID/GID resuelto; solo pueden autenticarse las cuentas o los grupos explícitamente permitidos.

Límites y base de verificación

Verificado con realm(8) (discover, join, permit), sssd.conf(5) (id_provider, access_provider) y sssctl(8). Deshacer: realm leave example.com elimina la configuración local del dominio e impide que SSSD siga autenticando contra él; la cuenta de equipo en AD se queda tal cual, a menos que se use realm leave --remove -U administrator example.com o que un administrador del dominio la elimine.