Problema

En entornos mixtos Windows + Linux, los administradores suelen querer que los usuarios accedan a servidores Ubuntu usando sus credenciales de Active Directory (AD) y, además, que la autenticación requiera un factor adicional. La combinación típica es:

  1. LDAP + Kerberos para validar el usuario contra AD.
  2. Google Authenticator (TOTP) como segundo factor.

El síntoma más frecuente es que el ticket Kerberos se obtiene, pero los comandos id, getent passwd o sudo siguen fallando. Los logs de SSSD muestran “offline” o errores de TLS, mientras que la conectividad de red y el DNS funcionan. El problema suele radicar en la configuración de SSSD, en la cadena de certificados o en la integración de PAM con el módulo de Google Authenticator.

Causa

1. Configuración incompleta de SSSD

  • ldap_id_mapping desactivado o mal definido impide que SSSD traduzca los SID de AD a UID/GID.
  • krb5_realm o realms incorrectos hacen que el ticket se obtenga pero no se valide contra el KDC.
  • ldap_tls_reqcert en demand sin que el certificado de la CA interna esté importado genera “offline”.

2. Certificado de la CA no confiado por el cliente

Incluso si el certificado está en /etc/ssl/certs, OpenLDAP lo ignora si la ruta no está incluida en ldap.conf o si el archivo está en formato PEM incompleto.

3. Orden de los módulos PAM

El módulo pam_google_authenticator.so debe ejecutarse después de la autenticación basada en Kerberos, pero antes de la autorización. Un orden invertido hace que el segundo factor nunca se solicite o que la sesión sea rechazada antes de validar el ticket.

4. Falta de mapeo de grupos de AD a sudoers

Sin una regla que convierta los grupos de AD a sudo en el archivo /etc/sudoers.d/sssd, los usuarios autenticados no pueden escalar privilegios, lo que se interpreta como “login no funciona”.

Solución

Paso 1 – Preparar la CA y los paquetes

apt-get update
apt-get install -y sssd libpam-google-authenticator libnss-sss libpam-sss
cp /path/to/internal-ca.pem /usr/local/share/ca-certificates/internal-ca.crt
update-ca-certificates

Asegúrate de que el archivo PEM contenga la cadena completa (root + intermediate).

Paso 2 – Configurar /etc/sssd/sssd.conf

[sssd]
domains = AD
config_file_version = 2
services = nss, pam

[domain/AD]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad

# LDAP/TLS
ldap_id_mapping = true
ldap_schema = rfc2307bis
ldap_user_search_base = OU=Users,DC=example,DC=com
ldap_group_search_base = OU=Groups,DC=example,DC=com
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_reqcert = demand

# Kerberos
krb5_realm = EXAMPLE.COM
krb5_server = ad.example.com
krb5_kpasswd = ad.example.com
cache_credentials = true
enumerate = false
  • ldap_id_mapping = true permite que SSSD genere UID/GID a partir del SID.
  • enumerate = false evita consultas costosas que suelen saturar el controlador AD.
  • Reinicia y habilita el servicio:
systemctl restart sssd
systemctl enable sssd

Paso 3 – Integrar Google Authenticator en PAM

Edita /etc/pam.d/sshd y coloca el módulo en la posición correcta:

#%PAM-1.0
auth    required    pam_sepermit.so
auth    sufficient  pam_ldap.so use_first_pass
auth    required    pam_google_authenticator.so nullok
auth    required    pam_unix.so try_first_pass
account required    pam_nologin.so
account sufficient  pam_ldap.so
account required    pam_unix.so
password sufficient pam_ldap.so
session required    pam_limits.so
session required    pam_unix.so
  • nullok permite que usuarios sin TOTP aún puedan iniciar sesión (útil para pruebas). En producción, elimínalo.
  • Cada usuario debe ejecutar google-authenticator una vez para crear ~/.google_authenticator.

Paso 4 – Mapear grupos AD a sudo

Crea /etc/sudoers.d/sssd:

%domain\\admins ALL=(ALL) ALL
%domain\\linux-admins ALL=(ALL) NOPASSWD: ALL

Reemplaza domain por el nombre NetBIOS del dominio. Con sss como backend, SSSD expone los grupos de AD como domain\group.

