---
title: "Cómo unir Ubuntu 24.04 a Active Directory con SSSD"
description: "Une un servidor Ubuntu 24.04 a Active Directory con realmd y SSSD, limita el acceso por grupos, concede sudo a un grupo del dominio y crea los home al entrar."
category: "Gestión de Identidad y Acceso"
language: es
source: https://cubepath.com/es/docs/gestión-de-identidad-y-acceso/gestion-centralizada-de-usuarios-con-sssd
updated: 2026-09-25
---

# Cómo unir Ubuntu 24.04 a Active Directory con SSSD

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:

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

```output
_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:

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

```output
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:

```bash
timedatectl status | grep synchronized
```

```output
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:

```bash
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:

```bash
realm discover ad.example.com
```

```output
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:

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

```output
 * 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:

```bash
realm list
id your_ad_user@ad.example.com
```

```output
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(your_ad_user@ad.example.com) gid=1215600513(domain users@ad.example.com) groups=1215600513(domain users@ad.example.com),1215601108(linux-users@ad.example.com)
```

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 (`usuario@ad.example.com`) y homes en `/home/usuario@ad.example.com`. En un entorno con un solo dominio es más cómodo usar nombres cortos. Abre el archivo:

```bash
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`:

```ini
[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:

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

```output
Issues identified by validators: 0
```

Ahora el usuario se resuelve sin el sufijo del dominio:

```bash
getent passwd your_ad_user
```

```output
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:

```bash
sudo pam-auth-update --enable mkhomedir
```

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

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

```output
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`:

```bash
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:

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

```output
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`:

```bash
sudo sssctl user-checks your_ad_user
```

```output
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:

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

```text
%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`:

```bash
su - your_ad_user
```

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

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

```bash
klist
sudo -l
```

```output
Ticket cache: FILE:/tmp/krb5cc_1215601103_AbCdEf
Default principal: your_ad_user@AD.EXAMPLE.COM
...
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:

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

Crea `/etc/sssd/sssd.conf`:

```bash
sudo nano /etc/sssd/sssd.conf
```

```ini
[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:

```bash
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`:

```bash
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:

```bash
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.