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
Given Red Hat support hasn't been able to fix our issue, what else can I do?
Cheers,
John
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
These links are not relevant to your problem. Symptoms might look simillar, but there root of problem will be different. In both cases, problem occurs with Active directory. But you are using id_provider = ad and #2483 (#2472) is about id_provider = ldap without id_mapping.
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
^^^^^^^^^^^^^^^ You can remove this line becuase it is enabled by defualt with "id_provider ad"
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
^^^^^^^^^^^^^^^ This is already disabled with "id_provider ad"
I would recommend to remove all folloving linse from your config file. You cannot be affected by bug from ticket #2483 therefore workarounds will not help.
I've tried a few config changes to fix the issue, but none has fixed it, including:
ldap_use_tokengroups = False
I would recommend to use default value "True". It should improve performace with id_prover ad.
ldap_group_objectsid = objectSID ldap_user_objectsid = objectSID
objectSID is already default value with id_provider ad
ldap_deref_threshold = 0 ldap_schema = rfc2307bis
You changed value of ldap_schema from ad -> rfc2307bis, which is not good idea for id_provider ad.
The ad provider in sssd is the simplification of complicated setup with ldap + krb5 provider. https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20... It also contains some ad specific features: sites, dynamic dns updates ... It's good that you are using ad provider. I would like to know how did you enrol sssd into Active Directory (adcli, net ads join?)
Given Red Hat support hasn't been able to fix our issue, what else can I do?
Support engineers can have good knowledge of sssd but they needn't be experts. Therefore developers need help them and it can some time. Depends on priorities. In some cases, it is faster to find solution here (sssd-users) because we (developers) watch this mailing list.
We would need to see log files from domain section for analysis. Please remove workarounds for ticket #2483. It will just complicate investigation and are useless. Unfortunately, our response can be slow due to upcoming holidays.
LS
OK, so all the workaround config changes are either useless or harmful, but we're still left with the problem. I can provide logs, but I'd rather not provide them publicly as they provide too many internal details I'd think...
We join computers to the domain using "kinit <domain_admin_user> && net ads join -k".
The Red Hat support engineer had me enable debug in various SSSD sections, and also provide the output from ldbsearch.
Cheers,
John
Oh, and I certainly understand about the holidays...I just started my Christmas break today. ;)
John
On (18/12/14 22:55), John Beranek wrote:
OK, so all the workaround config changes are either useless or harmful, but we're still left with the problem. I can provide logs, but I'd rather not provide them publicly as they provide too many internal details I'd think...
We join computers to the domain using "kinit <domain_admin_user> && net ads join -k".
The Red Hat support engineer had me enable debug in various SSSD sections, and also provide the output from ldbsearch.
Just for the record if anybody else have the same issue.
I exchanged many emails with John about this bug and we found out this bug is not related to togengroups at all. The problem is with processing nested groups. They have many groups and complicated structure.
We was able to get some groups with "ldap_group_nesting_level = 1". It is not solution because they need use at least default nesting level (2)
The processed nested groups are stored in wrong state: some groups have gidNumber 0 and contains some members.
ldbsearch -H var/lib/sss/db/cache_domain.ldb "(&(gidNumber = 0)(member = *))"
BTW togengroups was not used because Windows Server 2003 Functional Level was used and default version of sssd in el6.6 requires Windows Server 2008 Functional Level for tokengroups.
LS
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
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
On (17/04/15 09:11), John Beranek wrote:
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.
Thank you for confirmation. I was affraid it would be a problem for you.
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. :(
It should be fixed by ticket https://fedorahosted.org/sssd/ticket/2614
There isn't official upstream relase with these patches but you can test snapshot of latest 1.12 branch.
https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12-latest/
LS
sssd-users@lists.fedorahosted.org