Bug 599204

Summary: sssd does not work with non-anonymous LDAP access
Product: [Fedora] Fedora Reporter: Zaphod Beeblebrox <zaphod24>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 13CC: jhrozek, sbose, sgallagh, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-04 12:01:37 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
SSSD log file none

Description Zaphod Beeblebrox 2010-06-02 16:34:33 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?
Comment 1 Stephen Gallagher 2010-06-02 16:56:45 EDT
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 16:54:42 EDT
Created attachment 420322 [details]
SSSD log file

SSSD log file
Comment 3 Zaphod Beeblebrox 2010-06-03 16:56:51 EDT
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
Comment 4 Jakub Hrozek 2010-06-04 05:35:25 EDT
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 11:13:25 EDT
The uid for walkerb is 1000, so this should meet the minimum, yes?

Brian
Comment 6 Stephen Gallagher 2010-06-04 11:19:50 EDT
Zaphod, please also check whether his primary GID is >= 1000.
Comment 7 Zaphod Beeblebrox 2010-06-04 11:48:51 EDT
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
Comment 8 Stephen Gallagher 2010-06-04 12:01:37 EDT
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 12:11:40 EDT
Thanks for the info. Since this is working now, it makes sense to have closed this bug report.

Brian