Ich habe mehrere RHEL5-Server geerbt, die so eingerichtet waren, dass sie Benutzer über Winbind gegenüber ihren AD-Konten authentifizieren. Alles funktioniert einwandfrei, bis ich die Gruppenmitgliedschaft in AD aktualisiere. Bei einigen Benutzern gelangen die Änderungen nie in die Ausgabe des Befehls „groups“, obwohl sie in der Ausgabe von „getent group <groupname>“ widergespiegelt werden.
Betrachten Sie beispielsweise Folgendes:
[root@hcc1pl1 ~]# Gruppen Plubans
Plubans: Domänenbenutzer, Systeme, Infrastrukturentwicklung
[root@hcc1pl1 ~]# getent group q1esb
q1esb:*:23136:q1qai,q1prodi
Wenn ich mich selbst zu q1esb auf dem von winbind verwendeten DC hinzufüge, können Sie sehen, dass die Mitgliedschaft aktualisiert wird:
[root@hcc1pl1 ~]# lsof -i | grep winbind
winbindd 31339 root 17u IPv4 63817934 TCP hcc1pl1:56541->hcnas01:microsoft-ds (HERGESTELLT)
winbindd 31339 root 21u IPv4 63817970 TCP hcc1pl1:53622->hcnas01:ldap (HERGESTELLT)
[root@hcc1pl1 ~]# ldapsearch -u -x -LLL -h hcnas01 -D "[email geschützt]" -W -b "CN=Peter Lubans,OU=Standardbenutzerkonten,OU=Benutzer,OU=XXX,DC=XXX,DC=XXX" "(sAMAccountName=*)" memberOf
Geben Sie das LDAP-Passwort ein:
...
memberOf: CN=q1esb,OU=Sicherheitsgruppen,OU=Gruppen,OU=XXX,DC=XXX,DC=XXX
...
Beachten Sie, dass Winbind ohne Caching ausgeführt wird (Flag -n):
[root@hcc1pl1 ~]# ps -ef | grep winbind
root 31339 1 0 13:50 ? 00:00:00 winbindd -n
root 31340 31339 0 13:50 ? 00:00:00 winbindd -n root
31351 31339 0 13:50 ? 00:00:00 winbindd -n
root 31352 31339 0 13:50 ? 00:00:00 winbindd -n
root 31353 31339 0 13:50 ? 00:00:00 winbindd -n
Jetzt zeigt getent, dass diese Gruppe die richtigen Mitglieder hat:
[root@hcc1pl1 ~]# getent-Gruppe q1esb
q1esb:*:23136:q1qai,plubans,q1prodi
Die aktualisierte Mitgliedschaft wird jedoch nicht in meinen Kontodetails angezeigt:
[root@hcc1pl1 ~]# Gruppen Plubans
Plubans: Domänenbenutzersysteme Infrastrukturentwicklung
[root@hcc1pl1 ~]#
Das wirklich Ärgerliche an diesem Problem ist, dass es für andere Konten auf diesem Computer und für mein Konto auf Computern, die ich von Grund auf konfiguriert habe, einwandfrei funktioniert.
Irgendwelche Ideen?
Antwort1
Dies scheint dadurch verursacht worden zu sein, dass Gruppeninformationen beim Anmelden in /var/cache/samba/netsamlogon_cache.tdb zwischengespeichert wurden. Ich vermute, dass, obwohl „-n“ Winbind angewiesen hat, seine Abfragen gegen LDAP nicht zwischenzuspeichern, das Vorhandensein der Mitgliedschaftsinformationen in dieser TDB-Datei ausreichte, um alles durcheinander zu bringen.
Antwort2
Es gelang mir, Marcins verlorenen Artikel wiederzubeschaffen (https://marcinm.co.uk/Gruppenmitgliedschaft wird in Winbind nicht aktualisiert/), indem Sie ihn per E-Mail fragen. Da ich sicher bin, dass dies zumindest einigen Leuten helfen wird, ist hier sein ganzer Blog-Beitrag:
Szenario
Auf dem Dateiserver wird smbd ausgeführt security=ads(d. h. er fungiert als Domänenmitglied). Der Benutzer stellt eine Verbindung zur Samba-Freigabe her und bekommt beim ersten Verbindungsaufbau die Gruppenmitgliedschaft korrekt erfasst – und sie wird danach nie wieder aktualisiert.
Grundursache
Samba aktualisiert die Gruppenmitgliedschaft, wenn sie vom AD-Domänencontroller berechnet wird, und sie wird nur berechnet, wenn sich der Benutzer bei einem Server anmeldet, auf dem smbd und winbind laufen. Dies wird wbinfo -anur durch eine kerberisierte SMB-Anmeldung ausgelöst. Da dies eine ernste Einschränkung ist, d. h. dass auf Maschinen, an denen sich der Benutzer nie anmeldet, überhaupt keine Gruppenmitgliedschaft bekannt wäre, wurde ein Fallback-Gruppenmitgliedschaftscode entwickelt, der die Gruppenmitgliedschaft des Benutzers aus AD abruft, ohne dass sich der Benutzer anmeldet, aber da das von winbind verwendete Maschinenkonto nicht die Rechte hat, nach einer Benutzergruppenmitgliedschaft zu fragen, gilt er als fehlerhaft und seine Ergebnisse sind unzuverlässig. Daher verlässt sich winbind nie darauf – es ruft es auf, wenn überhaupt keine Gruppenmitgliedschaft bekannt ist, aber es wird nie verwendet, um zwischengespeicherte Gruppenmitgliedschaften zu aktualisieren. Dies hat zur Folge, dass winbind in manchen Szenarien die Benutzergruppenmitgliedschaften einmal erfasst und sie danach nie wieder aktualisiert.
Es ist nicht möglich, das Zwischenspeichern von Gruppenmitgliedschaften zu deaktivieren, d. h. es gibt keine Möglichkeit, dieses Verhalten durch Einfügen einer Zeile zu deaktivieren smb.conf. Beachten Sie, dass dies kein Samba-Problem, sondern ein AD-Designproblem ist. Dieses Verhalten entspricht der Art und Weise, wie sich Windows verhält, was effektiv darin besteht, dass die AD-Gruppenmitgliedschaft aktualisiert wird, wenn sich ein Benutzer bei der Anmeldung authentifiziert.
So erzwingen Sie die Aktualisierung der Gruppenmitgliedschaft für einen Benutzer
Die Gruppenmitgliedschaft wird in einer Datei namens zwischengespeichert netsamlogon_cache.tdb, die mit tdbtool (alle Versionen von Samba) oder net cache samlogon(Samba 4.7 oder neuer) untersucht werden kann. Das Löschen zwischengespeicherter Einträge aus dieser Datei löst eine einmalige Aktualisierung der Gruppenmitgliedschaften aus, indem der Fallback-Aktualisierungscode aufgerufen und sein Ergebnis wieder eingefügt wird netsamlogon_cache.tdb– und danach werden sie wieder dauerhaft zwischengespeichert.
tdbtool-Weg:
$ wbinfo -n user.name
S-1-5-21-3023451936-689652692-1079546996-40725 SID_USER (1)
an SID anhängen \0und in Anführungszeichen setzen:
$ tdbtool netsamlogon_cache.tdb delete "S-1-5-21-3023451936-689652692-1079546996-40725\0"
Die Gruppenmitgliedschaft wird aktualisiert, wenn das Betriebssystem sie zum ersten Mal benötigt. Warten Sie einige Minuten, bis die tdb-Datei ausgefüllt ist.
Net Cache Samlogon-Weg:
$ net cache samlogon list|head
SID Name When cached
---------------------------------------------------------------------------------------------------------------------------
S-1-5-21-3023451936-689652692-1079546996-40725 DOM\user.name Tue Apr 27 07:59:19 AM 2018 BST
S-1-5-21-3023451936-689652692-1079546996-41432 DOM\user.name2 Tue Apr 27 02:13:33 PM 2018 BST
$ net cache samlogon delete S-1-5-21-3023451936-689652692-1079546996-40725
Wie zuvor – die Gruppenmitgliedschaft wird aktualisiert, wenn das Betriebssystem dies zum ersten Mal benötigt. Warten Sie einige Minuten, bis die TDB-Datei aufgefüllt ist.
Antwort3
Mein einziger Gedanke, und der ist sehr vage, ist, dass es etwas mit der Kommunikation mit Ihrem Infrastrukturmaster zu tun haben könnte (der für die domänenübergreifende Aktualisierung der Gruppenmitgliedschaften verantwortlich ist).
Antwort4
Ich hatte etwas Ähnliches. Um das Problem zu beheben, habe ich „authconfig --disablecache --update“ ausgeführt. Natürlich wurden die Anmeldungen dadurch langsamer.