Nachverfolgen, welche Identitätsquelle für einen Benutzer antwortet: getent, id, nsswitch.conf und sss_cache

Ziel

Feststellen, welcher Namensdienst auf einem Linux-Host für einen bestimmten Benutzernamen oder eine bestimmte Gruppe antwortet, und einen veralteten SSSD-Cache-Eintrag löschen, wenn sowohl lokale Dateien als auch ein Verzeichnisdienst (LDAP/SSSD/AD) im Spiel sind.

Voraussetzungen

Lesezugriff auf /etc/nsswitch.conf; sss_cache ist vorhanden, wenn der Host SSSD verwendet (wird zusammen mit sssd-common/sssd-tools installiert, wie bei realmd/SSSD-AD-Beitritten üblich).

Schritte

1. Abfragereihenfolge für Konten lesen: Die Zeilen passwd:, group: und shadow: in /etc/nsswitch.conf führen die zu befragenden Quellen in der Reihenfolge ihrer Abfrage auf. Das Paket libnss-sss unter Debian/Ubuntu setzt sss hinter files; die authselect-Profile der RHEL-Familie haben sss je nach Release vor oder nach files gesetzt. Deshalb die tatsächliche Zeile lesen, statt von einer Annahme auszugehen. Die Man-Page dokumentiert dieses Format der Quellenliste pro Datenbank.
2. Einen bestimmten Namen auf dieselbe Weise auflösen, wie es jedes Programm auf dem System tut: getent passwd alice durchläuft die konfigurierten Quellen der Reihe nach und gibt den ersten Treffer aus, bei keinem Treffer nichts. Das ist der verlässliche Weg, um zu prüfen, ob dieses System den Benutzer sieht. Ein direktes Durchsuchen von /etc/passwd mit grep zeigt dagegen nur die lokale Quelle.
3. Prüfen, wie eine vollständig aufgelöste Identität aussieht, einschliesslich Gruppenmitgliedschaften, die aus einer anderen Quelle als das primäre Konto stammen können: id alice. Laut Man-Page gibt der Befehl Benutzer- und Gruppeninformationen für den angegebenen Benutzer aus, mit -G, --groups auch sämtliche Gruppen-IDs. Das ist nützlich, wenn eine auf der Verzeichnisseite hinzugefügte Gruppenmitgliedschaft nicht erscheint.
4. Ist SSSD eine der Quellen und erscheint eine auf der Verzeichnisseite vorgenommene Änderung (eine neue Gruppenmitgliedschaft, ein deaktiviertes Konto) nicht, liegt die Ursache oft im SSSD-Cache und nicht in der Abfragereihenfolge: sss_cache -E (als root) lässt alle zwischengespeicherten Einträge in sämtlichen konfigurierten Domains verfallen. Die nächste Abfrage geht dann wieder an den Provider, statt einen veralteten Cache-Eintrag zurückzugeben. sss_cache -u <user> betrifft dagegen nur einen einzelnen Benutzer statt den ganzen Cache.
5. Die Korrektur bestätigen: getent passwd alice (oder id alice) erneut ausführen und das Feld oder die Gruppenmitgliedschaft prüfen, die zuvor veraltet war.

Erwartetes Ergebnis

getent passwd <name> und id <name> geben nach sss_cache -E innerhalb einer Abfrage den aktuellen Stand des Verzeichnisses wieder, ohne dass der Dienst sssd neu gestartet werden muss. Bereits angemeldete Sitzungen behalten ihre alte Gruppenliste, bis sich der Benutzer erneut anmeldet.

Grenzen und Prüfbasis

getent passwd ohne Namen listet normalerweise nur lokale Benutzer auf, weil SSSD Verzeichnisbenutzer standardmässig nicht aufzählt; deshalb immer einen bestimmten Namen abfragen. getent meldet nur, was NSS auflöst: Steht in nsswitch.conf files vor sss und existiert für denselben Namen ein veralteter oder widersprüchlicher lokaler Eintrag, setzt sich dieser durch, und für diesen Namen werden nie Verzeichnisdaten abgefragt. sss_cache -E lässt Cache-Einträge verfallen, sodass die nächste Anfrage gegen den Provider geprüft wird; der Befehl selbst kontaktiert den Provider nicht. Damit die aktualisierten Daten sichtbar werden, muss daher eine Abfrage folgen. Ist der Provider in diesem Moment nicht erreichbar, kann SSSD je nach Offline-Cache-Konfiguration trotzdem den (nun als veraltet markierten) Cache-Wert ausliefern.