Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

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

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

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

Your Answer

 
discard

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