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