Linux integrado con Active Directory: unir un servidor al dominio con SSSDLinux joined to Active Directory: joining a server to the domain with SSSD

Qué vas a conseguir

Que los administradores entren en los servidores Linux con su cuenta de Active Directory (la misma contraseña, la misma baja cuando se van) y que sudo dependa de un grupo de AD en lugar de una lista local en cada máquina. Las cuentas locales quedan solo para emergencias.

Antes de empezar

• Un servidor RHEL o Ubuntu con DNS apuntando a los controladores de dominio y la hora sincronizada (Kerberos no perdona más de cinco minutos de desfase).
• Una cuenta de AD con permiso para unir equipos a la OU donde van los servidores Linux (OU=Linux,OU=Servers,DC=contoso,DC=local), no un Domain Admin.
• Dos grupos de AD creados: sg-linux-admins (sudo) y sg-linux-ssh (acceso por SSH).
• Una sesión SSH abierta con la cuenta local durante todo el proceso.

1. Requisitos y descubrimiento

›sudo dnf install -y realmd sssd oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation›timedatectl | grep -E 'synchronized|Time zone'                Time zone: Europe/Madrid (CEST, +0200)System clock synchronized: yes›dig +short _ldap._tcp.contoso.local SRV | head -20 100 389 dc01.contoso.local.0 100 389 dc02.contoso.local.›realm discover contoso.localcontoso.local  type: kerberos  realm-name: CONTOSO.LOCAL  domain-name: contoso.local  configured: no  server-software: active-directory  client-software: sssd  required-package: oddjob  required-package: oddjob-mkhomedir  required-package: sssd  required-package: adcli  required-package: samba-common-tools

En Ubuntu los paquetes son realmd sssd-ad sssd-tools adcli libnss-sss libpam-sss packagekit. Si realm discover no devuelve nada, el problema es DNS: para en ese punto.

2. Unir al dominio

›sudo realm join --user=svc-linux-join --computer-ou="OU=Linux,OU=Servers,DC=contoso,DC=local" --os-name="RHEL" --os-version="9.4" contoso.localPassword for svc-linux-join:›realm listcontoso.local  configured: kerberos-member  login-formats: %U@contoso.local  login-policy: allow-realm-logins›id laura.prado@contoso.localuid=1483201105(laura.prado@contoso.local) gid=1483200513(domain users@contoso.local) groups=1483200513(domain users@contoso.local),1483201204(sg-linux-admins@contoso.local)

El id que resuelve un usuario de AD con sus grupos es la prueba de que SSSD habla con el dominio. En AD aparece el objeto de equipo SRV-APP-01 en la OU indicada; apunta en el ticket el nombre y la OU.

3. Afinar SSSD: nombres cortos y acceso por grupo

[sssd]domains = contoso.localconfig_file_version = 2services = nss, pam [domain/contoso.local]default_shell = /bin/bashkrb5_store_password_if_offline = Truecache_credentials = Truekrb5_realm = CONTOSO.LOCALrealmd_tags = manages-system joined-with-adcliid_provider = adfallback_homedir = /home/%uad_domain = contoso.localuse_fully_qualified_names = Falseldap_id_mapping = Trueaccess_provider = adad_gpo_access_control = disabled

›sudo chmod 600 /etc/sssd/sssd.conf && sudo systemctl restart sssd›sudo realm permit -g sg-linux-ssh@contoso.local›sudo realm permit -g sg-linux-admins@contoso.local›realm list | grep permitted  permitted-groups: sg-linux-ssh@contoso.local, sg-linux-admins@contoso.local›id laura.pradouid=1483201105(laura.prado) gid=1483200513(domain users) groups=1483200513(domain users),1483201204(sg-linux-admins)

use_fully_qualified_names = False permite ssh laura.prado@srv-app-01 en lugar del @contoso.local detrás. realm permit -g cambia login-policy a allow-permitted-logins: solo los grupos listados entran, los demás usuarios del dominio reciben "Permission denied" aunque la contraseña sea correcta. ad_gpo_access_control = disabled evita que una GPO de "Allow log on locally" pensada para Windows bloquee el acceso a Linux; cámbialo a enforcing solo si gestionas esas GPO a propósito.

4. sudo por grupo de AD

›echo '%sg-linux-admins ALL=(ALL) ALL' | sudo tee /etc/sudoers.d/10-ad-linux-admins›sudo chmod 440 /etc/sudoers.d/10-ad-linux-admins && sudo visudo -c/etc/sudoers: parsed OK/etc/sudoers.d/10-ad-linux-admins: parsed OK# prueba desde otra sesión, con la cuenta de AD:›ssh laura.prado@srv-app-01 'sudo -n true && echo SUDO_OK'SUDO_OK

Ya no hay lista de administradores en el servidor: la gestiona quien gestiona sg-linux-admins en AD, y la baja de la guía de Active Directory del Nivel 1 corta el acceso a todos los servidores a la vez. Con Ansible, todo este artículo es un rol que se aplica a la flota.

5. Cuando el login de dominio falla

›sudo systemctl status sssd --no-pager | head -3● sssd.service - System Security Services Daemon     Active: active (running) since Wed 2026-10-22 07:01:12 CEST; 3h ago›sudo sssctl domain-status contoso.localOnline status: OfflineActive server: not connected›sudo journalctl -u sssd -p err -S "1 hour ago" --no-pager | tail -3oct 22 09:58:40 srv-app-01 sssd_be[1322]: Backend is offline›kinit laura.pradokinit: Cannot find KDC for realm "CONTOSO.LOCAL" while getting initial credentials›dig +short dc01.contoso.local

Los tres comandos: sssctl domain-status (¿ve al dominio?), journalctl -u sssd -p err (¿por qué no?) y kinit (¿Kerberos funciona independientemente de SSSD?). Aquí el DNS dejó de resolver los controladores: alguien cambió /etc/resolv.conf o NetworkManager pisó la configuración. Otros clásicos: desfase de hora (timedatectl, error Clock skew too great), contraseña del equipo caducada tras una restauración desde snapshot (sudo adcli update o volver a hacer realm leave y realm join), y la caché de SSSD con un grupo antiguo (sudo sss_cache -E).

6. Lo que revisas cada mes

• Servidores Linux en la OU de AD cuyo lastLogon del objeto de equipo tiene más de 30 días: ya no existen o SSSD no está arrancando.
• Miembros de sg-linux-admins: la revisión trimestral de accesos del repo 27 cubre este grupo igual que los de administrador de M365.
• Cuentas locales con contraseña en los servidores (sudo awk -F: '$2 !~ /^[!*]/ {print $1}' /etc/shadow): solo la de emergencia.
• Que realm list sigue en allow-permitted-logins después de cada reinstalación o restauración.

Siguientes pasos

• Claves SSH desde AD: con ldap_user_ssh_public_key = altSecurityIdentities en SSSD y AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys en sshd_config, la clave pública vive en el objeto de usuario.
• Kerberos para servicios: un servidor web o PostgreSQL (guía de bases de datos) autenticando con el ticket del usuario, sin contraseña, con el keytab que realm join ya ha creado en /etc/krb5.keytab.
• Para flotas grandes, FreeIPA/IdM con confianza hacia AD da sudo, HBAC y claves centralizadas con una consola; hasta entonces, SSSD directo es suficiente.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.