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