Bug 599204 - sssd does not work with non-anonymous LDAP access
Summary: sssd does not work with non-anonymous LDAP access
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd   
(Show other bugs)
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-02 20:34 UTC by Zaphod Beeblebrox
Modified: 2010-06-04 16:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-04 16:01:37 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
SSSD log file (71.16 KB, text/x-log)
2010-06-03 20:54 UTC, Zaphod Beeblebrox
no flags Details

Description Zaphod Beeblebrox 2010-06-02 20:34:33 UTC
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):

How reproducible:
Have the following in the sssd.conf file:
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:
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?

Comment 1 Stephen Gallagher 2010-06-02 20:56:45 UTC
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).

Comment 2 Zaphod Beeblebrox 2010-06-03 20:54:42 UTC
Created attachment 420322 [details]
SSSD log file

SSSD log file

Comment 3 Zaphod Beeblebrox 2010-06-03 20:56:51 UTC
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.


Comment 4 Jakub Hrozek 2010-06-04 09:35:25 UTC
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.

Comment 5 Zaphod Beeblebrox 2010-06-04 15:13:25 UTC
The uid for walkerb is 1000, so this should meet the minimum, yes?


Comment 6 Stephen Gallagher 2010-06-04 15:19:50 UTC
Zaphod, please also check whether his primary GID is >= 1000.

Comment 7 Zaphod Beeblebrox 2010-06-04 15:48:51 UTC
Finally got this working...

The userid walkerb was in GROUPS less than 1000, so this filtered it out

id walkerb
uid=1000(walkerb) gid=513(Domain Users) groups=513(Domain Users),512(Domain

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.


Comment 8 Stephen Gallagher 2010-06-04 16:01:37 UTC
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.

Comment 9 Zaphod Beeblebrox 2010-06-04 16:11:40 UTC
Thanks for the info. Since this is working now, it makes sense to have closed this bug report.


Note You need to log in before you can comment on or make changes to this bug.