# Autenticación de usuarios de Active Directory en Linux con restricción por OU usando SSSD

- Link: https://binariocero.com/linux/autenticacion-de-usuarios-de-active-directory-en-linux-con-restriccion-por-ou-usando-sssd
- Published: 2025-08-09T12:16:52+02:00
- Author: Juan José Fernández Durán

![Loading](https://binariocero.com/wp-content/plugins/page-views-count/ajax-loader-
2x.gif)

En entornos empresariales, es habitual centralizar la autenticación de usuarios 
mediante **Active Directory (AD)**. Integrar sistemas Linux en este tipo de infraestructuras
permite a los usuarios autenticarse con sus credenciales de dominio y acceder a 
recursos de forma unificada.

Este artículo explica paso a paso un script Bash que configura un sistema Linux 
basado en **Debian/Ubuntu** para autenticarse contra un dominio de Active Directory,**
restringiendo el acceso SSH únicamente a los usuarios que pertenecen a una Unidad
Organizativa (OU) específica**.

## Objetivo del script

El objetivo del script es:

 1. Instalar las dependencias necesarias para autenticación contra AD.
 2. Configurar la creación automática de directorios home.
 3. Configurar SSSD con un filtro LDAP para restringir el acceso solo a miembros de
    una OU.
 4. Asegurar que el servicio SSH permite el inicio de sesión de usuarios del dominio.
 5. Reiniciar los servicios afectados para aplicar los cambios.

    ```wp-block-code
    #!/bin/bash

    set -e

    DOMINIO="midominio.local"
    REALM="${DOMINIO^^}"  # en mayúsculas
    OU_PERMITIDA="OU=PermitidosSSH,DC=midominio,DC=local"  # <-- ajusta según tu AD

    echo "[INFO] Instalando dependencias necesarias para autenticación con AD..."
    apt update
    apt install -y sssd sssd-tools libnss-sss libpam-sss oddjob oddjob-mkhomedir

    echo "[INFO] Configurando creación automática de directorios home..."
    pam_file="/etc/pam.d/common-session"
    if ! grep -q "pam_mkhomedir.so" "$pam_file"; then
        echo "session required pam_mkhomedir.so skel=/etc/skel umask=0077" >> "$pam_file"
    fi

    echo "[INFO] Configurando SSSD para restringir inicio de sesión a una OU específica..."

    cat >/etc/sssd/sssd.conf <<EOF
    [sssd]
    domains = ${DOMINIO}
    config_file_version = 2
    services = nss, pam, ssh

    [domain/${DOMINIO}]
    ad_domain = ${DOMINIO}
    krb5_realm = ${REALM}
    realmd_tags = manages-system joined-with-samba
    cache_credentials = True
    id_provider = ad
    access_provider = ldap
    ldap_access_order = filter
    ldap_access_filter = (memberOf=CN=PermitidosSSH,${OU_PERMITIDA})
    default_shell = /bin/bash
    fallback_homedir = /home/%u
    ldap_id_mapping = true
    EOF

    chmod 600 /etc/sssd/sssd.conf

    echo "[INFO] Reiniciando SSSD..."
    systemctl restart sssd

    echo "[INFO] Configurando SSH para usar PAM y permitir usuarios de dominio..."
    sshd_config="/etc/ssh/sshd_config"

    # Asegurar que se usa PAM
    if ! grep -q "^UsePAM yes" "$sshd_config"; then
        echo "UsePAM yes" >> "$sshd_config"
    fi

    # (Opcional) Si se desea, restringir por grupo adicionalmente (además del filtro de SSSD)
    # echo "AllowGroups domain^PermitidosSSH@${REALM}" >> "$sshd_config"

    systemctl restart ssh

    echo "[INFO] Configuración completada."
    ```

## Detalles del script

### 1. Variables configurables

    ```wp-block-preformatted
    DOMINIO="midominio.local"REALM="${DOMINIO^^}"OU_PERMITIDA="OU=PermitidosSSH,DC=midominio,DC=local"
    ```

 * `DOMINIO`: Define el nombre del dominio AD.
 * `REALM`: Es el dominio en mayúsculas, utilizado en Kerberos.
 * `OU_PERMITIDA`: Especifica la Unidad Organizativa de AD que contiene a los usuarios
   autorizados para acceder vía SSH.

### 2. Instalación de paquetes necesarios

    ```wp-block-preformatted
    apt updateapt install -y sssd sssd-tools libnss-sss libpam-sss oddjob oddjob-mkhomedir
    ```

Se instalan paquetes esenciales para que el sistema pueda:

 * Integrarse con AD (`sssd`, `libnss-sss`, `libpam-sss`)
 * Crear automáticamente el directorio home de los usuarios al iniciar sesión (`
   oddjob-mkhomedir`)

### 3. Activación de la creación automática del directorio home

    ```wp-block-preformatted
    echo "session required pam_mkhomedir.so skel=/etc/skel umask=0077" >> /etc/pam.d/common-session
    ```

Este paso asegura que cada usuario de AD tendrá su propio directorio home al iniciar
sesión por primera vez.

### 4. Configuración de SSSD

    ```wp-block-preformatted
    cat >/etc/sssd/sssd.conf <<EOF...EOF
    ```

Se crea el archivo de configuración principal de SSSD, donde:

 * Se define el dominio y realm.
 * Se establece el proveedor de identidad (`id_provider = ad`).
 * Se configura un filtro LDAP con `ldap_access_filter` para restringir el acceso
   a miembros de un grupo específico dentro de la OU indicada: ldapCopiarEditar`(
   memberOf=CN=PermitidosSSH,OU=PermitidosSSH,DC=midominio,DC=local)`
 * Se establecen otras opciones como shell por defecto y directorio home.

> **Importante:** El archivo `/etc/sssd/sssd.conf` debe tener permisos `600` por
> seguridad.

### 5. Reinicio de servicios

    ```wp-block-preformatted
    systemctl restart sssd
    ```

Después de configurar SSSD, se reinicia el servicio para aplicar los cambios.

### 6. Configuración de SSH

    ```wp-block-preformatted
    echo "UsePAM yes" >> /etc/ssh/sshd_configsystemctl restart ssh
    ```

Se asegura que el demonio SSH utiliza PAM para validar usuarios mediante SSSD.

> Opcionalmente, puede usarse la directiva `AllowGroups` para aplicar una capa adicional
> de filtrado en SSH.

## Consideraciones finales

 * Este script asume que la máquina ya está unida al dominio AD (por ejemplo, usando`
   realm join` o `net ads join`).
 * Asegúrate de que el sistema puede resolver correctamente el dominio (`/etc/resolv.
   conf` con el DNS del controlador de dominio).
 * La OU y el grupo deben existir previamente en AD, con los usuarios correctamente
   asignados.

## Conclusión

Este script proporciona una forma automatizada y segura de integrar un sistema Linux
en un entorno Active Directory, restringiendo el acceso SSH únicamente a usuarios
de una OU específica. Es especialmente útil en escenarios donde se requiere un control
estricto de quién puede acceder remotamente a los servidores.

Si deseas ampliar este procedimiento, podrías:

 * Añadir logging o control de errores más detallado.
 * Convertirlo en un _playbook_ de Ansible para gestión masiva.
 * Integrarlo con herramientas de gestión remota como NinjaOne o scripts de hardening.