Red Hat Training

A Red Hat training course is available for RHEL 8

5.5.11. Gestión de la identidad

La caché de credenciales KCM no es adecuada para un gran número de credenciales en una sola caché de credenciales

El gestor de credenciales de Kerberos (KCM) puede manejar tamaños de caché de hasta 64 kB. Si contiene demasiadas credenciales, las operaciones de Kerberos, como kinit, fallan debido a un límite codificado en el búfer utilizado para transferir datos entre el componente sssd-kcm y la base de datos subyacente.

Para solucionar este problema, añada la opción ccache_storage = memory en la sección kcm del archivo /etc/sssd/sssd.conf. Esto instruye al respondedor de kcm para que sólo almacene los cachés de credenciales en memoria, no de forma persistente. Si haces esto, reiniciar el sistema o sssd-kcm borra los cachés de credenciales.

(BZ#1448094)

Cambiar /etc/nsswitch.conf requiere un reinicio manual del sistema

Cualquier cambio en el archivo /etc/nsswitch . conf, por ejemplo la ejecución del comando authselect select profile_id, requiere un reinicio del sistema para que todos los procesos relevantes utilicen la versión actualizada del archivo /etc/nsswitch.conf. Si no es posible reiniciar el sistema, reinicie el servicio que une su sistema a Active Directory, que es el demonio de servicios de seguridad del sistema (SSSD) o winbind.

(BZ#1657295)

Los valores de tiempo de espera conflictivos impiden que SSSD se conecte a los servidores

Algunos de los valores de tiempo de espera por defecto relacionados con las operaciones de conmutación por error utilizadas por el demonio de servicios de seguridad del sistema (SSSD) son conflictivos. En consecuencia, el valor del tiempo de espera reservado para que SSSD hable con un solo servidor impide que SSSD pruebe con otros servidores antes de que la operación de conexión se agote por completo. Para solucionar el problema, establezca el valor del parámetro ldap_opt_timeout timeout más alto que el valor del parámetro dns_resolver_timeout, y establezca el valor del parámetro dns_resolver_timeout más alto que el valor del parámetro dns_resolver_op_timeout.

(BZ#1382750)

SSSD sólo puede buscar certificados únicos en las anulaciones de ID

Cuando varias anulaciones de ID contienen el mismo certificado, el demonio de servicios de seguridad del sistema (SSSD) no puede resolver las consultas de los usuarios que coinciden con el certificado. Un intento de buscar estos usuarios no devuelve ningún usuario. Tenga en cuenta que la búsqueda de usuarios mediante su nombre de usuario o UID funciona como se espera.

(BZ#1446101)

SSSD no maneja correctamente varias reglas de coincidencia de certificados con la misma prioridad

Si un certificado determinado coincide con varias reglas de coincidencia de certificados con la misma prioridad, el demonio de servicios de seguridad del sistema (SSSD) sólo utiliza una de las reglas. Como solución, utilice una única regla de coincidencia de certificados cuyo filtro LDAP esté formado por los filtros de las reglas individuales concatenados con el operador | (o). Para ver ejemplos de reglas de coincidencia de certificados, consulte la página de manual de sss-certamp(5).

(BZ#1447945)

SSSD devuelve la pertenencia a un grupo LDAP incorrecto para los usuarios locales

Si el demonio de servicios de seguridad del sistema (SSSD) sirve a los usuarios desde los archivos locales, el proveedor de archivos no incluye la pertenencia a grupos de otros dominios. Como consecuencia, si un usuario local es miembro de un grupo LDAP, el comando id local_user no devuelve la pertenencia al grupo LDAP del usuario. Para solucionar el problema, invierta el orden de las bases de datos en las que el sistema busca la pertenencia a grupos de los usuarios en el archivo /etc/nsswitch.conf, sustituyendo sss files por files sss, o desactive el dominio implícito de files añadiendo

enable_files_domain=False

a la sección [sssd] en el archivo /etc/sssd/sssd.conf.

Como resultado, id local_user devuelve la pertenencia correcta al grupo LDAP para los usuarios locales.

(BZ#1652562)

Las reglas sudo podrían no funcionar con id_provider=ad si las reglas sudo hacen referencia a los nombres de los grupos

System Security Services Daemon (SSSD) no resuelve los nombres de grupo de Active Directory durante la operación initgroups debido a una optimización de la comunicación entre AD y SSSD mediante el uso de una caché. La entrada de la caché sólo contiene un identificador de seguridad (SID) y no los nombres de los grupos hasta que se solicita el grupo por nombre o por ID. Por lo tanto, las reglas de sudo no coinciden con el grupo de AD a menos que los grupos estén completamente resueltos antes de ejecutar sudo.

Para solucionar este problema, es necesario desactivar la optimización: Abra el archivo /etc/sssd/sssd.conf y añada el parámetro ldap_use_tokengroups = false en la sección [dominio/ejemplo.com ].

(BZ#1659457)

La configuración PAM por defecto para systemd-user ha cambiado en RHEL 8, lo que puede influir en el comportamiento de SSSD

La pila de módulos de autenticación enchufables (PAM) ha cambiado en Red Hat Enterprise Linux 8. Por ejemplo, la sesión de usuario systemd ahora inicia una conversación PAM usando el servicio systemd-user PAM. Este servicio ahora incluye recursivamente el servicio PAM system-auth, que puede incluir la interfaz pam_sss.so. Esto significa que el control de acceso SSSD siempre es llamado.

Tenga en cuenta este cambio cuando diseñe las reglas de control de acceso para los sistemas RHEL 8. Por ejemplo, puede añadir el servicio systemd-user a la lista de servicios permitidos.

Tenga en cuenta que para algunos mecanismos de control de acceso, como IPA HBAC o AD GPOs, el servicio systemd-user se ha añadido a la lista de servicios permitidos por defecto y no necesita realizar ninguna acción.

(BZ#1669407)

El servidor IdM no funciona en FIPS

Debido a una implementación incompleta del conector SSL para Tomcat, un servidor de gestión de identidades (IdM) con un servidor de certificados instalado no funciona en máquinas con el modo FIPS activado.

(BZ#1673296)

Samba deniega el acceso cuando se utiliza el complemento de asignación de ID sss

Para utilizar Samba como servidor de archivos en un host RHEL unido a un dominio de Active Directory (AD), el servicio Winbind de Samba debe estar ejecutándose incluso si se utiliza SSSD para gestionar usuarios y grupos desde AD. Si se une al dominio utilizando el comando realm join --client-software=sssd o sin especificar el parámetro --client-software en este comando, realm crea sólo el archivo /etc/sssd/sssd.conf. Cuando se ejecuta Samba en el miembro del dominio con esta configuración y se añade una configuración que utiliza el back end de mapeo de ID sss al archivo /etc/samba/smb.conf para compartir directorios, los cambios en el back end de mapeo de ID pueden causar errores. En consecuencia, Samba niega el acceso a los archivos en ciertos casos, incluso si el usuario o grupo existe y es conocido por SSSD.

Si planea actualizar desde una versión anterior de RHEL y el parámetro ldap_id_mapping en el archivo /etc/sssd/sssd.conf está establecido en True, que es el valor predeterminado, no hay ninguna solución disponible. En este caso, no actualice el host a RHEL 8 hasta que se haya solucionado el problema.

Posibles soluciones en otros escenarios:

  • Para las nuevas instalaciones, únase al dominio utilizando el comando realm join --client-software=winbind. Esto configura el sistema para utilizar Winbind en lugar de SSSD para todas las búsquedas de usuarios y grupos. En este caso, Samba utiliza el complemento de mapeo de ID rid o ad en /etc/samba/smb.conf dependiendo de si se establece la opción --automatic-id-mapping en yes (por defecto) o no. Si planea usar SSSD en el futuro o en otros sistemas, usar --automatic-id-mapping=no permite una migración más fácil pero requiere que almacene UIDs y GIDs POSIX en AD para todos los usuarios y grupos.
  • Cuando se actualiza desde una versión anterior de RHEL, y si el parámetro ldap_id_mapping en el archivo /etc/sssd/sssd. conf se establece en False y el sistema utiliza los atributos uidNumber y gidNumber de AD para la asignación de ID:

    1. Cambie la entrada idmap config <domain> : backend = sss en el archivo /etc/samba/smb.conf por idmap config <domain> : backend = ad
    2. Utilice el comando systemctl status winbind para reiniciar el Winbind.

(BZ#1657665)

El servicio nuxwdog falla en entornos HSM y requiere instalar el paquete keyutils en entornos no HSM

El servicio de vigilancia nuxwdog se ha integrado en Certificate System. En consecuencia, nuxwdog ya no se proporciona como un paquete independiente. Para utilizar el servicio de vigilancia, instale el paquete pki-server.

Tenga en cuenta que el servicio nuxwdog tiene los siguientes problemas conocidos:

  • El servicio nuxwdog no funciona si se utiliza un módulo de almacenamiento de hardware (HSM). Para este problema, no hay ninguna solución disponible.
  • En un entorno no-HSM, Red Hat Enterprise Linux 8.0 no instala automáticamente el paquete keyutils como una dependencia. Para instalar el paquete manualmente, utilice el comando dnf install keyutils.

(BZ#1652269)

La adición de anulaciones de ID de usuarios de AD sólo funciona en la CLI de IdM

Actualmente, la adición de anulaciones de ID de usuarios de Active Directory (AD) a los grupos de Gestión de identidades (IdM) con el fin de conceder acceso a las funciones de gestión falla en la interfaz web de IdM. Para solucionar el problema, utilice la interfaz de línea de comandos (CLI) de IdM.

Tenga en cuenta que si instaló el paquete ipa-idoverride-memberof-plugin en el servidor IdM después de realizar previamente ciertas operaciones utilizando la utilidad ipa, Red Hat recomienda limpiar la caché de la utilidad ipa para forzarla a refrescar su visión sobre los metadatos del servidor IdM.

Para ello, elimine el contenido del directorio ~/.cache/ipa para el usuario bajo el cual se ejecuta la utilidad ipa. Por ejemplo, para root:

# rm -r /root/.cache/ipa

(BZ#1651577)

No se muestra la información sobre los registros DNS necesarios al activar la compatibilidad con la confianza de AD en IdM

Cuando se habilita el soporte para la confianza de Active Directory (AD) en la instalación de Red Hat Enterprise Linux Identity Management (IdM) con gestión externa de DNS, no se muestra información sobre los registros DNS requeridos. La confianza del bosque en AD no tiene éxito hasta que se añaden los registros DNS requeridos. Para solucionar este problema, ejecute el comando 'ipa dns-update-system-records --dry-run' para obtener una lista de todos los registros DNS requeridos por IdM. Cuando el DNS externo para el dominio de IdM define los registros DNS necesarios, es posible establecer la confianza del bosque en AD.

(BZ#1665051)