Menu Close
Settings Close

Language and Page Formatting Options

Integración de los sistemas RHEL directamente con Windows Active Directory

Red Hat Enterprise Linux 8

Comprender y configurar los sistemas RHEL para que se conecten directamente con Active Directory

Resumen

Esta colección de documentación proporciona instrucciones sobre cómo integrar los sistemas RHEL directamente con Windows Active Directory utilizando SSSD.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a sustituir el lenguaje problemático en nuestro código, documentación y propiedades web. Estamos empezando con estos cuatro términos: maestro, esclavo, lista negra y lista blanca. Debido a la enormidad de este esfuerzo, estos cambios se implementarán gradualmente a lo largo de varias versiones próximas. Para más detalles, consulte el mensaje de nuestro CTO Chris Wright.

Proporcionar comentarios sobre la documentación de Red Hat

Agradecemos su opinión sobre nuestra documentación. Por favor, díganos cómo podemos mejorarla. Para ello:

  • Para comentarios sencillos sobre pasajes concretos:

    1. Asegúrese de que está viendo la documentación en el formato Multi-page HTML. Además, asegúrese de ver el botón Feedback en la esquina superior derecha del documento.
    2. Utilice el cursor del ratón para resaltar la parte del texto que desea comentar.
    3. Haga clic en la ventana emergente Add Feedback que aparece debajo del texto resaltado.
    4. Siga las instrucciones mostradas.
  • Para enviar comentarios más complejos, cree un ticket de Bugzilla:

    1. Vaya al sitio web de Bugzilla.
    2. Como componente, utilice Documentation.
    3. Rellene el campo Description con su sugerencia de mejora. Incluya un enlace a la(s) parte(s) pertinente(s) de la documentación.
    4. Haga clic en Submit Bug.

Capítulo 1. Conexión de sistemas RHEL directamente a AD mediante SSSD

Esta sección describe el uso del demonio de servicios de seguridad del sistema (SSSD) para conectar un sistema RHEL a Active Directory (AD). Se necesitan dos componentes para conectar un sistema RHEL a Active Directory (AD). Un componente, SSSD, interactúa con el origen central de identidad y autenticación, y el otro componente, realmd, detecta los dominios disponibles y configura los servicios del sistema RHEL subyacente, en este caso SSSD, para conectarse al dominio.

1.1. Visión general de la integración directa mediante SSSD

Se utiliza SSSD para acceder a un directorio de usuarios para la autenticación y autorización a través de un marco común con el almacenamiento en caché de los usuarios para permitir los inicios de sesión sin conexión. SSSD es altamente configurable; proporciona integración de Módulos de Autenticación Conectables (PAM) y Servicio de Cambio de Nombre (NSS) y una base de datos para almacenar usuarios locales así como datos de usuario extendidos recuperados de un servidor central. SSSD es el componente recomendado para conectar un sistema RHEL con uno de los siguientes tipos de servidor de identidad:

  • Directorio Activo
  • Gestión de identidades (IdM) en RHEL
  • Cualquier servidor genérico LDAP o Kerberos
Nota

La integración directa con SSSD sólo funciona por defecto dentro de un único bosque de AD.

La forma más conveniente de configurar SSSD para integrar directamente un sistema Linux con AD es utilizar el servicio realmd. Éste permite configurar la autenticación de red y la pertenencia a un dominio de forma estándar. El servicio realmd descubre automáticamente información sobre los dominios y reinos accesibles y no requiere una configuración avanzada para unirse a un dominio o reino.

Puede utilizar SSSD tanto para la integración directa como indirecta con AD y le permite cambiar de un enfoque de integración a otro. La integración directa es una forma sencilla de introducir los sistemas RHEL en un entorno AD. Sin embargo, a medida que crece la proporción de sistemas RHEL, sus implantaciones suelen necesitar una mejor gestión centralizada de las políticas relacionadas con la identidad, como el control de acceso basado en host, sudo o las asignaciones de usuarios de SELinux. Inicialmente, puede mantener la configuración de estos aspectos de los sistemas RHEL en archivos de configuración locales. Sin embargo, con un número creciente de sistemas, la distribución y gestión de los archivos de configuración es más fácil con un sistema de aprovisionamiento como Red Hat Satellite. Cuando la integración directa ya no es escalable, debe considerar la integración indirecta. Para más información sobre cómo pasar de la integración directa (los clientes RHEL están en el dominio AD) a la integración indirecta (IdM con confianza en AD), consulte Mover los clientes RHEL del dominio AD al servidor IdM.

Para más información sobre qué tipo de integración se ajusta a su caso de uso, consulte Decidir entre la integración indirecta y la directa.

Recursos adicionales

  • La página de manual realm(8).
  • La página de manual sssd-ad(5).
  • La página de manual sssd(8).

1.2. Plataformas Windows compatibles con la integración directa

Puede integrar directamente su sistema RHEL con los bosques de Active Directory que utilizan los siguientes niveles funcionales de bosque y dominio:

  • Rango de nivel funcional del bosque: Windows Server 2008 - Windows Server 2016
  • Rango de nivel funcional del dominio: Windows Server 2008 - Windows Server 2016

La integración directa se ha probado en los siguientes sistemas operativos compatibles:

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
Nota

Windows Server 2019 no introduce un nuevo nivel funcional. El nivel funcional más alto que utiliza Windows Server 2019 es Windows Server 2016.

1.3. Garantizar la compatibilidad con los tipos de cifrado comunes en AD y RHEL

Por defecto, SSSD soporta los tipos de cifrado RC4, AES-128 y AES-256 de Kerberos.

El cifrado RC4 ha sido obviado y deshabilitado por defecto en RHEL 8, ya que se considera menos seguro que los nuevos tipos de cifrado AES-128 y AES-256. Por el contrario, las credenciales de usuario de Active Directory (AD) y los fideicomisos entre dominios AD admiten el cifrado RC4 y es posible que no admitan los tipos de cifrado AES.

Sin ningún tipo de cifrado común, es posible que la comunicación entre los hosts RHEL y los dominios AD no funcione, o que algunas cuentas AD no puedan autenticarse. Para remediar esta situación, modifique una de las siguientes configuraciones:

  • Enable AES encryption support in Active Directory (recommended option): Para garantizar que los fideicomisos entre los dominios de AD en un bosque de AD admiten tipos de cifrado AES fuertes, consulte el siguiente artículo de Microsoft: AD DS: Seguridad: Kerberos \ "Unsupported etype" error al acceder a un recurso en un dominio de confianza
  • Enable RC4 support in RHEL: En cada host RHEL donde se realiza la autenticación contra los controladores de dominio AD:

    1. Utilice el comando update-crypto-policies para activar la subpolítica criptográfica AD-SUPPORT además de la política criptográfica DEFAULT.

      [root@host ~]# update-crypto-policies --set DEFAULT:AD-SUPPORT
      Setting system policy to DEFAULT:AD-SUPPORT
      Note: System-wide crypto policies are applied on application start-up.
      It is recommended to restart the system for the change of policies
      to fully take place.
    2. Reinicia el host.
