Linux nested groups with winbind

Question

We have several RHEL6 servers connected to Active Directory using winbind. All servers are configured identically using a configuration management tool. Servers however produce different results when querying groups using the groups command and/or sudo. Getent and winbind however return correct consistent results on all servers.

user.name1 and user.name2 are members of the group test.group1. test.group1 is a member of the group test.group2

Running the following commands is consistent on all servers:

# getent group test.group1 test.group1:*:16126:user.name1,user.name2 # getent group test.group2 test.group2:*:16125:user.name1,user.name2 # wbinfo --group-info test.group1 test.group1:*:16126:user.name1,user.name2 # wbinfo --group-info test.group2 test.group2:*:16125:user.name1,user.name2 

However server A incorrectly returns:

# groups user.name2 test.group1 

Server B correctly returns:

# groups user.name2 test.group1 test.group2 

The Samba config looks like:

 winbind use default domain = true winbind offline logon = false winbind separator = + winbind enum users = Yes winbind enum groups = Yes winbind nested groups = Yes winbind expand groups = 10 server string = Linux Server strict locking = no wins server = 192.168.0.1 idmap config * : range = 10000-50000000 idmap config * : backend = rid idmap config SENT : range = 10000-50000000 idmap config SENT : default = yes idmap config SENT : backend = rid idmap uid = 10000-50000000 idmap gid = 10000-50000000 

nsswitch.conf looks like:

passwd: files winbind shadow: files winbind group: files winbind 

I'd hazard a guess to say the answer is somewhere in PAM or perhaps a winbind lookup error, Any thoughts or suggestions as where to look? Winbind / servers have been restarted, tdb files rebuilt. The problem may be intermittent as well.

---

Edit:

Finally getting to have another look at this issue. I've rebuilt the authentication using SSSD instead of winbind and the same occurs

sssd.conf

[sssd] config_file_version = 2 domains = sent.local services = nss, pam debug_level = 1 [nss] [pam] [domain/sent.local] id_provider = ad auth_provider = ad access_provider = ad default_shell = /bin/bash fallback_homedir = /home/domain/%u use_fully_qualified_names = False 

Now we have some interesting results, users who have never been domain admins have the same result as before, until we pre-cache the groups we know they are members of, for example:

[root@test-smg1 - (11:46:40) sssd]# id test.user5 uid=1084806380(test.user5) gid=1084800513(domain users) groups=1084800513(domain users) [root@test-smg1 - (11:46:43) sssd]# getent group testg2 testg2:*:1084806126:test.user5,test.user4,test.user3,test.user2 [root@test-smg1 - (11:46:46) sssd]# id test.user5 uid=1084806380(test.user5) gid=1084800513(domain users) groups=1084800513(domain users),1084806126(testg2) [root@test-smg1 - (11:46:49) sssd]# getent group testg2-nest testg2-nest:*:1084806125:test.user4,test.user3,test.user2,test.user5 [root@test-smg1 - (11:46:54) sssd]# id test.user5 uid=1084806380(test.user5) gid=1084800513(domain users) groups=1084800513(domain users),1084806126(testg2),1084806125(testg2-nest) 

This makes me think the issue might be more in the direction of active directory and this ADs specific implementation than an issue linux side. Making a user a member of Domain Admins causes all their groups to show correctly. Removing the user from Domain Admins leaves the user in this "fixed" state.

Answer 1

Looks like it is a very specific issue inside our AD setup, "Read group membership" is checked for authenticated users for users it currently works and unchecked for those it doesn't. Adding this right fixes the issue (though winbind takes a substantial amount of time to pick up on the change).