SSSD (System Security Services Daemon) conecta Linux con un directorio centralizado, como Active Directory o un servidor LDAP, para que los usuarios del dominio puedan iniciar sesión en el servidor con sus credenciales corporativas. Se integra con NSS (resolución de usuarios y grupos) y PAM (autenticación) y guarda en caché las credenciales para seguir funcionando si el controlador de dominio no responde. En este tutorial unirás un servidor Ubuntu 24.04 a un dominio de Active Directory con realmd, limitarás quién puede entrar, darás sudo a un grupo del dominio y verás la configuración equivalente para un servidor LDAP.

Requisitos previos

  • Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath, y un usuario local no root con privilegios sudo. Mantén ese usuario: es tu acceso de emergencia si el dominio falla.
  • Conectividad desde el servidor a los controladores de dominio (DNS 53, Kerberos 88, LDAP 389, 464, 3268), normalmente a través de una VPN o una red privada. Nunca expongas un controlador de dominio a Internet.
  • Un dominio de Active Directory, en esta guía ad.example.com, y una cuenta con permiso para unir equipos (por defecto, cualquier usuario del dominio puede unir hasta 10).
  • Dos grupos en AD para el ejemplo: linux-users (pueden entrar) y linux-admins (pueden entrar y usar sudo).

Paso 1: Preparar DNS, nombre de host y hora

Active Directory depende de DNS y Kerberos, y los fallos de unión casi siempre vienen de uno de estos tres puntos.

El servidor debe resolver el dominio a través de los DNS de AD. Comprueba que encuentra los registros SRV de los controladores:

resolvectl query -t SRV _ldap._tcp.ad.example.com

_ldap._tcp.ad.example.com IN SRV 0 100 389 dc1.ad.example.com

