To add to Lukas' update, I was seeing less issues with supplemental groups using the sssd 1.11.6 in RHEL/CentOS 6, but just this morning I've discovered that the issue is still lurking. It's still strangely intermittent, with some users getting supplemental groups at times, and then later not getting any groups.
Interesting about the behaviour 1.12 has of removing distribution groups, I must say I agree with the behaviour.
So, we still have a lingering issue with all the RHEL/CentOS 6 servers in our company, which puts us off patching from 6.5 to 6.6. :(
Cheers,
John
On 16 April 2015 at 17:22, Lukas Slebodnik lslebodn@redhat.com wrote:
On (17/12/14 20:54), John Beranek wrote:
Hi,
I've been investigating problems with the SSSD 1.11 versions supplied in RHEL/CentOS 6.6 for a while now. I've followed:
https://access.redhat.com/solutions/1264443 https://fedorahosted.org/sssd/ticket/2472
and also created a case with Red Hat support. However, I'm still no closer to solving the issue.
After updating servers to the SSSD in 6.6, intermittently (for particular users but not on all servers, and not necessarily all the time) users
don't
get their supplementary groups. e.g:
[root@rhel6-template sssd]# id matthewbe uid=46721(matthewbe) gid=20513(domain users) groups=20513(domain users)
This is with the latest SSSD on a RHEL6.6 server, i.e.:
sssd-1.11.6-30.el6_6.3.x86_64
Our environment is Windows 2003 AD controllers, and users *without* POSIX attributes in their AD records. So, snippets of sanitised sssd.conf:
[domain/AD] debug_level = 9 id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad
ad_server = dc01.local,dc02.local ad_backup_server = ad.local ad_domain = ad.local
# ID mapping min_id = 20000 ldap_idmap_range_min = 20000 #ldap_idmap_range_max = 220000 ldap_idmap_range_size = 200000 ldap_idmap_default_domain_sid = S-1-5-21-2365159532-2245169678-2931239768 ldap_schema = ad ldap_id_mapping = true override_homedir = /home/AD/%u override_shell = /bin/bash
# access controls ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true
# performance ldap_referrals = false
I've tried a few config changes to fix the issue, but none has fixed it, including:
ldap_use_tokengroups = False ldap_group_objectsid = objectSID ldap_user_objectsid = objectSID ldap_deref_threshold = 0 ldap_schema = rfc2307bis
I want just wrote a summary of long off the list discussion. We exchanged many log files and tested lot of packages. Thank you very much John for cooperation.
John's initial problem with missing supplementary groups was resolved after some changes on AD side. But there were sill some missing groups. We tested never version off sssd with enabled and disabled tokengrops.
sssd-1.12 with enabled tokengroups [user@host tmp]# id -G matthewbe | perl -pi -e 's/ /\n/g'|wc -l 39
sssd-1.9 (rhel 6.5) or (sssd-1.12 with disabled tokengroups) [user@host]$ id -G matthewbe | perl -pi -e 's/ /\n/g'|wc -l 134
The "workaround" with disabled tokengroups was actually a bug [2]. Sumit implemented filtering of "Distributions groups" [3] as part of ticket[1]. It did not work with disabled tokengrous due to bug[2].
Even thought im might look like regression from sssd-1.9 (less supplementary groups). It is by design. The "workaround" will not work with sssd >= 1.12.5 which will be released very soon.
Technet site says[3]: "Distribution groups are not security-enabled, which means that they cannot be listed in discretionary access control lists (DACLs)."
LS
[1] https://fedorahosted.org/sssd/ticket/2178 [2] https://fedorahosted.org/sssd/ticket/2614 [3] https://technet.microsoft.com/en-us/library/cc781446%28v=ws.10%29.aspx