Importante

La subpolítica criptográfica AD-SUPPORT sólo está disponible en RHEL 8.3 y posteriores.

  • Para habilitar la compatibilidad con RC4 en RHEL 8.2, cree y habilite una política de módulo criptográfico personalizada con cipher = RC4-128 . Para obtener más detalles, consulte Personalizar las políticas criptográficas de todo el sistema con modificadores de políticas.
  • Para habilitar la compatibilidad con RC4 en RHEL 8.0 y RHEL 8.1, añada rc4 a la opción permitted_enctypes en el archivo /etc/crypto-policies/back-ends/krb5.config:

    [libdefaults]
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac +rc4

Recursos adicionales

1.4. Conexión directa a AD

Esta sección describe cómo integrarse directamente con AD utilizando la asignación de ID o los atributos POSIX.

1.4.1. Descubrir y unirse a un dominio AD utilizando SSSD

Este procedimiento describe cómo descubrir un dominio AD y conectar un sistema RHEL a ese dominio utilizando SSSD.

Requisitos previos

  • Asegúrese de que los siguientes puertos del host RHEL están abiertos y son accesibles para los controladores de dominio AD.

    Tabla 1.1. Puertos necesarios para la integración directa de sistemas Linux en AD mediante SSSD

    ServicioPuertoProtocoloNotas

    DNS

    53

    UDP y TCP

     

    LDAP

    389

    UDP y TCP

     

    Kerberos

    88

    UDP y TCP

     

    Kerberos

    464

    UDP y TCP

    Utilizado por kadmin para establecer y cambiar una contraseña

    Catálogo global LDAP

    3268

    TCP

    Si se utiliza la opción id_provider = ad

    NTP

    123

    UDP

    Opcional

  • Asegúrese de que está utilizando el servidor del controlador de dominio AD para el DNS.
  • Compruebe que la hora del sistema en ambos sistemas está sincronizada. Esto garantiza que Kerberos pueda funcionar correctamente.

Procedimiento

  1. Instale los siguientes paquetes:

    # yum install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
  2. Para mostrar la información de un dominio específico, ejecute realm discover y añada el nombre del dominio que desea descubrir:

    # 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: oddjob
      required-package: oddjob-mkhomedir
      required-package: sssd
      required-package: adcli
      required-package: samba-common

    El sistema realmd utiliza las búsquedas DNS SRV para encontrar los controladores de dominio en este dominio automáticamente.

    Nota

    El sistema realmd puede descubrir tanto dominios de Active Directory como de Gestión de Identidades. Si existen ambos dominios en su entorno, puede limitar los resultados del descubrimiento a un tipo específico de servidor utilizando la opción --server-software=active-directory.

  3. Configure el sistema RHEL local con el comando realm join. El conjunto realmd edita automáticamente todos los archivos de configuración necesarios. Por ejemplo, para un dominio llamado ad.example.com:

    # realm join ad.example.com

Pasos de verificación

  • Muestra los detalles de un usuario de AD, como el usuario administrador:

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash

Recursos adicionales

  • Consulte la página de manual realm(8).
  • Consulte la página de manual nmcli(1).

1.4.2. Opciones para la integración con AD: uso de mapeo de ID o atributos POSIX

Los sistemas Linux y Windows utilizan diferentes identificadores para los usuarios y grupos:

  • Linux utiliza user IDs (UID) y group IDs (GID). Ver Gestión de Usuarios y Grupos en Configuring Basic System Settings. Los UIDs y GIDs de Linux cumplen con el estándar POSIX.
  • Windows utiliza security IDs (SID).
Importante

No utilice el mismo nombre de usuario en Windows y Linux.

Para autenticarse en un sistema RHEL como usuario de AD, debe tener asignados un UID y un GID. SSSD ofrece la opción de integrarse con AD utilizando la asignación de ID o los atributos POSIX. La opción por defecto es utilizar el mapeo de ID.

1.4.2.1. Generar automáticamente nuevos UID y GID para los usuarios de AD

SSSD puede utilizar el SID de un usuario de AD para generar algoritmicamente IDs de POSIX en un proceso llamado ID mapping. El mapeo de IDs crea un mapa entre los SIDs en AD y los IDs en Linux.

  • Cuando SSSD detecta un nuevo dominio AD, asigna un rango de IDs disponibles al nuevo dominio.
  • Cuando un usuario de AD se conecta a una máquina cliente de SSSD por primera vez, SSSD crea una entrada para el usuario en la caché de SSSD, incluyendo un UID basado en el SID del usuario y el rango de ID para ese dominio.
  • Debido a que los IDs para un usuario de AD son generados de manera consistente desde el mismo SID, el usuario tiene el mismo UID y GID cuando ingresa a cualquier sistema Red Hat Enterprise Linux.

Consulte Descubrir y unirse a un dominio AD mediante SSSD.

Nota

Cuando todos los sistemas cliente utilizan SSSD para asignar los SID a los ID de Linux, la asignación es coherente. Si algunos clientes utilizan un software diferente, elija uno de los siguientes:

  • Asegúrese de que se utiliza el mismo algoritmo de asignación en todos los clientes.
  • Utilizar atributos POSIX explícitos definidos en AD.

1.4.2.2. Utilizar los atributos POSIX definidos en AD

AD puede crear y almacenar atributos POSIX, como uidNumber, gidNumber, unixHomeDirectory, o loginShell.

Cuando se utiliza el mapeo de IDs descrito anteriormente, SSSD crea nuevos UIDs y GIDs, que anulan los valores definidos en AD. Para mantener los valores definidos por AD, debe desactivar el mapeo de ID en SSSD.

Consulte Conexión a AD mediante atributos POSIX definidos en Active Directory.

1.4.3. Conexión a AD mediante atributos POSIX definidos en Active Directory

Para un mejor rendimiento, publique los atributos POSIX en el catálogo global de AD. Si los atributos POSIX no están presentes en el catálogo global, SSSD se conecta a los controladores de dominio individuales directamente en el puerto LDAP.

Requisitos previos

  • Asegúrese de que los siguientes puertos del host RHEL están abiertos y son accesibles para los controladores de dominio AD.

    Tabla 1.2. Puertos necesarios para la integración directa de sistemas Linux en AD mediante SSSD

    ServicioPuertoProtocoloNotas

    DNS

    53

    UDP y TCP

     

    LDAP

    389

    UDP y TCP

     

    Kerberos

    88

    UDP y TCP

     

    Kerberos

    464

    UDP y TCP

    Utilizado por kadmin para establecer y cambiar una contraseña

    Catálogo global LDAP

    3268

    TCP

    Si se utiliza la opción id_provider = ad

    NTP

    123

    UDP

    Opcional

  • Asegúrese de que está utilizando el servidor del controlador de dominio AD para el DNS.
  • Compruebe que la hora del sistema en ambos sistemas está sincronizada. Esto garantiza que Kerberos pueda funcionar correctamente.