Si no aparece, configura los controladores de dominio como servidores DNS en Netplan (nameservers en /etc/netplan/*.yaml) y aplica con sudo netplan apply.

Asigna al servidor un nombre completo dentro del dominio. Es el nombre con el que se registrará la cuenta de equipo:

sudo hostnamectl set-hostname srv01.ad.example.com
hostname -f

srv01.ad.example.com

Kerberos rechaza la autenticación si la hora difiere más de 5 minutos de la del controlador. Comprueba que el reloj está sincronizado:

timedatectl status | grep synchronized

System clock synchronized: yes

Si dice no, apunta systemd-timesyncd a tus controladores de dominio editando NTP= en /etc/systemd/timesyncd.conf y reinicia con sudo systemctl restart systemd-timesyncd.

Paso 2: Instalar realmd y SSSD

realmd descubre el dominio, crea la cuenta de equipo con adcli y genera la configuración de SSSD y Kerberos. Instala los paquetes:

sudo apt update
sudo apt install realmd sssd-ad sssd-tools adcli libnss-sss libpam-sss krb5-user

Si la instalación de krb5-user pregunta por el reino Kerberos predeterminado, escribe el dominio en mayúsculas (AD.EXAMPLE.COM) y deja en blanco las preguntas sobre servidores.

Comprueba que realmd detecta el dominio:

realm discover ad.example.com

ad.example.com
  type: kerberos
  realm-name: AD.EXAMPLE.COM
  domain-name: ad.example.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

Si faltan paquetes de required-package, instálalos con apt. El importante es configured: no: el servidor aún no está unido.

Paso 3: Unir el servidor al dominio

Une el servidor con una cuenta que tenga permiso para crear equipos. Sustituye your_ad_admin por esa cuenta; te pedirá su contraseña:

sudo realm join -v -U your_ad_admin ad.example.com

 * Resolving: _ldap._tcp.ad.example.com
 * Performing LDAP DSE lookup on: 10.0.0.10
 * Successfully discovered: ad.example.com
...
 * Successfully enrolled machine in realm

Si quieres crear la cuenta de equipo en una unidad organizativa concreta, añade --computer-ou="OU=Linux,OU=Servers,DC=ad,DC=example,DC=com".

Comprueba el resultado y que el servidor ya resuelve usuarios del dominio. Sustituye your_ad_user por un usuario real:

realm list
id [email protected]

ad.example.com
  type: kerberos
  realm-name: AD.EXAMPLE.COM
  domain-name: ad.example.com
  configured: kerberos-member
  ...
  login-policy: allow-realm-logins
uid=1215601103([email protected]) gid=1215600513(domain [email protected]) groups=1215600513(domain [email protected]),1215601108([email protected])

Los UID y GID se calculan a partir del SID de cada objeto, así que serán los mismos en todos los servidores unidos al dominio.

Paso 4: Ajustar sssd.conf

realmd genera /etc/sssd/sssd.conf con nombres completos ([email protected]) y homes en /home/[email protected]. En un entorno con un solo dominio es más cómodo usar nombres cortos. Abre el archivo:

sudo nano /etc/sssd/sssd.conf

Deja la sección del dominio así. Las líneas que cambian son use_fully_qualified_names y fallback_homedir; el resto las ha escrito realmd:

[sssd]
domains = ad.example.com
config_file_version = 2
services = nss, pam

[domain/ad.example.com]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = AD.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
id_provider = ad
ad_domain = ad.example.com
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad

cache_credentials = True y krb5_store_password_if_offline = True permiten que un usuario que ya haya iniciado sesión antes pueda volver a entrar aunque no haya conexión con el controlador.

SSSD se niega a arrancar si el archivo es legible por otros usuarios. Comprueba los permisos, valida la sintaxis, reinicia el servicio y vacía la caché para que aplique los nombres cortos:

sudo chmod 600 /etc/sssd/sssd.conf
sudo sssctl config-check
sudo systemctl restart sssd
sudo sss_cache -E

Issues identified by validators: 0

Ahora el usuario se resuelve sin el sufijo del dominio:

getent passwd your_ad_user

your_ad_user:*:1215601103:1215600513:Your AD User:/home/your_ad_user:/bin/bash

Paso 5: Crear el directorio home al primer inicio de sesión

Los usuarios del dominio no tienen directorio home en el servidor hasta que se crea. El módulo pam_mkhomedir lo hace automáticamente la primera vez que entran. Actívalo con pam-auth-update, que edita los archivos de /etc/pam.d/ de forma segura:

sudo pam-auth-update --enable mkhomedir

Comprueba que el módulo quedó en la pila de sesión:

grep mkhomedir /etc/pam.d/common-session

session	optional			pam_mkhomedir.so

Paso 6: Limitar quién puede iniciar sesión

Por defecto cualquier usuario del dominio puede entrar en el servidor. Restringe el acceso a los grupos linux-users y linux-admins:

sudo realm deny --all
sudo realm permit -g linux-users linux-admins

realm escribe esa política en sssd.conf como access_provider = simple y simple_allow_groups. Compruébalo:

sudo grep -E 'access_provider|simple_allow' /etc/sssd/sssd.conf

access_provider = simple
simple_allow_groups = linux-users, linux-admins

Para ver qué decidiría SSSD con un usuario concreto sin iniciar sesión, usa sssctl:

sudo sssctl user-checks your_ad_user

user: your_ad_user
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: your_ad_user
...
pam_acct_mgmt: Success

Con un usuario que no pertenece a ninguno de los dos grupos, pam_acct_mgmt devuelve Permission denied.

Paso 7: Conceder sudo a un grupo del dominio

La forma más sencilla y predecible de dar privilegios es una regla en /etc/sudoers.d que referencie al grupo de AD. Edítala siempre con visudo, que valida la sintaxis antes de guardar:

sudo visudo -f /etc/sudoers.d/ad-admins

%linux-admins ALL=(ALL:ALL) ALL

Si el nombre del grupo tiene espacios, escápalos con barra invertida, por ejemplo %domain\ admins.

Paso 8: Probar el inicio de sesión

Prueba primero desde tu sesión actual, sin cerrar la conexión SSH, para no quedarte fuera si algo falla. Cambia a un usuario del grupo linux-admins:

su - your_ad_user

Password:
Creating directory '/home/your_ad_user'.
your_ad_user@srv01:~$

Ya dentro, comprueba que tienes un ticket de Kerberos y que sudo funciona:

klist
sudo -l

Ticket cache: FILE:/tmp/krb5cc_1215601103_AbCdEf
Default principal: [email protected]
...
User your_ad_user may run the following commands on srv01:
    (ALL : ALL) ALL

Para entrar por SSH con la contraseña del dominio, el servidor tiene que aceptar PasswordAuthentication. Las imágenes cloud de Ubuntu 24.04 lo desactivan en /etc/ssh/sshd_config.d/. Si prefieres mantenerlo desactivado, cada usuario puede usar claves SSH en su ~/.ssh/authorized_keys una vez creado su home.

Alternativa: conectar SSSD a un servidor LDAP

Si tu directorio es OpenLDAP u otro servidor LDAP con esquema POSIX (posixAccount, posixGroup), no se usa realmd. Instala el proveedor LDAP:

sudo apt install sssd-ldap sssd-tools libnss-sss libpam-sss ldap-utils

Crea /etc/sssd/sssd.conf:

sudo nano /etc/sssd/sssd.conf

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam

[domain/example.com]
id_provider = ldap
auth_provider = ldap
access_provider = simple
simple_allow_groups = linux-users

ldap_uri = ldaps://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=sssd-reader,ou=services,dc=example,dc=com
ldap_default_authtok = your_bind_password
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

cache_credentials = True
fallback_homedir = /home/%u
default_shell = /bin/bash

La cuenta sssd-reader solo necesita permisos de lectura. ldap_tls_reqcert = demand obliga a validar el certificado del servidor LDAP; si lo firma una CA interna, cópiala a /usr/local/share/ca-certificates/ y ejecuta sudo update-ca-certificates. SSSD no permite autenticar contra LDAP sin cifrado, así que usa siempre ldaps:// o StartTLS.

Aplica los mismos pasos finales que con AD:

sudo chmod 600 /etc/sssd/sssd.conf
sudo sssctl config-check
sudo systemctl restart sssd
sudo pam-auth-update --enable mkhomedir
getent passwd your_ldap_user

Solución de problemas

realm join falla con Couldn't authenticate to active directory o errores de reloj. Revisa la diferencia horaria con el controlador y que el nombre de host sea un FQDN del dominio (paso 1).

id usuario devuelve no such user. Comprueba que el dominio está en línea y que sss aparece en /etc/nsswitch.conf:

sudo sssctl domain-status ad.example.com
grep -E '^(passwd|group)' /etc/nsswitch.conf

La salida debe incluir Online status: Online y las líneas passwd: files systemd sss y group: files systemd sss.

Cambios en AD que no se reflejan en el servidor. SSSD sirve los datos desde su caché. Invalídala para un usuario o para todo:

sudo sss_cache -u your_ad_user
sudo sss_cache -E

Necesitas más detalle. Añade debug_level = 6 en la sección [domain/...], reinicia SSSD y revisa /var/log/sssd/sssd_ad.example.com.log. Vuelve a quitar la línea cuando termines, porque genera mucho registro.

Conclusión

El servidor Ubuntu 24.04 está unido a Active Directory: los usuarios del dominio se resuelven con nombres cortos, solo los grupos autorizados pueden entrar, el grupo linux-admins tiene sudo y los homes se crean en el primer inicio de sesión, con credenciales en caché para cuando el controlador no responda. Como siguientes pasos puedes automatizar la unión de nuevos servidores con Ansible usando los mismos comandos, distribuir claves SSH públicas desde AD con sss_ssh_authorizedkeys o centralizar las reglas de sudo en el propio directorio.