The 'groups' command is not retrieving the complete supplementary group membership and is causing various permissions-based issues.

On a Linux AD client running 4.22.7

% groups webapp
webapp : webappg domain users


On a Linux AD client running 4.21.10

% groups webapp
webapp : webappg domain users faculty hc_server submit hc_prism hc_public privkey

As you can see the Linux AD client running 4.22.7, doesn't return all the groups.


We are aware of the config option 'winbind expand groups = 1' which can help. If this option is enabled, it results in a lookup, which results in a severe performance hit.

Something changed in the Samba 4.22 code.


From a colleague who is also investigating this issue.
-------
When winbind expand groups = 0 (which is the default, and has been for many versions), then during login, the AD controller sends back a token for the user which includes primary group, and secondary groups.  Winbind stores the token in its cache.  If you run "groups" winbind just reads that groups from the cached token.

When winbind expand groups = 1, winbind doesn't rely on that information from login.  It looks up all the groups that contain the user.

So when expand groups = 0, AD gives winbind the complete list of groups at login.  Winbind just reuses that list when you ask.  But when "expand groups = 1" winbind does the work itself.  It's slower, and doesn't rely on the login token.

Now, we know that after reboot, groups is fine, so what happens?

So on login, winbind stores the token in netsamlogon_cache.tdb... it's all good.
At some point, I believe the login token ages out, so I think it has to re-request the info from AD, and that's where the bug probably lies.  Maybe there's a cache corruption at this point under a certain scenario (maybe high load) and the token it gets back must contain only the primary group.  

----------



There is another bug report filed at Red Hat, which is very similar.


https://issues.redhat.com/browse/RHEL-138263


Something has changed in 4.22.7. We tried upgrading to Samba 4.23.4, but there was no resolution.


How do we solve this issue without taking a performance hit? 



On the host in question (Linux AD client 4.22.7 and 4.21.10):
------
egrep -i '^passwd|^group' /etc/nsswitch.conf
passwd:      files winbind systemd
group:       files winbind systemd



/etc/samba/smb.conf
global]
workgroup = HOSTHOSTCA
security = ADS
realm = AD.HOST.HOST.CA
dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and keytab
winbind use krb5 enterprise principals = no
winbind max clients = 600

idmap config * : backend = tdb
idmap config * : range = 1000000-1999999
 
# idmap config for the HOSTHOSTCA domain
# range should match UNIX ID in AD

idmap config HOSTHOSTCA : backend = ad
idmap config HOSTHOSTCA : schema_mode = rfc2307
idmap config HOSTHOSTCA : range = 1000-999999
idmap config HOSTHOSTCA : unix_primary_group = yes
idmap config HOSTHOSTCA : unix_nss_info = yes

# Renew the kerberos tickets
winbind refresh tickets = yes
 
# Enable offline logins
winbind offline logon = yes
 
# User uid/Gid from AD. (rfc2307)
winbind nss info = rfc2307

# With default domain, wbinfo -u, yes = username, no is SAMBADOM\username
winbind use default domain = yes
 
# Keep no in production, set yes when debugging, this slows down your samba.
winbind enum users  = no
winbind enum groups = no

# For Windows ACL support on member file server, enabled globaly, OBLIGATED
# For a mixed setup of rights, put this per share!
vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes

# Template settings for login shell and home directory
template shell = /bin/bash
template homedir = /eecs/home/%U

#log files
debug timestamp = yes
debug uid = yes
debug pid = yes
debug level = 1
max log size = 0

# printing (none)
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes

# security
username map = /xconf/samba/usermap
guest account = nobody
----