Procedimiento

  1. Instale los siguientes paquetes:

    # yum install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
  2. Configure el sistema RHEL local con el mapeo de ID deshabilitado utilizando el comando realm join con la opción --automatic-id-mapping=no. El conjunto realmd edita automáticamente todos los archivos de configuración necesarios. Por ejemplo, para un dominio llamado ad.example.com:

    # realm join --automatic-id-mapping=no ad.example.com
  3. Si ya se ha unido a un dominio, puede desactivar manualmente la asignación de ID en SSSD:

    1. Abra el archivo /etc/sssd/sssd.conf.
    2. En la sección del dominio AD, añada la configuración ldap_id_mapping = false.
    3. Eliminar las cachés de SSSD:

      rm -f /var/lib/sss/db/*
    4. Reinicie el SSSD:

      systemctl restart sssd

SSSD ahora utiliza los atributos POSIX de AD, en lugar de crearlos localmente.

Nota

Debe tener los atributos POSIX pertinentes (uidNumber, gidNumber, unixHomeDirectory, y loginShell) configurados para los usuarios en AD.

Pasos de verificación

  • Muestra los detalles de un usuario de AD, como el usuario administrador:

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bash

Recursos adicionales

  • Para más detalles sobre la asignación de ID y el parámetro ldap_id_mapping, consulte la página de manual sssd-ldap(8).

1.4.4. Conexión a múltiples dominios en diferentes bosques de AD con SSSD

Este procedimiento describe la unión y autenticación en varios dominios de Active Directory (AD) en diferentes bosques donde no hay confianza entre ellos.

Este ejemplo describe la unión de dos dominios, addomain1.com y addomain2.com. Utilice realmd para unirse al primer dominio y configurar automáticamente SSSD, Kerberos y otras utilidades para ese dominio. Utilice adcli para unirse a dominios adicionales y edite manualmente los archivos de configuración para incluir esos dominios.

Requisitos previos

  • Asegúrese de que los siguientes puertos del host RHEL están abiertos y son accesibles para los controladores de dominio AD.

    Tabla 1.3. Puertos necesarios para la integración directa de sistemas Linux en AD mediante SSSD

    ServicioPuertoProtocoloNotas

    DNS

    53

    UDP y TCP

     

    LDAP

    389

    UDP y TCP

     

    Kerberos

    88

    UDP y TCP

     

    Kerberos

    464

    UDP y TCP

    Utilizado por kadmin para establecer y cambiar una contraseña

    Catálogo global LDAP

    3268

    TCP

    Si se utiliza la opción id_provider = ad

    NTP

    123

    UDP

    Opcional

  • Asegúrese de que está utilizando el servidor del controlador de dominio AD para el DNS.
  • Compruebe que la hora del sistema en ambos sistemas está sincronizada. Esto garantiza que Kerberos pueda funcionar correctamente.
  • Asegúrese de que dispone de credenciales para una cuenta de administrador de AD en cada dominio de AD que tenga derechos para unir máquinas a ese dominio

Procedimiento

  1. Instale los paquetes necesarios.

    # yum install sssd realmd adcli samba-common-tools oddjob oddjob-mkhomedir
  2. Utilice realmd para unirse al primer dominio AD, addomain1.com.

    # realm join ADDOMAIN1.COM
  3. Renombrar el keytab del sistema con un nombre único.

    # mv /etc/krb5.keytab /etc/dominio1.com.krb5.keytab
  4. Utilice adcli para unirse al segundo dominio de AD y a cualquier otro dominio adicional. Utilice la opción -K para especificar una ruta única para el llavero de Kerberos donde se escribirán las credenciales del host.

    # adcli join -D dc2.addomain2.com -K /etc/addomain2.com.krb5.keytab
  5. Modificar /etc/krb5.conf.

    • Añade la opción includedir para incluir los archivos de configuración de SSSD.
    • Habilite las búsquedas de DNS para los controladores de dominio de AD con la opción dns_lookup_kdc.

      includedir /var/lib/sss/pubconf/krb5.include.d/
      
      [logging]
       default = FILE:/var/log/krb5libs.log
       kdc = FILE:/var/log/krb5kdc.log
       admin_server = FILE:/var/log/kadmind.log
      
      [libdefaults]
       default_realm = ADDOMAIN1.COM
       dns_lookup_realm = false
       dns_lookup_kdc = true
       ticket_lifetime = 24h
       renew_lifetime = 7d
       forwardable = true
      
      ...
  6. Modifique /etc/sssd/sssd.conf para incluir información sobre todos los dominios de AD en uso.

    [sssd]
    services = nss, pam
    config_file_version = 2
    domains = addomain1.com, addomain2.com
    
    [domain/addomain1.com]
    id_provider = ad
    access_provider = ad
    krb5_keytab = /etc/addomain1.com.krb5.keytab
    ldap_krb5_keytab = /etc/addomain1.com.krb5.keytab
    ad_server = dc1.addomain1.com
    ad_maximum_machine_account_password_age = 0
    use_fully_qualified_names = true
    default_shell=/bin/bash
    override_homedir=/home/%d/%u
    
    [domain/addomain2.com]
    id_provider = ad
    access_provider = ad
    krb5_keytab = /etc/addomain2.com.krb5.keytab
    ldap_krb5_keytab = /etc/addomain2.com.krb5.keytab
    ad_server = dc2.addomain2.com
    ad_maximum_machine_account_password_age = 0
    use_fully_qualified_names = true
    default_shell=/bin/bash
    override_homedir=/home/%d/%u
    
    [nss]
    
    [pam]
    • Para cada sección de dominio, especifique la ruta al keytab de Kerberos que corresponde a cada dominio con las opciones krb5_keytab y ldap_krb5_keytab.
    • Configure ad_maximum_machine_account_password_age = 0 para desactivar la renovación de las claves Kerberos del host.
    • Establezca use_fully_qualified_names = true para diferenciar a los usuarios de diferentes dominios.
    • Configure override_homedir = /home/%d/%u para que los usuarios (%u) de diferentes dominios (%d) each receive unique home directories. For example, the home directory for user linuxuser@addomain1.com is /home/addomain1.com/linuxuser.
  7. SSH recupera las claves de host del keytab del sistema y proporciona la funcionalidad de single sign-on a través de GSSAPI/Kerberos. Si desea utilizar el inicio de sesión único, copie todas las claves de host Kerberos actuales en el llavero del sistema /etc/kbr5.keytab.

    # ktutil
    ktutil:  rkt /etc/addomain1.com.krb5.keytab
    ktutil:  rkt /etc/addomain2.com.krb5.keytab
    ktutil:  wkt /etc/krb5.keytab
  8. Reinicie y habilite el servicio SSSD.

    # systemctl restart sssd
    # systemctl enable sssd

Pasos de verificación

  1. Muestra los detalles de los usuarios de cada dominio de AD:

    # id administrator@addomain1.com
    uid=1240800500(administrator@addomain1.com) gid=1240800513(domain users@addomain1.com) groups=1240800513(domain users@addomain1.com),1240800512(domain admins@addomain1.com),1240800518(schema admins@addomain1.com),1240800520(group policy creator owners@addomain1.com),1240800572(denied rodc password replication group@addomain1.com),1240800519(enterprise admins@addomain1.com)
    
    # id administrator@addomain2.com
    uid=1013800500(administrator@addomain2.com) gid=1013800500(administrator@addomain2.com) groups=1013800500(administrator@addomain2.com),1013800513(domain users@addomain2.com)
  2. Inicie sesión como un usuario de cada dominio y verifique que se ha creado el directorio raíz correcto para el usuario.

    # ssh administrator@addomain1.com@localhost
    administrator@addomain1.com@localhost's password:
    Creating directory '/home/addomain1.com/administrator'.
    
    $ pwd
    /home/addomain1.com/administrator
    # ssh administrator@addomain2.com@localhost
    administrator@addomain2.com@localhost's password:
    Creating directory '/home/addomain2.com/administrator'.
    
    $ pwd
    /home/addomain2.com/administrator

1.5. Cómo maneja el proveedor de AD las actualizaciones dinámicas de DNS

Active Directory (AD) mantiene activamente sus registros DNS mediante la desactivación (aging) y la eliminación (scavenging) de los registros inactivos.

Por defecto, el servicio SSSD actualiza el registro DNS de un cliente RHEL en los siguientes intervalos:

  • Cada vez que el proveedor de identidad se conecta.
  • Cada vez que el sistema RHEL se reinicia.
  • En el intervalo especificado por la opción dyndns_refresh_interval en el archivo de configuración /etc/sssd/sssd.conf. El valor por defecto es 86400 segundos (24 horas).

    Nota

    Si establece la opción dyndns_refresh_interval con el mismo intervalo que el arrendamiento DHCP, puede actualizar el registro DNS después de que se renueve el arrendamiento IP.

SSSD envía actualizaciones dinámicas de DNS al servidor AD utilizando Kerberos/GSSAPI para DNS (GSS-TSIG). Esto significa que solo es necesario habilitar las conexiones seguras a AD.

Recursos adicionales

  • La página de manual sssd-ad(5).

1.6. Modificación de la configuración del DNS dinámico para el proveedor de AD

El siguiente procedimiento ajusta la configuración dentro del servicio SSSD para afectar a la forma en que actualiza automáticamente el registro DNS para un host RHEL unido a un entorno de Active Directory.

Requisitos previos

  • Ha unido un host RHEL a un entorno de Active Directory con el servicio SSSD.
  • Se necesitan permisos de root para editar el archivo de configuración de /etc/sssd/sssd.conf.

Procedimiento

  1. Abra el archivo de configuración /etc/sssd/sssd.conf en un editor de texto.
  2. Añada las siguientes opciones a la sección [domain] de su dominio AD para establecer el intervalo de actualización del registro DNS en 12 horas, deshabilitar la actualización de los registros PTR y establecer el tiempo de vida (TTL) del registro DNS en 1 hora.

    [domain/ad.example.com]
    id_provider = ad
    ...
    dyndns_refresh_interval = 43200
    dyndns_update_ptr = false
    dyndns_ttl = 3600
  3. Guarde y cierre el archivo de configuración /etc/sssd/sssd.conf.
  4. Reinicie el servicio SSSD para cargar los cambios de configuración.

    [root@client ~]# systemctl restart sssd
Nota

Puede desactivar las actualizaciones dinámicas de DNS configurando la opción dyndns_update en el archivo sssd.conf a false:

[domain/ad.example.com]
id_provider = ad
...

dyndns_update = false

Recursos adicionales

  • sssd-ad(5) página de manual

1.7. Cómo maneja el proveedor de AD los dominios de confianza

Esta sección describe cómo SSSD maneja los dominios de confianza si se establece la opción id_provider = ad en el archivo de configuración /etc/sssd/sssd.conf.

  • SSSD sólo admite dominios en un único bosque de AD. Si SSSD requiere acceso a varios dominios de varios bosques, considere el uso de IPA con fideicomisos (preferido) o el servicio winbindd en lugar de SSSD.
  • Por defecto, SSSD descubre todos los dominios del bosque y, si llega una solicitud de un objeto en un dominio de confianza, SSSD intenta resolverlo.

    Si los dominios de confianza no son alcanzables o están geográficamente distantes, lo que los hace lentos, puede establecer el parámetro ad_enabled_domains en /etc/sssd/sssd.conf para limitar de qué dominios de confianza resuelve objetos SSSD.

  • Por defecto, debe utilizar nombres de usuario totalmente calificados para resolver usuarios de dominios de confianza.

Recursos adicionales

  • La página de manual sssd.conf(5).

1.8. comandos del reino

El sistema realmd tiene dos grandes áreas de trabajo:

  • Gestión de la inscripción del sistema en un dominio.
  • Controlar qué usuarios del dominio pueden acceder a los recursos del sistema local.

En realmd utilice la herramienta de línea de comandos realm para ejecutar comandos. La mayoría de los comandos de realm requieren que el usuario especifique la acción que debe realizar la utilidad, y la entidad, como un dominio o una cuenta de usuario, para la que debe realizar la acción.

Tabla 1.4. comandos de realmd

ComandoDescripción

Realm Commands

descubra

Ejecute un escaneo de detección de dominios en la red.

únase a

Añade el sistema al dominio especificado.

dejar

Eliminar el sistema del dominio especificado.

lista

Enumerar todos los dominios configurados para el sistema o todos los dominios descubiertos y configurados.

Login Commands

permiso

Permitir el acceso a usuarios específicos o a todos los usuarios de un dominio configurado para acceder al sistema local.

denegar

Restringe el acceso de usuarios específicos o de todos los usuarios de un dominio configurado para acceder al sistema local.

Para obtener más información sobre los comandos de realm, consulte la página de manual realm(8).

Capítulo 2. Conexión de los sistemas RHEL directamente a AD mediante Samba Winbind

Esta sección describe el uso de Samba Winbind para conectar un sistema RHEL a Active Directory (AD). Se necesitan dos componentes para conectar un sistema RHEL a AD. Un componente, Samba Winbind, interactúa con el origen de identidad y autenticación de AD, y el otro componente, realmd, detecta los dominios disponibles y configura los servicios del sistema RHEL subyacente, en este caso Samba Winbind, para conectarse al dominio AD.

2.1. Visión general de la integración directa mediante Samba Winbind

Samba Winbind emula un cliente Windows en un sistema Linux y se comunica con los servidores AD.

Puede utilizar el servicio realmd para configurar Samba Winbind:

  • Configurar la autenticación de la red y la pertenencia a un dominio de forma estándar.
  • Descubrir automáticamente la información sobre los dominios y reinos accesibles.
  • No requiere una configuración avanzada para unirse a un dominio o reino.

Tenga en cuenta que:

  • La integración directa con Winbind en una configuración AD multiforestal requiere confianzas bidireccionales.
  • Los bosques remotos deben confiar en el bosque local para garantizar que el complemento idmap_ad maneje correctamente a los usuarios del bosque remoto.

El servicio winbindd de Samba proporciona una interfaz para el conmutador de servicios de nombres (NSS) y permite a los usuarios del dominio autenticarse en AD al iniciar sesión en el sistema local.

El uso de winbindd ofrece la ventaja de que puede mejorar la configuración para compartir directorios e impresoras sin necesidad de instalar software adicional. Para más detalles, consulte la sección sobre el uso de Samba como servidor en la Guía de implementación de diferentes tipos de servidores.

Recursos adicionales

  • Consulte la página de manual realmd.
  • Consulte la página de manual windbindd.

2.2. Plataformas Windows compatibles con la integración directa

Puede integrar directamente su sistema RHEL con los bosques de Active Directory que utilizan los siguientes niveles funcionales de bosque y dominio:

  • Rango de nivel funcional del bosque: Windows Server 2008 - Windows Server 2016
  • Rango de nivel funcional del dominio: Windows Server 2008 - Windows Server 2016

La integración directa se ha probado en los siguientes sistemas operativos compatibles:

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
Nota

Windows Server 2019 no introduce un nuevo nivel funcional. El nivel funcional más alto que utiliza Windows Server 2019 es Windows Server 2016.

2.3. Garantizar la compatibilidad con los tipos de cifrado comunes en AD y RHEL

Por defecto, Samba Winbind soporta los tipos de cifrado RC4, AES-128 y AES-256 Kerberos.

El cifrado RC4 ha sido obviado y deshabilitado por defecto en RHEL 8, ya que se considera menos seguro que los nuevos tipos de cifrado AES-128 y AES-256. Por el contrario, las credenciales de usuario de Active Directory (AD) y los fideicomisos entre dominios AD admiten el cifrado RC4 y es posible que no admitan los tipos de cifrado AES.

Sin ningún tipo de cifrado común, es posible que la comunicación entre los hosts RHEL y los dominios AD no funcione, o que algunas cuentas AD no puedan autenticarse. Para remediar esta situación, modifique una de las siguientes configuraciones:

  • Enable AES encryption support in Active Directory (recommended option): Para garantizar que los fideicomisos entre los dominios de AD en un bosque de AD admiten tipos de cifrado AES fuertes, consulte el siguiente artículo de Microsoft: AD DS: Seguridad: Kerberos \ "Unsupported etype" error al acceder a un recurso en un dominio de confianza
  • Enable RC4 support in RHEL: En cada host RHEL donde se realiza la autenticación contra los controladores de dominio AD:

    1. Utilice el comando update-crypto-policies para activar la subpolítica criptográfica AD-SUPPORT además de la política criptográfica DEFAULT.

      [root@host ~]# update-crypto-policies --set DEFAULT:AD-SUPPORT
      Setting system policy to DEFAULT:AD-SUPPORT
      Note: System-wide crypto policies are applied on application start-up.
      It is recommended to restart the system for the change of policies
      to fully take place.
    2. Reinicia el host.
Importante

La subpolítica criptográfica AD-SUPPORT sólo está disponible en RHEL 8.3 y posteriores.

  • Para habilitar la compatibilidad con RC4 en RHEL 8.2, cree y habilite una política de módulo criptográfico personalizada con cipher = RC4-128 . Para obtener más detalles, consulte Personalizar las políticas criptográficas de todo el sistema con modificadores de políticas.
  • Para habilitar la compatibilidad con RC4 en RHEL 8.0 y RHEL 8.1, añada rc4 a la opción permitted_enctypes en el archivo /etc/crypto-policies/back-ends/krb5.config:

    [libdefaults]
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac +rc4

Recursos adicionales

2.4. Unir un sistema RHEL a un dominio AD

Esta sección describe cómo unir un sistema Red Hat Enterprise Linux a un dominio AD utilizando realmd para configurar Samba Winbind.

Procedimiento

  1. Si su AD requiere el tipo de cifrado RC4 obsoleto para la autenticación Kerberos, habilite el soporte para estos cifrados en RHEL:

    # update-crypto-policies --set DEFAULT:AD-SUPPORT
  2. Instale los siguientes paquetes:

    # yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients \ samba-winbind samba-common-tools samba-winbind-krb5-locator
  3. Para compartir directorios o impresoras en el miembro del dominio, instale el paquete samba:

    # yum install samba
  4. Realice una copia de seguridad del archivo de configuración de Samba existente en /etc/samba/smb.conf:

    # mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
  5. Únase al dominio. Por ejemplo, para unirse a un dominio llamado ad.example.com:

    # realm join --membership-software=samba --client-software=winbind ad.example.com

    Utilizando el comando anterior, la utilidad realm automáticamente:

    • Crea un archivo /etc/samba/smb.conf para un miembro del dominio ad.example.com
    • Añade el módulo winbind para la búsqueda de usuarios y grupos en el archivo /etc/nsswitch.conf
    • Actualiza los archivos de configuración del Pluggable Authentication Module (PAM) en el directorio /etc/pam.d/
    • Inicia el servicio winbind y permite que el servicio se inicie al arrancar el sistema
  6. Opcionalmente, establezca un back end de mapeo de ID alternativo o ajustes de mapeo de ID personalizados en el archivo /etc/samba/smb.conf. Para obtener más detalles, consulte la sección Comprender y configurar la asignación de ID de Samba en la documentación de Deploying different types of servers.
  7. Edite el archivo /etc/krb5.conf y añada la siguiente sección:

    [plugins]
        localauth = {
            module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
            enable_only = winbind
        }
  8. Compruebe que el servicio winbind está en funcionamiento:

    # systemctl status winbind
    ...
       Active: active (running) since Tue 2018-11-06 19:10:40 CET; 15s ago
    Importante

    Para que Samba pueda consultar la información de los usuarios y grupos del dominio, el servicio winbind debe estar funcionando antes de iniciar smb.

  9. Si ha instalado el paquete samba para compartir directorios e impresoras, active e inicie el servicio smb:

    # systemctl enable --now smb

Pasos de verificación

  1. Muestra los detalles de un usuario AD, como la cuenta de administrador AD en el dominio AD:

    # getent passwd "AD\administrator"
    AD\administrator:*:10000:10000::/home/administrator@AD:/bin/bash
  2. Consultar los miembros del grupo de usuarios del dominio en el dominio AD:

    # getent group "AD\Domain Users"
        AD\domain users:x:10000:user1,user2
  3. Opcionalmente, verifique que puede utilizar los usuarios y grupos del dominio cuando establezca los permisos de los archivos y directorios. Por ejemplo, para establecer el propietario del archivo /srv/samba/example.txt como AD\administrator y el grupo como AD\Domain Users:

    # chown "AD\administrator":"AD\Domain Users" /srv/samba/example.txt
  4. Verifique que la autenticación Kerberos funciona como se espera:

    1. En el miembro del dominio AD, obtenga un ticket para la entidad de crédito administrator@AD.EXAMPLE.COM:

      # kinit administrator@AD.EXAMPLE.COM
    2. Muestra el ticket de Kerberos en caché:

      # klist
      Ticket cache: KCM:0
      Default principal: administrator@AD.EXAMPLE.COM
      
      Valid starting       Expires              Service principal
      01.11.2018 10:00:00  01.11.2018 20:00:00  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
              renew until 08.11.2018 05:00:00
  5. Muestra los dominios disponibles:

    # wbinfo --all-domains
    BUILTIN
    SAMBA-SERVER
    AD

Recursos adicionales

2.5. comandos del reino

El sistema realmd tiene dos grandes áreas de trabajo:

  • Gestión de la inscripción del sistema en un dominio.
  • Controlar qué usuarios del dominio pueden acceder a los recursos del sistema local.

En realmd utilice la herramienta de línea de comandos realm para ejecutar comandos. La mayoría de los comandos de realm requieren que el usuario especifique la acción que debe realizar la utilidad, y la entidad, como un dominio o una cuenta de usuario, para la que debe realizar la acción.

Tabla 2.1. comandos de realmd

ComandoDescripción

Realm Commands

descubra

Ejecute un escaneo de detección de dominios en la red.

únase a

Añade el sistema al dominio especificado.

dejar

Eliminar el sistema del dominio especificado.

lista

Enumerar todos los dominios configurados para el sistema o todos los dominios descubiertos y configurados.

Login Commands

permiso

Permitir el acceso a usuarios específicos o a todos los usuarios de un dominio configurado para acceder al sistema local.

denegar

Restringe el acceso de usuarios específicos o de todos los usuarios de un dominio configurado para acceder al sistema local.

Para obtener más información sobre los comandos de realm, consulte la página de manual realm(8).

Capítulo 3. Gestión de las conexiones directas con AD

Esta sección describe cómo modificar y gestionar su conexión con Active Directory.

Requisitos previos

  • Ha conectado su sistema RHEL al dominio de Active Directory.

3.1. Modificación del intervalo de renovación del keytab del host Kerberos por defecto

SSSD renueva automáticamente el archivo keytab del host Kerberos en un entorno AD si el paquete adcli está instalado. El demonio comprueba diariamente si la contraseña de la cuenta de la máquina es más antigua que el valor configurado y la renueva si es necesario.

El intervalo de renovación por defecto es de 30 días. Para cambiar el valor predeterminado, siga los pasos de este procedimiento.

Procedimiento

  1. Añada el siguiente parámetro al proveedor de AD en su archivo /etc/sssd/sssd.conf:

    ad_maximum_machine_account_password_age = value_in_days
  2. Reinicie el SSSD:

    # systemctl restart sssd
  3. Para desactivar la renovación automática del keytab del host Kerberos, configure ad_maximum_machine_account_password_age = 0.

Recursos adicionales

  • La página de manual adcli(8).
  • La página de manual sssd.conf(5).

3.2. Eliminación de un sistema RHEL de un dominio AD

Este procedimiento describe cómo eliminar un sistema RHEL de un dominio de Active Directory (AD).

Procedimiento

  1. Elimine un sistema de un dominio de identidad mediante el comando realm leave. El comando elimina la configuración del dominio de SSSD y del sistema local.

    # licencia de reino ad.example.com
    Nota

    Cuando un cliente abandona un dominio, la cuenta no se elimina de AD; sólo se elimina la configuración local del cliente. Si desea eliminar la cuenta de AD, ejecute el comando con la opción --remove. Se le pedirá la contraseña del usuario y debe tener los derechos para eliminar una cuenta de Active Directory.

  2. Utilice la opción -U con el comando realm leave para especificar un usuario diferente para eliminar un sistema de un dominio de identidad.

    Por defecto, el comando realm leave se ejecuta como administrador por defecto. En el caso de AD, la cuenta de administrador se llama Administrator. Si se utilizó un usuario diferente para unirse al dominio, podría ser necesario realizar la eliminación como ese usuario.

    # realm leave [ad.example.com] -U [AD.EXAMPLE.COM\user]'

El comando primero intenta conectarse sin credenciales, pero solicita una contraseña si es necesario.

Pasos de verificación

  • Compruebe que el dominio ya no está configurado:

    # realm discover [ad.example.com]
    ad.example.com
        type: kerberos
        realm-name: EXAMPLE.COM
        domain-name: example.com
        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

Recursos adicionales

  • Consulte la página de manual realm(8)`.

3.3. Gestión de los permisos de acceso para los usuarios del dominio

Por defecto, se aplica el control de acceso del lado del dominio, lo que significa que las políticas de inicio de sesión para los usuarios de Active Directory (AD) se definen en el propio dominio AD. Este comportamiento por defecto puede ser anulado para que se utilice el control de acceso del lado del cliente. Con el control de acceso del lado del cliente, el permiso de inicio de sesión se define únicamente mediante políticas locales.

Si un dominio aplica el control de acceso del lado del cliente, puede utilizar la página realmd para configurar reglas básicas de permiso o denegación de acceso para los usuarios de ese dominio.

Nota

Las reglas de acceso permiten o deniegan el acceso a todos los servicios del sistema. Las reglas de acceso más específicas deben establecerse en un recurso específico del sistema o en el dominio.

3.3.1. Habilitar el acceso a los usuarios dentro de un dominio

Esta sección describe cómo habilitar el acceso a los usuarios dentro de un dominio.

Importante

Es más seguro permitir sólo el acceso a usuarios o grupos específicos que negar el acceso a algunos, mientras se permite a todos los demás. Por lo tanto, no se recomienda permitir el acceso a todos por defecto mientras sólo se niega a usuarios específicos con realm permit -x. En su lugar, Red Hat recomienda mantener una política de no acceso por defecto para todos los usuarios y sólo conceder acceso a usuarios seleccionados utilizando realm permit.

Requisitos previos

  • Su sistema RHEL es miembro del dominio de Active Directory.

Procedimiento

  1. Conceder acceso a todos los usuarios:

    # realm permit --all
  2. Conceder acceso a usuarios específicos:

    $ realm permit aduser01@example.com
    $ realm permit 'AD.EXAMPLE.COM\aduser01'

Actualmente, sólo se puede permitir el acceso a usuarios de dominios primarios y no a usuarios de dominios de confianza. Esto se debe a que el inicio de sesión del usuario debe contener el nombre del dominio y SSSD no puede actualmente proporcionar a realmd información sobre los dominios secundarios disponibles.

Pasos de verificación

  1. Utilice SSH para iniciar sesión en el servidor como el usuario aduser01@example.com:

    $ ssh aduser01@example.com@server_name
    [aduser01@example.com@server_name ~]$
  2. Utilice el comando ssh una segunda vez para acceder al mismo servidor, esta vez como el usuario aduser02@example.com:

    $ ssh aduser02@example.com@server_name
    Authentication failed.

Observe cómo se le niega el acceso al sistema a aduser02@example.com. Usted ha concedido el permiso para iniciar sesión en el sistema sólo al usuario aduser01@example.com. Todos los demás usuarios de ese dominio de Active Directory son rechazados debido a la política de inicio de sesión especificada.

Nota

Si establece use_fully_qualified_names como verdadero en el archivo sssd.conf, todas las solicitudes deben utilizar el nombre de dominio completamente calificado. Sin embargo, si establece use_fully_qualified_names como falso, es posible utilizar el nombre completamente calificado en las solicitudes, pero sólo se muestra la versión simplificada en la salida.

Recursos adicionales

  • Consulte la página de manual realm(8)`.

3.3.2. Denegación de acceso a usuarios dentro de un dominio

Esta sección describe cómo denegar el acceso a todos los usuarios de un dominio.

Importante

Es más seguro permitir sólo el acceso a usuarios o grupos específicos que negar el acceso a algunos, mientras se permite a todos los demás. Por lo tanto, no se recomienda permitir el acceso a todos por defecto mientras sólo se niega a usuarios específicos con realm permit -x. En su lugar, Red Hat recomienda mantener una política de no acceso por defecto para todos los usuarios y sólo conceder acceso a usuarios seleccionados utilizando realm permit.

Requisitos previos

  • Su sistema RHEL es miembro del dominio de Active Directory.

Procedimiento

  1. Denegar el acceso a todos los usuarios del dominio:

    # realm deny --all

    Este comando impide que las cuentas de realm se registren en la máquina local. Utilice realm permit para restringir el acceso a cuentas específicas.

  2. Compruebe que el usuario del dominio login-policy está configurado como deny-any-login:

    [root@replica1 ~]# realm list
    example.net
      type: kerberos
      realm-name: EXAMPLE.NET
      domain-name: example.net
      configured: kerberos-member
      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
      login-formats: %U@example.net
      login-policy: deny-any-login
  3. Denegar el acceso a usuarios específicos mediante la opción -x:

    $ realm permit -x 'AD.EXAMPLE.COM\\Naduser02'

Pasos de verificación

  • Utilice SSH para iniciar sesión en el servidor como el usuario aduser01@example.net.

    $ ssh aduser01@example.net@server_name
    Authentication failed.
Nota

Si establece use_fully_qualified_names como verdadero en el archivo sssd.conf, todas las solicitudes deben utilizar el nombre de dominio completamente calificado. Sin embargo, si establece use_fully_qualified_names como falso, es posible utilizar el nombre completamente calificado en las solicitudes, pero sólo se muestra la versión simplificada en la salida.

Recursos adicionales

  • Consulte la página de manual realm(8)`.

3.4. Aplicación del control de acceso a los objetos de la directiva de grupo en RHEL

Un Group Policy Object (GPO) es una colección de configuraciones de control de acceso almacenadas en Microsoft Active Directory (AD) que pueden aplicarse a equipos y usuarios en un entorno AD. Al especificar los GPO en AD, los administradores pueden definir las políticas de inicio de sesión que honran tanto los clientes de Windows como los hosts de Red Hat Enterprise Linux (RHEL) unidos a AD.

Las siguientes secciones describen cómo puede administrar los GPO en su entorno:

3.4.1. Cómo interpreta SSSD las reglas de control de acceso de GPO

Por defecto, SSSD recupera los objetos de política de grupo (GPO) de los controladores de dominio de Active Directory (AD) y los evalúa para determinar si un usuario puede iniciar sesión en un determinado host RHEL unido a AD.

SSSD mapea AD Windows Logon Rights a los nombres de servicio del Módulo de Autenticación Conectable (PAM) para imponer esos permisos en un entorno GNU/Linux.

Como administrador de AD, puede limitar el alcance de las reglas de GPO a usuarios, grupos o hosts específicos mediante una lista en security filter.

3.4.1.1. Limitaciones del filtrado por hosts

Las versiones más antiguas de SSSD no evalúan los hosts en los filtros de seguridad de AD GPO.

  • RHEL 8.3.0 and newer: SSSD admite usuarios, grupos y hosts en los filtros de seguridad.
  • RHEL versions older than 8.3.0: SSSD ignora las entradas de host y sólo admite usuarios y grupos en los filtros de seguridad.
    Para garantizar que SSSD aplique el control de acceso basado en GPO a un host específico, cree una nueva unidad organizativa (OU) en el dominio de AD, mueva el sistema a la nueva OU y, a continuación, vincule el GPO a esta OU.

3.4.1.2. Limitaciones del filtrado por grupos

SSSD actualmente no es compatible con los grupos incorporados de Active Directory, como Administrators con Security Identifier (SID) S-1-5-32-544. Red Hat recomienda no utilizar los grupos integrados de AD en los GPOs de AD dirigidos a los hosts RHEL.

Recursos adicionales

3.4.2. Lista de configuraciones de GPO que admite SSSD

La siguiente tabla muestra las opciones de SSSD que se corresponden con las opciones de GPO de Active Directory tal y como se especifican en Group Policy Management Editor en Windows.

Tabla 3.1. Opciones de control de acceso GPO recuperadas por SSSD

Opción GPOOpción correspondiente sssd.conf

Permitir el inicio de sesión localmente
Denegar el inicio de sesión localmente

ad_gpo_map_interactive

Permitir el inicio de sesión a través de
los Servicios de Escritorio Remoto Denegar el inicio de sesión a través de los Servicios de Escritorio Remoto

ad_gpo_map_remote_interactive

Acceder a este ordenador desde la red
Denegar el acceso a este ordenador desde la red

ad_gpo_map_network

Permitir el inicio de sesión como trabajo por lotes
Denegar el inicio de sesión como trabajo por lotes

ad_gpo_map_batch

Permitir el inicio de sesión como servicio
Denegar el inicio de sesión como servicio

ad_gpo_map_service

  • Para obtener más información sobre estas configuraciones de sssd.conf, como los servicios de Pluggable Authentication Module (PAM) que se asignan a las opciones de GPO, consulte la entrada de la página sssd-ad(5) Manual.

3.4.3. Lista de opciones de SSSD para controlar la aplicación de GPO

3.4.3.1. La opción ad_gpo_access_control

Puede configurar la opción ad_gpo_access_control en el archivo /etc/sssd/sssd.conf para elegir entre tres modos diferentes en los que funciona el control de acceso basado en GPO.

Tabla 3.2. Tabla de valores ad_gpo_access_control

Valor de
ad_gpo_access_control
Comportamiento

enforcing

Las reglas de control de acceso basadas en GPO son evaluadas y aplicadas.
This is the default setting in RHEL 8.

permissive

Las reglas de control de acceso basadas en GPO se evalúan pero se aplican en not; se registra un mensaje syslog cada vez que se deniega el acceso. Esta es la configuración por defecto en RHEL 7.
Este modo es ideal para probar los ajustes de las políticas mientras se permite a los usuarios seguir iniciando sesión.

disabled

Las reglas de control de acceso basadas en GPO no se evalúan ni se aplican.

3.4.3.2. La opción ad_gpo_implicit_deny

La opción ad_gpo_implicit_deny está configurada por defecto en False. En este estado predeterminado, se permite el acceso a los usuarios si no se encuentran los GPO aplicables. Si establece esta opción en True, debe permitir explícitamente el acceso de los usuarios con una regla de GPO.

Puede utilizar esta función para reforzar la seguridad, pero tenga cuidado de no denegar el acceso involuntariamente. Red Hat recomienda probar esta función mientras ad_gpo_access_control está configurado en permissive.

Las dos tablas siguientes ilustran cuándo se permite o rechaza el acceso de un usuario en función de los derechos de inicio de sesión permitidos y denegados definidos en el lado del servidor de AD y el valor de ad_gpo_implicit_deny.

Tabla 3.3. Comportamiento del inicio de sesión con ad_gpo_implicit_deny configurado como False (default)

allow-rulesdeny-rulesresultado

falta

falta

todos los usuarios están autorizados

falta

presente

sólo se permite a los usuarios que no están en deny-rules

presente

falta

sólo se permite a los usuarios en allow-rules

presente

presente

sólo se permite a los usuarios en allow-rules y no en deny-rules

Tabla 3.4. Comportamiento del inicio de sesión con ad_gpo_implicit_deny configurado como True

allow-rulesdeny-rulesresultado

falta

falta

no se permiten usuarios

falta

presente

no se permiten usuarios

presente

falta

sólo se permite a los usuarios en allow-rules

presente

presente

sólo se permite a los usuarios en allow-rules y no en deny-rules

Recursos adicionales

  • Para conocer el procedimiento para cambiar el modo de aplicación de GPO en SSSD, consulte Cambio del modo de control de acceso de GPO.
  • Para más detalles sobre cada uno de los diferentes modos de funcionamiento de GPO, consulte la entrada ad_gpo_access_control en la página del Manual sssd-ad(5).

3.4.4. Cambiar el modo de control de acceso de GPO

Este procedimiento cambia la forma en que se evalúan y aplican las reglas de control de acceso basadas en GPO en un host RHEL unido a un entorno de Active Directory (AD).

En este ejemplo, se cambiará el modo de funcionamiento del GPO de enforcing (el predeterminado) a permissive con fines de prueba.

Importante

Si ve los siguientes errores, los usuarios de Active Directory no pueden iniciar sesión debido a los controles de acceso basados en GPO:

  • En /var/log/secure:

    Oct 31 03:00:13 client1 sshd[124914]: pam_sss(sshd:account): Access denied for user aduser1: 6 (Permission denied)
    Oct 31 03:00:13 client1 sshd[124914]: Failed password for aduser1 from 127.0.0.1 port 60509 ssh2
    Oct 31 03:00:13 client1 sshd[124914]: fatal: Access denied for user aduser1 by PAM account configuration [preauth]
  • En /var/log/sssd/sssd__example.com_.log:

    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_perform_hbac_processing] (0x0040): GPO access check failed: [1432158236](Host Access Denied)
    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_cse_done] (0x0040): HBAC processing failed: [1432158236](Host Access Denied}
    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.

Si este es un comportamiento no deseado, puede establecer temporalmente ad_gpo_access_control en permissive como se describe en este procedimiento mientras soluciona la configuración correcta de GPO en AD.

Requisitos previos

  • Ha unido un host RHEL a un entorno AD utilizando SSSD.
  • La edición del archivo de configuración de /etc/sssd/sssd.conf requiere permisos de root.

Procedimiento

  1. Detenga el servicio SSSD.

    [root@server ~]# systemctl stop sssd
  2. Abra el archivo /etc/sssd/sssd.conf en un editor de texto.
  3. Establezca ad_gpo_access_control como permissive en la sección domain para el dominio AD.

    [domain/example.com]
    ad_gpo_access_control=permissive
    ...
  4. Guarde el archivo /etc/sssd/sssd.conf.
  5. Reinicie el servicio SSSD para cargar los cambios de configuración.

    [root@server ~]# systemctl restart sssd

Recursos adicionales

3.4.5. Creación y configuración de un GPO para un host RHEL en la GUI de AD

El siguiente procedimiento crea un objeto de directiva de grupo (GPO) en la interfaz gráfica de usuario (GUI) de Active Directory (AD) para controlar el acceso al inicio de sesión en un host RHEL.

Requisitos previos

  • Ha unido un host RHEL a un entorno AD utilizando SSSD.
  • Tiene privilegios de administrador de AD para realizar cambios en AD utilizando la GUI.

Procedimiento

  1. Dentro de Active Directory Users and Computers, cree una Unidad Organizativa (OU) para asociarla con el nuevo GPO:

    1. Haga clic con el botón derecho del ratón en el dominio.
    2. Elija New.
    3. Elija Organizational Unit.
  2. Haga clic en el nombre del objeto de equipo que representa el host RHEL (creado cuando se unió a Active Directory) y arrástrelo a la nueva OU. Al tener el host RHEL en su propia OU, el GPO se dirige a este host.
  3. Dentro de Group Policy Management Editor, cree un nuevo GPO para la OU que ha creado:

    1. Ampliar Forest.
    2. Ampliar Domains.
    3. Amplía tu dominio.
    4. Haga clic con el botón derecho en la nueva OU.
    5. Elija Create a GPO in this domain.
  4. Especifique un nombre para el nuevo GPO, como Allow SSH access o Allow Console/GUI access y haga clic en OK.
  5. Edite el nuevo GPO:

    1. Seleccione la OU dentro del editor Group Policy Management.
    2. Haga clic con el botón derecho del ratón y elija Edit.
    3. Seleccione User Rights Assignment.
    4. Seleccione Computer Configuration
    5. Seleccione Policies.
    6. Seleccione Windows Settings.
    7. Seleccione Security Settings.
    8. Seleccione Local Policies.
    9. Seleccione User Rights Assignment.
  6. Asignar permisos de acceso:

    1. Haga doble clic en Allow log on locally para conceder acceso a la consola/GUI local.
    2. Haga doble clic en Allow log on through Remote Desktop Services para conceder el acceso SSH.
  7. Añada el usuario o los usuarios que desea que accedan a cualquiera de estas políticas a las propias políticas:

    1. Haga clic en Add User or Group.
    2. Introduzca el nombre de usuario en el campo en blanco.
    3. Haga clic en OK.

Recursos adicionales

3.4.6. Recursos adicionales