6

I have inherited several RHEL5 servers that were set up to authenticate users against their AD accounts via winbind. Everything works fine until I update group membership in AD. For some users, the changes never make it to the output of the "groups" command, although they are reflected in the output of "getent group <groupname>".

For example, consider the following:

[root@hcc1pl1 ~]# groups plubans
plubans : domain users systems infrastructure development
[root@hcc1pl1 ~]# getent group q1esb
q1esb:*:23136:q1qai,q1prodi

If I add myself to q1esb on the DC that winbind is using, you can see that the membership is updated:

[root@hcc1pl1 ~]# lsof -i | grep winbind
winbindd 31339 root 17u IPv4 63817934 TCP hcc1pl1:56541->hcnas01:microsoft-ds (ESTABLISHED)
winbindd 31339 root 21u IPv4 63817970 TCP hcc1pl1:53622->hcnas01:ldap (ESTABLISHED)
[root@hcc1pl1 ~]# ldapsearch -u -x -LLL -h hcnas01 -D "plubans@XXX.XXX" -W -b "CN=Peter Lubans,OU=Standard User Accounts,OU=Users,OU=XXX,DC=XXX,DC=XXX" "(sAMAccountName=*)" memberOf
Enter LDAP Password:
...
memberOf: CN=q1esb,OU=Security Groups,OU=Groups,OU=XXX,DC=XXX,DC=XXX
...

Note that winbind is running without caching (-n flag):

[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

Now getent shows that that group has the correct members:

[root@hcc1pl1 ~]# getent group q1esb
q1esb:*:23136:q1qai,plubans,q1prodi

But the updated membership is not reflected in my account details:

[root@hcc1pl1 ~]# groups plubans
plubans : domain users systems infrastructure development
[root@hcc1pl1 ~]#

The truly vexing part of this problem is that it works fine for other accounts on this machine, and for my account on machines that I have configured from the ground up.

Any ideas?

5 Answers5

4

It appears that this was caused by group information being cached at logon-time in /var/cache/samba/netsamlogon_cache.tdb. I guess that although '-n' instructed winbind not to cache it's queries against LDAP, the presence of the membership information in that TDB file was enough to mess things up.

  • 1
    So how do I "refresh" that log-on info? I have logged out of the linux box and log in again but the problem still persists. – Zhang18 Apr 21 '17 at 19:35
0

I had something similar. To fix the problem I ran "authconfig --disablecache --update". Of course it made logons slow.

dustin
  • 1
0

My only thought and it is a very vague one is that it might have something to do with communication with your Infrastructure Master (which is responsible for updating group memberships across domains).

Catherine MacInnes
  • 1,958
  • 11
  • 15
0

I've had a similar experience with RHEL's stock samba/winbind packages. It's been my experience that RHEL's winbind is a little sketchy. What I observed was that once a user authenticated, their group membership would be accurately updated, but aside from that, no changes in group membership would ever show up. This is not an optimal solution, particularly if you remove a user from a group that would grant them access to the machine, since it effectively gives them one last login that they shouldn't get. This may or may not reflect your situation exactly though, because I also suffered from not seeing the group members of an AD group when running getent group (it would just look like a group with no members, even if groups username showed them as a member of the group), but it appears that is working for you.

What solved the problem for me was installing the "tested" distribution of RPMs from enterprisesamba.org. Group membership changes showed up immediately, regardless of winbind cache settings. Required no configuration changes, BUT if you're mapping AD users and groups with a local idmap table installing the new RPMS will more than likely completely remap your numeric group and user ids, so be prepared for that (dump your getent group and getent passwd output to a file before upgrading so you have a reference to fix file ownership with.

rvf
  • 1,435
  • 1
  • 13
  • 9
  • "What I observed was that once a user authenticated, their group membership would be accurately updated, but aside from that, no changes in group membership would ever show up." A note to others that may be helpful is that the key here is "*once a user authenticated*". I had similar problem where I would `su myaduser` (from root) and yet running `groups` showed that the AD changes had not applied. **Signing in as myaduser (ie. entering my password) seems to have properly updated the user's groups settings**. – lampShadesDrifter Mar 01 '21 at 23:01
-1

I had the same problem here, and I found this link (https://marcinm.co.uk/group-membership-not-updating-in-winbind/) that explains in detail what happens. Following the steps and deleting the records from the cache, my problem was solved.

Bye

Douglas Comim
  • 1
  • Adding some more info on the steps you took to solve the problem will mean that if the link dies, other users can still benefit from your answer. Thanks! – shearn89 Dec 02 '21 at 12:08
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - [From Review](/review/late-answers/504333) – Dave M Dec 05 '21 at 12:49
  • It's no longer an "if". The link is dead. – KenB Sep 22 '22 at 23:28