Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

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
Copiar enlace

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
Copiar enlace

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.

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
Copiar enlace

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
Copiar enlace

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.

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.
      Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

Recursos adicionales

1.4. Conexión directa a AD
Copiar enlace

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
Copiar enlace

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.

    Expand
    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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

Recursos adicionales

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

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.

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
Copiar enlace

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.

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.

    Expand
    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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

  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/*
      Copy to Clipboard Toggle word wrap

    4. Reinicie el SSSD: 

      systemctl restart sssd
      Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

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).

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.

    Expand
    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
    Copy to Clipboard Toggle word wrap

  2. Utilice realmd para unirse al primer dominio AD, addomain1.com. 

    # realm join ADDOMAIN1.COM
    Copy to Clipboard Toggle word wrap

  3. Renombrar el keytab del sistema con un nombre único. 

    # mv /etc/krb5.keytab /etc/dominio1.com.krb5.keytab
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

  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

...
      Copy to Clipboard Toggle word wrap

  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]
    Copy to Clipboard Toggle word wrap
    • 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
    Copy to Clipboard Toggle word wrap

  8. Reinicie y habilite el servicio SSSD. 

    # systemctl restart sssd
# systemctl enable sssd
    Copy to Clipboard Toggle word wrap

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)
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap 
    # ssh administrator@addomain2.com@localhost
administrator@addomain2.com@localhost's password:
Creating directory '/home/addomain2.com/administrator'.

$ pwd
/home/addomain2.com/administrator
    Copy to Clipboard Toggle word wrap

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.

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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

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

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
Copiar enlace

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.

Expand
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).

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
Copiar enlace

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
Copiar enlace

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.

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.
      Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

Recursos adicionales

2.4. Unir un sistema RHEL a un dominio AD
Copiar enlace

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
    Copy to Clipboard Toggle word wrap

  2. Instale los siguientes paquetes: 

    # yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients \ samba-winbind samba-common-tools samba-winbind-krb5-locator
    Copy to Clipboard Toggle word wrap

  3. Para compartir directorios o impresoras en el miembro del dominio, instale el paquete samba: 

    # yum install samba
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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
    }
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

  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
      Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

  5. Muestra los dominios disponibles: 

    # wbinfo --all-domains
BUILTIN
SAMBA-SERVER
AD
    Copy to Clipboard Toggle word wrap

Recursos adicionales

2.5. comandos del reino
Copiar enlace

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.

Expand
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
Copiar enlace

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.

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
    Copy to Clipboard Toggle word wrap

  2. Reinicie el SSSD: 

    # systemctl restart sssd
    Copy to Clipboard Toggle word wrap
  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
Copiar enlace

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
    Copy to Clipboard Toggle word wrap
    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]'
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap

Recursos adicionales

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

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

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
Copiar enlace

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
    Copy to Clipboard Toggle word wrap

  2. Conceder acceso a usuarios específicos: 

    $ realm permit aduser01@example.com
$ realm permit 'AD.EXAMPLE.COM\aduser01'
    Copy to Clipboard Toggle word wrap

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 ~]$
    Copy to Clipboard Toggle word wrap

  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.
    Copy to Clipboard Toggle word wrap

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
Copiar enlace

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
    Copy to Clipboard Toggle word wrap

    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
    Copy to Clipboard Toggle word wrap

  3. Denegar el acceso a usuarios específicos mediante la opción -x: 

    $ realm permit -x 'AD.EXAMPLE.COM\\Naduser02'
    Copy to Clipboard Toggle word wrap

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.
    Copy to Clipboard Toggle word wrap
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)`.

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
Copiar enlace

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
Copiar enlace

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
Copiar enlace

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
Copiar enlace

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.

Expand
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
Copiar enlace

3.4.3.1. La opción ad_gpo_access_control
Copiar enlace

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.

Expand
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
Copiar enlace

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.

Expand
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

Expand
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
Copiar enlace

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]
    Copy to Clipboard Toggle word wrap

  • 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.
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
  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
...
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

Recursos adicionales

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
Copiar enlace

Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

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

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat