Red Hat Enterprise Linux 8

Integración de los sistemas RHEL directamente

con Windows Active Directory

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

Active Directory

directamente con Windows Active Directory

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

Directory

Enter your first name here. Enter your surname here.

Enter your organisation's name here. Enter your organisational division here.

Enter your email address here.

Copyright © 2021 | You need to change the HOLDER entity in the

en-US/Integrating_RHEL_systems_directly_with_Windows_Active_Directory.ent file |.

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons

Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is

available at

http://creativecommons.org/licenses/by-sa/3.0/

. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must

provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,

Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,

Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States

and other countries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States

and/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and

other countries.

Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the

official Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks

or trademarks/service marks of the OpenStack Foundation, in the United States and other

countries and are used with the OpenStack Foundation's permission. We are not affiliated with,

endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Resumen

Esta colección de documentación proporciona instrucciones sobre cómo integrar los sistemas

RHEL directamente con Windows Active Directory utilizando SSSD.

. . . . . . . . . . . . . . . . . . . .

Table of Contents

HACER QUE EL CÓDIGO ABIERTO SEA MÁS INCLUSIVO

PROPORCIONAR COMENTARIOS SOBRE LA DOCUMENTACIÓN DE RED HAT

CAPÍTULO 1. CONEXIÓN DE SISTEMAS RHEL DIRECTAMENTE A AD MEDIANTE SSSD 1.1. VISIÓN GENERAL DE LA INTEGRACIÓN DIRECTA MEDIANTE SSSD

1.2. PLATAFORMAS WINDOWS COMPATIBLES CON LA INTEGRACIÓN DIRECTA

1.3. GARANTIZAR LA COMPATIBILIDAD CON LOS TIPOS DE CIFRADO COMUNES EN AD Y RHEL 1.4. CONEXIÓN DIRECTA A AD

1.4.1. Descubrir y unirse a un dominio AD utilizando SSSD

1.4.2. Opciones para la integración con AD: uso de mapeo de ID o atributos POSIX 1.4.2.1. Generar automáticamente nuevos UID y GID para los usuarios de AD 1.4.2.2. Utilizar los atributos POSIX definidos en AD

1.4.3. Conexión a AD mediante atributos POSIX definidos en Active Directory 1.4.4. Conexión a múltiples dominios en diferentes bosques de AD con SSSD

1.5. CÓMO MANEJA EL PROVEEDOR DE AD LAS ACTUALIZACIONES DINÁMICAS DE DNS 1.6. MODIFICACIÓN DE LA CONFIGURACIÓN DEL DNS DINÁMICO PARA EL PROVEEDOR DE AD 1.7. CÓMO MANEJA EL PROVEEDOR DE AD LOS DOMINIOS DE CONFIANZA

1.8. COMANDOS DEL REINO

CAPÍTULO 2. CONEXIÓN DE LOS SISTEMAS RHEL DIRECTAMENTE A AD MEDIANTE SAMBA WINBIND 2.1. VISIÓN GENERAL DE LA INTEGRACIÓN DIRECTA MEDIANTE SAMBA WINBIND

2.2. PLATAFORMAS WINDOWS COMPATIBLES CON LA INTEGRACIÓN DIRECTA

2.3. GARANTIZAR LA COMPATIBILIDAD CON LOS TIPOS DE CIFRADO COMUNES EN AD Y RHEL 2.4. UNIR UN SISTEMA RHEL A UN DOMINIO AD

2.5. COMANDOS DEL REINO

CAPÍTULO 3. GESTIÓN DE LAS CONEXIONES DIRECTAS CON AD

3.1. MODIFICACIÓN DEL INTERVALO DE RENOVACIÓN DEL KEYTAB DEL HOST KERBEROS POR DEFECTO 3.2. ELIMINACIÓN DE UN SISTEMA RHEL DE UN DOMINIO AD

3.3. GESTIÓN DE LOS PERMISOS DE ACCESO PARA LOS USUARIOS DEL DOMINIO 3.3.1. Habilitar el acceso a los usuarios dentro de un dominio

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

3.4. APLICACIÓN DEL CONTROL DE ACCESO A LOS OBJETOS DE LA DIRECTIVA DE GRUPO EN RHEL 3.4.1. Cómo interpreta SSSD las reglas de control de acceso de GPO

3.4.1.1. Limitaciones del filtrado por hosts 3.4.1.2. Limitaciones del filtrado por grupos

3.4.2. Lista de configuraciones de GPO que admite SSSD

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

3.4.3.2. La opción ad_gpo_implicit_deny

3.4.4. Cambiar el modo de control de acceso de GPO

3.4.5. Creación y configuración de un GPO para un host RHEL en la GUI de AD 3.4.6. Recursos adicionales 3 4 5 5 6 6 7 8 9 10 10 10 12 16 16 17 17 19 19 20 20 21 23 25 25 25 26 27 28 29 29 30 30 30 31 31 31 32 34 35

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.

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.

Visión general de la integración directa mediante SSSD Plataformas Windows compatibles con la integración directa

Garantizar la compatibilidad con los tipos de cifrado comunes en AD y RHEL Conexión directa a AD

Cómo maneja el proveedor de AD las actualizaciones dinámicas de DNS Modificación de la configuración del DNS dinámico para el proveedor de AD Cómo maneja el proveedor de AD los dominios de confianza

comandos del reino

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 sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac +rc4

Recursos adicionales

Para obtener más información sobre cómo trabajar con las políticas criptográficas de RHEL, consulte Uso de políticas criptográficas en todo el sistema en la guía de endurecimiento de la seguridad.

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.

Opciones para la integración con AD: uso de mapeo de ID o atributos POSIX Conexión a AD mediante atributos POSIX definidos en Active Directory Conexión a múltiples dominios en diferentes bosques de AD con SSSD

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

Servicio Puerto Protocolo Notas

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:

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 [email protected]

[email protected]:*: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.

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

Servicio Puerto Protocolo Notas

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: a. Abra el archivo /etc/sssd/sssd.conf.

b. En la sección del dominio AD, añada la configuración ldap_id_mapping = false. c. Eliminar las cachés de SSSD:

d. 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 [email protected]

[email protected]:*: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

Servicio Puerto Protocolo Notas

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

Servicio Puerto Protocolo Notas

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]

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 [email protected] 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 [email protected]

uid=1240800500([email protected]) gid=1240800513(domain [email protected]) groups=1240800513(domain

[email protected]),1240800512(domain [email protected]),1240800518(schema

[email protected]),1240800520(group policy creator

[email protected]),1240800572(denied rodc password replication [email protected]),1240800519(enterprise [email protected]) # id [email protected] uid=1013800500([email protected]) gid=1013800500([email protected]) groups=1013800500([email protected]),1013800513(domain [email protected])

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 [email protected]@localhost [email protected]@localhost's password: Creating directory '/home/addomain1.com/administrator'. $ pwd

/home/addomain1.com/administrator

# ssh [email protected]@localhost [email protected]@localhost's password: Creating directory '/home/addomain2.com/administrator'. $ pwd

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

Comando Descripció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.

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.

Visión general de la integración directa mediante Samba Winbind Plataformas Windows compatibles con la integración directa

Garantizar la compatibilidad con los tipos de cifrado comunes en AD y RHEL Unir un sistema RHEL a un dominio AD

comandos del reino

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.

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 sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac +rc4

Recursos adicionales

Para obtener más información sobre cómo trabajar con las políticas criptográficas de RHEL, consulte Uso de políticas criptográficas en todo el sistema en la guía de endurecimiento de la seguridad.

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 winbind-clients \ samba-winbind samba-common-tools samba-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

# 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:

a. En el miembro del dominio AD, obtenga un ticket para la entidad de crédito

[email protected]:

# kinit [email protected]

b. Muestra el ticket de Kerberos en caché: # klist

Ticket cache: KCM:0

Default principal: [email protected] Valid starting Expires Service principal 01.11.2018 10:00:00 01.11.2018 20:00:00 krbtgt/[email protected] renew until 08.11.2018 05:00:00

5. Muestra los dominios disponibles: # wbinfo --all-domains

BUILTIN

SAMBA-SERVER AD

Recursos adicionales

Si no desea utilizar los cifrados RC4 obsoletos, puede habilitar el tipo de cifrado AES en AD. Consulte Activación del tipo de cifrado AES en Active Directory mediante un GPO en la documentación de Deploying different types of servers.

Para más detalles sobre la utilidad realm, consulte la página de manual realm(8).

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

Comando Descripció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.

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 [email protected] $ 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 [email protected]: $ ssh [email protected]@server_name

[[email protected]@server_name ~]$

2. Utilice el comando ssh una segunda vez para acceder al mismo servidor, esta vez como el usuario [email protected]:

$ ssh [email protected]@server_name Authentication failed.

permiso para iniciar sesión en el sistema sólo al usuario [email protected]. 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: %[email protected]

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 [email protected]. $ ssh [email protected]@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:

Sección 3.4.1, “Cómo interpreta SSSD las reglas de control de acceso de GPO” Sección 3.4.2, “Lista de configuraciones de GPO que admite SSSD”

Sección 3.4.3, “Lista de opciones de SSSD para controlar la aplicación de GPO” Sección 3.4.4, “Cambiar el modo de control de acceso de GPO”

Sección 3.4.5, “Creación y configuración de un GPO para un host RHEL en la GUI de AD”

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

Para obtener una lista de las opciones de GPO de Windows y sus correspondientes opciones de SSSD, consulte Lista de opciones de GPO que admite SSSD .

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 GPO Opció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

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

Opción GPO Opción correspondiente sssd.conf

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-rules deny-rules resultado

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-rules deny-rules resultado

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

Para ver la lista de los diferentes modos de control de acceso a GPO, consulte Lista de opciones de SSSD para controlar la aplicación de GPO.

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:

a. Haga clic con el botón derecho del ratón en el dominio. b. Elija New.

c. 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: a. Ampliar Forest.

b. Ampliar Domains. c. Amplía tu dominio.

d. Haga clic con el botón derecho en la nueva OU. e. 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:

a. Seleccione la OU dentro del editor Group Policy Management. b. Haga clic con el botón derecho del ratón y elija Edit.

c. Seleccione User Rights Assignment. d. Seleccione Computer Configuration e. Seleccione Policies.

f. Seleccione Windows Settings. g. Seleccione Security Settings. h. Seleccione Local Policies.

i. Seleccione User Rights Assignment. 6. Asignar permisos de acceso:

a. Haga doble clic en Allow log on locally para conceder acceso a la consola/GUI local. b. 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:

a. Haga clic en Add User or Group.

b. Introduzca el nombre de usuario en el campo en blanco. c. Haga clic en OK.

Recursos adicionales

Para obtener más detalles sobre los objetos de directiva de grupo, consulte Objetos de directiva de grupo en la documentación de Microsoft.

3.4.6. Recursos adicionales

Para obtener más información sobre cómo unir un host RHEL a un entorno de Active Directory, consulte Conexión de sistemas RHEL directamente a AD mediante SSSD