Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

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

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?

share|improve this question

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.

share|improve this answer

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).

share|improve this answer

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 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.

share|improve this answer

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

share|improve this answer

I have the same issue with this. Since this is last 2009, have you guys found solution for this problem?

Any advise would be deeply appreciated.


share|improve this answer
Anyone interested to share ideas and solutions can you please comment to…. Thanks – James W. Jun 24 '15 at 7:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.