☰

El usuario LDAP no existe cuando se ejecuta 'su'

tag-icon • tag-icon rhel ldap sssd
El usuario LDAP no existe cuando se ejecuta 'su'

Estoy intentando configurar la autenticación LDAP de acuerdo con las instrucciones del libro RHCSA/RHCE de Sander Van Vugt para RHEL7. En el capítulo 6 explica que cuando se usa authconfig-tuila FORCELEGACYopción se establece yesen /etc/sysconfig/authconfig. Se supone que esto debe configurarse nslcden lugar de sssd.

No veo que esto suceda. Quizás era así en 7.0 o incluso 7.1, pero en 7.3 la opción está configurada nodespués de usar authconfig-tui.

Si dejo de lado la confusión nslcdvs sssde intento completar el ejercicio que lleva a ejecutar su - larala autenticación a través de LDAP para dicho usuario, simplemente obtengo:

su: user lara does not exist

Verifiqué que el servidor FreeIPA está respondiendo consultas usando ldapsearchy, al hacerlo, confirmé que el usuario está en LDAP. Sin embargo, me parece que eso suno es autenticar contra LDAP, sino /etc/passwd.

Mi PAM system-authconfiguración incluye las sssdentradas que parecen necesarias:

auth        sufficient    pam_sss.so forward_pass
account     [default=bad success=ok user_unknown=ignore] pam.sss.so
password    sufficient    pam_sss.so use_authtok
session     optional      pam_sss.so

Mi /etc/nsswitch.confarchivo contiene:

passwd:    files sss
shadow:    files sss
group:     files sss

El sssdservicio está activo.

No hay entradas de registro en /var/log/*o /var/log/sssd/*. De hecho, ninguno de los sssdregistros contiene nada.

EDITAR

Después de leer un poco, todavía no estoy más cerca de encontrar una solución a esto; sin embargo, tengo más información.

Puedo autenticarme como usuario lara si entro sshen el servidor LDAP. Entonces sé que LDAP realmente está funcionando.

También miré la PAMconfiguración de su. Esto está ingresando el system-autharchivo:

auth        substack        system-auth
account     include         system-auth
password    include         system-auth
session     include         system-auth

por lo que debería hacer uso del pam_sss.somódulo implícitamente.

Aunque todavía no puedo solucionarlo.

EDITAR 2

Al poder iniciar sesión en el servidor IPA localmente o mediante SSH con el usuario lara, decidí comparar los archivos pam con los del cliente. La única diferencia que pude determinar es que el cliente figuraba broken_shadowen el pam_unix.soasiento de cuenta. Lo eliminé e incluso reinicié pero no solucionó nada.

¿Cómo lo desactivo broken_shadow? No puedo encontrar nada al respecto.

Respuesta1

Puede que esto no esté relacionado, pero estoy siguiendo el mismo curso (con un servidor cliente de mi creación) y logré solucionarlo haciendo lo siguiente:

  1. Verificar que todo coincidiera con lo que había configurado en authconfig-tui en /etc/sssd/sssd.conf
  2. Establecer los permisos en /etc/sssd/sssd.conf en 0600 (funcionó inmediatamente después de eso). No estoy seguro de por qué esto marcó la diferencia, dado que solo otorga R/W al usuario, pero lo encontré en una guía de Oracle. para la configuración del cliente RHEL7 SSSD:https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-sssd-ldap.html

EDITAR: Posible explicación:https://pagure.io/SSSD/sssd/issue/1413

información relacionada