SSD- und LDAP-Authentifizierungscache

Auf unserer Box mit OpenSUSE 12.2 haben wir OpenLDAP und sssdDaemon installiert . Wir verwenden diese beiden Dienste zur Benutzerauthentifizierung. Kürzlich haben wir ein Skript erstellt, das dynamisch neue Webbenutzer für unsere vhosts erstellt. Jetzt haben wir es mit einem Problem zu tun.

Es scheint, dass sssd eine Art Cache verwendet und dabei getent passwdBenutzer zurückgibt, die aus LDAP gelöscht wurden. Manchmal wird der kürzlich erstellte Benutzer nicht sofort zurückgegeben, da dies im Skript weiter erforderlich ist (zum Festlegen von Berechtigungen mit setfaclund chown).

LDAP neu starten sssdoder nscdnicht helfen, Cache auch nicht leeren sss_cache -U. Wir haben versucht, den Cache in der Konfiguration von zu verkleinern, sssdaber es scheint, dass dies nichts beeinflusst.

Wir müssen den Cache nach dem Hinzufügen eines neuen Benutzers zu LDAP explizit aktualisieren oder den Cache überhaupt deaktivieren.

Hat jemand ein ähnliches Problem erlebt?

Von der Manpage (sssd.conf):

NSS configuration options
       These options can be used to configure the Name Service Switch (NSS)
       service.

       enum_cache_timeout (integer)
           How many seconds should nss_sss cache enumerations (requests for
           info about all users)
       Default: 120

Ich würde so etwas einfügen wie:

[nss]
enum_cache_timeout 10

(Sekunden anpassen, wie es passt)

Ich habe ähnliche Probleme erlebt

Ich habe das bemerkt getent passwd | grep <username>und getent passwd <username>werde nicht die gleichen Ergebnisse zurückgeben.

Mit strace habe ich festgestellt, dass getent passwd <username>Daten eingecheckt werden"/var/lib/sss/mc/passwd"

Dabei getent passwd | grep <username>wird eine Verbindung hergestellt /var/lib/sss/pipes/nssund die Daten von dort abgerufen .

Das verwirrt mich wirklich, da beide Ansätze unterschiedliche Caches zu treffen scheinen. Diese Caches scheinen beim Ausführen aktualisiert zu werden sudo su - <username>, scheinen aber ansonsten stundenlang gültig zu sein.

Das Ergebnis in der Praxis ist, dass z. B. der SSH-Zugriff für einen Benutzer einige Minuten nach dem Entfernen aus dem LDAP nicht funktioniert, aber getent passwd ihn stundenlang anzeigt, sodass ich nur schwer überprüfen kann, ob dieser Benutzer angemeldet ist Tatsache entfernt oder nicht (ohne einige Caches ständig manuell zu löschen)

Versuchen sss_cache -E

oder versuchen Sie, sssd zu stoppen, die Dateien in / var / lib / sss / db / * zu entfernen und sssd neu zu starten

• Sie können das Caching mit sssd nicht vollständig deaktivieren.

• Sie können sss als Authentifizierungsanbieter vollständig deaktivieren und LDAP direkt abfragen, wenn Sie dies wünschen.

/etc/nsswitch.confÄndern Sie beispielsweise in Zeilen wie folgt:

passwd:     files sss

zu

passwd:     files ldap

• Sie können die Bereinigung des Caches erzwingen, indem Sie ihn entfernen /var/lib/sss/db/*

Sie können versuchen, die Caching-Anmeldeinformationen zu deaktivieren, indem Sie der Anweisung /etc/sssd/sssd.conf eine Anweisung hinzufügen:

[domain/default]
cache_credentials = False

Sie können dann mit dem Konsolenbefehl überprüfen, ob sssd den Cache für Anmeldeinformationen verwendet:

# authconfig --test|grep credential
credential caching in SSSD is disabled

Beachten Sie, dass cache_credentials = True in Fedora 30/31 einen Fehler verursacht, der eine Anmeldung mit LDAP-Benutzern unmöglich macht. Ich habe keinen dokumentierten Fehler gefunden, also schreibe ich ihn hier.