☰

LDAP-Benutzer existiert nicht, wenn „su“ ausgeführt wird

tag-icon • tag-icon rhel ldap sssd
LDAP-Benutzer existiert nicht, wenn „su“ ausgeführt wird

Ich versuche, die LDAP-Authentifizierung gemäß den Anweisungen in Sander Van Vugts RHCSA/RHCE-Buch für RHEL7 einzurichten. In Kapitel 6 erklärt er, dass bei Verwendung authconfig-tuidie FORCELEGACYOption auf yesin gesetzt ist /etc/sysconfig/authconfig. Dies soll konfigurieren nslcdstatt sssd.

Ich sehe nicht, dass das passiert. Vielleicht war es in 7.0 oder sogar 7.1 so, aber in 7.3 ist die Option auf „ noafter using“ eingestellt authconfig-tui.

nslcdWenn ich die „vs“ -Verwirrung beiseite lasse sssdund versuche, die Übung abzuschließen, die dazu führt, dass ich su - laraden besagten Benutzer per LDAP authentifiziere, erhalte ich lediglich:

su: user lara does not exist

Ich habe überprüft, dass der FreeIPA-Server Anfragen mit beantwortet ldapsearchund dabei bestätigt, dass der Benutzer in LDAP ist. Mir scheint jedoch, dass dies sukeine Authentifizierung gegenüber LDAP ist, sondern /etc/passwd.

Meine PAM system-authKonfiguration beinhaltet die sssdEinträge, die notwendig erscheinen:

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

Meine /etc/nsswitch.confDatei enthält:

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

Der sssdDienst ist aktiv.

Es gibt keine Protokolleinträge in /var/log/*oder /var/log/sssd/*. Tatsächlich sssdenthält keines der Protokolle irgendetwas.

BEARBEITEN

Ich bin der Lösung dieses Problems nach einigem Lesen immer noch nicht näher gekommen, verfüge jedoch über weitere Informationen.

Ich kann mich als Benutzerin Lara authentifizieren, wenn ich sshmich beim LDAP-Server anmelde. Ich weiß also, dass LDAP tatsächlich funktioniert.

Ich habe mir auch die PAMKonfiguration für angesehen su. Hier wird die Datei eingefügt system-auth:

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

daher sollte das pam_sss.soModul implizit verwendet werden.

Ich kann es aber immer noch nicht klären.

BEARBEITEN 2

Da ich mich entweder lokal oder per SSH mit dem Benutzer lara beim IPA-Server anmelden konnte, beschloss ich, die PAM-Dateien darauf mit denen auf dem Client zu vergleichen. Der einzige Unterschied, den ich feststellen konnte, war, dass der Client broken_shadowden pam_unix.soKontoeintrag enthielt. Ich habe ihn entfernt und sogar neu gestartet, aber das hat nichts behoben.

Wie deaktiviere ich broken_shadow? Ich kann nichts darüber finden.

Antwort1

Dies hat möglicherweise nichts damit zu tun, aber ich verfolge den gleichen Weg (mit einem Client-Server meiner Wahl) und konnte das Problem folgendermaßen beheben:

  1. Überprüfen, ob alles mit meinen Einstellungen in authconfig-tui in /etc/sssd/sssd.conf übereinstimmt
  2. Festlegen der Berechtigungen für /etc/sssd/sssd.conf auf 0600 (danach hat es sofort funktioniert) – ich bin nicht sicher, warum das einen Unterschied macht, da dem Benutzer dadurch nur R/W gewährt wird, aber ich habe es in einem Oracle-Handbuch zur RHEL7 SSSD-Clientkonfiguration gefunden:https://docs.oracle.com/cd/E52668_01/E54669/html/ol7-sssd-ldap.html

EDIT: Mögliche Erklärung:https://pagure.io/SSSD/sssd/issue/1413

verwandte Informationen