On 31 Oct 2014, at 00:46, Trey Dockendorf <treydock(a)gmail.com>
wrote:
I have a number of systems all on CentOS 6.5 with sssd-1.9.2 and had been using enumerate
= True to support SLURM. After bringing ~300 nodes online all with enumeration enabled, I
found my LDAP server was getting hit hard every 5 minutes. We've opted to disable
enumeration, but since then all group membership lookups are failing.
$getent group general
<no output>
The sssd_LDAP.log shows:
(Thu Oct 30 18:41:03 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS
result: Success(0), Start TLS request accepted.Server willing to negotiate SSL.
(Thu Oct 30 18:41:03 2014) [sssd[be[LDAP]]] [sdap_get_server_opts_from_rootdse] (0x0200):
No known USN scheme is supported by this server!
(Thu Oct 30 18:41:03 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0040):
Unexpected result from ldap: Protocol error(2), A dereference attribute must have DN
syntax
We’re trying to dereference uniqueMember here, does it have DN syntax on the server side?
(Thu Oct 30 18:41:03 2014) [sssd[be[LDAP]]] [sdap_deref_search_done]
(0x0040): dereference processing failed [5]: Input/output error
(Thu Oct 30 18:41:03 2014) [sssd[be[LDAP]]] [sdap_nested_group_deref_direct_done]
(0x0020): Error processing direct membership [5]: Input/output error
(Thu Oct 30 18:41:03 2014) [sssd[be[LDAP]]] [sdap_nested_done] (0x0020): Nested group
processing failed: [5][Input/output error]
(Thu Oct 30 18:41:03 2014) [sssd[be[LDAP]]] [sdap_id_op_done] (0x0200): communication
error on cached connection, moving to next server
If I re-enable enumeration, "getent group" works with just fine. If I do a
"id" on a user account, their primary group just shows the GID, no group name
which is breaking numerous applications. As a test I upgraded a dev system to sssd-1.11.6
based on this bug report,
https://bugzilla.redhat.com/show_bug.cgi?id=1109188. However
the issue persists. I've cleared caches and the result is the same.
The LDAP servers are 389ds version 1.2.11.15-32.el6.
Below is my sssd.conf. What else can be done to debug this or resolve this issue?
Can you try disabling dereference altogether with ldap_deef_threshold=0 in the domain
section?
Thanks,
- Trey
[sssd]
config_file_version = 2
debug_level = 0x02F0
reconnection_retries = 3
sbus_timeout = 30
services = nss,pam,sudo,ssh
domains = LDAP
[nss]
debug_level = 0x02F0
reconnection_retries = 3
filter_groups = root,wheel
filter_users = root
[pam]
debug_level = 0x02F0
reconnection_retries = 3
offline_credentials_expiration = 0
[sudo]
[ssh]
[domain/LDAP]
debug_level = 0x02F0
cache_credentials = TRUE
entry_cache_timeout = 6000
enumerate = FALSE
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
access_provider = ldap
sudo_provider = ldap
ldap_uri = ldap://ldap01.DOMAIN,ldap://ldap02.DOMAIN
ldap_search_base = <OMIT>
ldap_network_timeout = 3
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/puppet-ca.crt
ldap_schema = rfc2307bis
ldap_id_use_start_tls = TRUE
ldap_chpass_update_last_change = TRUE
ldap_group_member = uniquemember
ldap_group_object_class = posixGroup
ldap_group_name = cn
ldap_pwd_policy = none
ldap_account_expire_policy = 389ds
ldap_access_order = filter,expire
ldap_access_filter = (objectclass=posixaccount)
ldap_sudo_search_base = ou=SUDOers,<OMIT>
Thanks,
- Trey
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users