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

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.

share|improve this question

2 Answers 2

up vote 0 down vote accepted

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

security panel

share|improve this answer


I've got same trouble on winbind.
Here you are some analyze details of my case:
- several user are affected by this problem (total 800 users).
- only few group is missing (wbinfo -r ; id ) (some are still assigned) to problematic account - probably it's not caused by problematic user permisison in AD
- list of users in group is complete (getent group; unfortunately I haven't found way to list group users by wbinfo)
- all my servers use same version of samba and the problem appears on all of them with same user.
I'll try to set up SSSD to confirm, this issue is related to AD than to SAMBA.

share|improve this answer
    
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 –  Antitribu Sep 19 at 11:33

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.