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.

Solution

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

Comments

[Antitribu]

It was only after I configured a test box using SSSD and received the same results I started noticing it in other places, like VMware. That lead me to believe it was AD related and I found the above solution. My issue was very similar to what you have listed. The winbind command you're looking for is wbinfo --group-info