Paso 5 – Ajustar SSHD

En /etc/ssh/sshd_config habilita PAM y GSSAPI:

UsePAM yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
PasswordAuthentication no
ChallengeResponseAuthentication yes

Reinicia SSH:

systemctl restart sshd

Cuándo aplicar esta solución

  • Síntomas: Kerberos ticket se obtiene, pero id y sudo devuelven “no such user” o “permission denied”. Los logs de SSSD indican “offline” o “TLS verification failed”.
  • Entorno: Ubuntu Server (cualquier versión LTS) que necesita autenticación centralizada contra AD y MFA basada en TOTP.
  • No aplica: Cuando se usa LDAP simple sin Kerberos, o cuando la política de MFA está gestionada por Azure AD/Entra ID con flujo web. En esos casos, la integración con SSSD no es necesaria.

Código

# Instalar paquetes
apt-get install -y sssd libpam-google-authenticator libnss-sss libpam-sss

# Copiar CA y actualizar trust store
cp /path/to/internal-ca.pem /usr/local/share/ca-certificates/internal-ca.crt
update-ca-certificates

# Configurar sssd.conf (ejemplo completo)
cat > /etc/sssd/sssd.conf <<'EOF'
[sssd]
domains = AD
config_file_version = 2
services = nss, pam

[domain/AD]
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = ad
ldap_id_mapping = true
ldap_schema = rfc2307bis
ldap_user_search_base = OU=Users,DC=example,DC=com
ldap_group_search_base = OU=Groups,DC=example,DC=com
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_reqcert = demand
krb5_realm = EXAMPLE.COM
krb5_server = ad.example.com
krb5_kpasswd = ad.example.com
cache_credentials = true
enumerate = false
EOF

chmod 600 /etc/sssd/sssd.conf
systemctl restart sssd
systemctl enable sssd

# PAM para sshd
sed -i '/@include common-auth/a auth required pam_google_authenticator.so nullok' /etc/pam.d/sshd

# Sudoers para grupos AD
cat > /etc/sudoers.d/sssd <<'EOF'
%EXAMPLE\\admins ALL=(ALL) ALL
%EXAMPLE\\linux-admins ALL=(ALL) NOPASSWD: ALL
EOF
chmod 440 /etc/sudoers.d/sssd

# SSHD ajustes
sed -i 's/^#\?UsePAM .*/UsePAM yes/' /etc/ssh/sshd_config
sed -i 's/^#\?GSSAPIAuthentication .*/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

Verificación

  1. Ticket Kerberos

    kinit [email protected]
klist

    El ticket debe mostrarse sin errores.

  2. Resolución de usuarios

    getent passwd usuario
id usuario

    La salida debe incluir UID/GID generados por SSSD.

  3. SSH con MFA

    ssh usuario@ubuntu-host

    Después de la contraseña (Kerberos), se pedirá el código TOTP. Ingresar el código generado por google-authenticator.

  4. Sudo

    sudo -l -U usuario

    Debe listar los comandos permitidos según los grupos AD.

  5. Logs
    Revisar /var/log/sssd/sssd_AD.log y /var/log/auth.log para confirmar que no aparecen errores de TLS o de PAM.

Notas adicionales

  • Rotación de certificados: cuando la CA interna renueve su certificado, vuelve a copiarlo y ejecuta update-ca-certificates; no es necesario reiniciar SSSD, pero un systemctl reload sssd ayuda.
  • Bloqueo de usuarios: SSSD respeta la política de bloqueo de AD. Si un usuario está deshabilitado, ssh fallará antes de llegar a Google Authenticator.
  • Modo “nullok”: útil para migraciones graduales. En producción, quítalo para forzar MFA a todos los usuarios.
  • Depuración: aumenta la verbosidad de SSSD con debug_level = 9 en [sssd] y revisa journalctl -u sssd.
  • Escalabilidad: desactivar enumerate reduce la carga en el controlador AD y evita que SSSD haga listados completos de usuarios y grupos en cada inicio.

Con estos pasos, los servidores Ubuntu pueden confiar en AD para la primera capa de autenticación y en Google Authenticator para el factor adicional, manteniendo una experiencia de login coherente y segura en entornos híbridos.