Red Hat Bugzilla – Bug 599204
sssd does not work with non-anonymous LDAP access
Last modified: 2010-06-04 12:11:40 EDT
Description of problem: SSSD with LDAP does not work correctly with non-anonymous access to the LDAP directory, despite the use of the ldap_default_bind_dn, ldap_default_authtok_type, and ldap_default_authtok parameters. Version-Release number of selected component (if applicable): 1.2.0-12.fc13 How reproducible: Have the following in the sssd.conf file: [domain/default] ldap_tls_reqcert = demand ldap_id_use_start_tls = True cache_credentials = True ldap_default_authtok_type = password ldap_search_base = dc=house,dc=org chpass_provider = ldap id_provider = ldap auth_provider = ldap ldap_default_bind_dn = cn=nss_ldap,dc=house,dc=org debug_level = 10 min_id = 1000 ldap_uri = ldap://ldap.house.org/ krb5_realm = EXAMPLE.COM krb5_kdcip = kerberos.example.com ldap_schema = rfc2307 ldap_default_authtok = "<password removed>" ldap_tls_cacertdir = /etc/openldap/cacerts I see this in the sssd_default.log: (Wed Jun 2 16:26:38 2010) [sssd[be[default]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(objectclass=*)][]. (Wed Jun 2 16:26:38 2010) [sssd[be[default]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 2 (Wed Jun 2 16:26:38 2010) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x84c8b88], connected[1], ops[0x84d37e0], ldap[0x84ca1b8] (Wed Jun 2 16:26:38 2010) [sssd[be[default]]] [sdap_process_result] (8): Trace: ldap_result found nothing! (Wed Jun 2 16:26:38 2010) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x84c8b88], connected[1], ops[0x84d37e0], ldap[0x84ca1b8] (Wed Jun 2 16:26:38 2010) [sssd[be[default]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Wed Jun 2 16:26:38 2010) [sssd[be[default]]] [sdap_get_rootdse_done] (2): No RootDSE for server ?! (Wed Jun 2 16:26:38 2010) [sssd[be[default]]] [fo_set_port_status] (4): Marking port 389 of server 'ldap.house.org' as 'not working' If I change my openldap settings allow anonymous read access, the (objectclass=*) query succeeds. Even with anonymous access, certain attributes like userPassword are not accessible (as they should not be), so sssd still fails to authenticate a user. Steps to Reproduce: 1. 2. 3. Actual results: User is never authenticated Expected results: User gets authenticated Additional info: Until sssd works like nss_ldap does, how can sssd be disabled and the older nss_ldap be used?
Ok, there are two issues here. The first is a server misconfiguration. By the LDAP standard, the rootDSE has to be available before a bind is performed (as it tells the client what options the server supports in regards to authentication mechanisms like SASL). So that's why you're failing when using the non-anonymous bind. You have your ACLs set so that the rootDSE isn't readable by an unbound user, and we fail. We have an enhancement request open upstream to be graceful about this (https://fedorahosted.org/sssd/ticket/497) but it's still technically a misconfiguration. nss_ldap was a bit more accepting about this violation of the standard. You should configure your ACIs to allow unrestricted read access to the rootDSE. As for your second problem, that has nothing to do with the userPassword being unreadable. You are correct, that should absolutely not be accessible. We don't rely on it, we just do a connect and authenticated bind (the same as pam_ldap). I'd need to see your sssd_default.log for that case to tell you what went wrong there, but it's completely unrelated to your first issue. If I were to hazard a guess, I'd suspect that you have a certificate issue, which is preventing the bind from occurring (we don't allow passwords to be passed over an unencrypted channel, unlike pam_ldap).
Created attachment 420322 [details] SSSD log file SSSD log file
Ok, I changed the ACLs in my openldap server to allow anonymous read access to the root DSE with: access to dn.base="" by * read It appears that sssd is now correctly binding to the LDAP server, but it still doesn't appear to be working completely. I've attached the sssd_default.log. Brian
Is looks like your user "walkerb" is being filtered out. I would suggest to check his uid and gid and modify the "min_id" (the default is 1000) setting in SSSD config file accordingly.
The uid for walkerb is 1000, so this should meet the minimum, yes? Brian
Zaphod, please also check whether his primary GID is >= 1000.
Finally got this working... The userid walkerb was in GROUPS less than 1000, so this filtered it out apparently. id walkerb uid=1000(walkerb) gid=513(Domain Users) groups=513(Domain Users),512(Domain Admins),1000(webpublish),1001(momsclubwebpub),1002(webcal_admin) Perhaps there should be 2 different parameters, one for minimum uid and another for minimum gid? Likewise, there is no place to set this in the authentication config tool AND there is no place to set the bind user/password there either. Both would be really handy to have in the config tool so that manual editing of the sssd.config file is not necessary. Brian
We have an open bug to document the min_id/max_id options better. See bz #590513 This features (and the binddn) were left out of authconfig as a conscious decision. Authconfig is targeting the most common 90% case of deployments. For the remaining 10%, it's assumed that the configurations are complicated enough that the person actually implementing them will be tech-savvy enough to edit sssd.conf directly.
Thanks for the info. Since this is working now, it makes sense to have closed this bug report. Brian