Bug 742204
| Summary: | sssd LDAP authentication fails with specific versions of openldap-servers | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | anax_casablanca <anax> | ||||||||||
| Component: | sssd | Assignee: | Stephen Gallagher <sgallagh> | ||||||||||
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 15 | CC: | jhrozek, sbose, sgallagh, ssorce | ||||||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2011-09-30 06:49:04 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
This is not a bug. SSSD does not allow authentication over an unsecure channel, because the LDAP protocol sends the password in the clear. It is trivial to snoop an unencrypted LDAP request. Because of this, SSSD requires that password authentication will only happen over a secure channel. If the main identity channel is unencrypted, we will still always attempt to use START_TLS before sending the password. If the connection is already using START_TLS (due to the ldap_id_use_start_tls = true option) or is made over LDAPS (using ldap_uri = ldaps://...) then no additional step is required. This is a security feature, intended to prevent you from accidentally exposing your credentials. It can't be a security feature, that START_TLS as well as the opening of the LDAPS connection fails. I agree with you, that passwords in general should be sent over secure/encrypted connections unless you use a challenge/response mechanism such as digest-md5. I need to have an sssd which is able to open an LDAPS or START_TLS connection with the ldap server version openldap-servers-2.4.15-7.fc11.i586. Apparently, the actual version sssd-1.5.13-1.fc15.2.x86_64 is not capable to do that. Sorry, I think I misunderstood your original report. I thought you were saying that you didn't want it trying to use SSL/TLS. If I understand correctly now, you're saying that on older openldap servers, it's failing to establish the START_TLS request successfully, but it works on newer servers. Is that correct? If that's the case, I suspect it's most likely to be a certificate-related issue. Could you please set debug_level = 8 in the [domain/LDAP] section of sssd.conf, restart sssd, perform an auth request and then attach /var/log/sssd/sssd_LDAP.log (sanitized as needed) to this bugzilla ticket? Created attachment 525595 [details]
/tmp/sssd_LDAP.log
Created attachment 525596 [details]
/etc/sssd/sssd.conf
Unfortunately we're hitting http://www.openldap.org/its/index.cgi/Incoming?id=6789 here, which is making the debug log not terribly helpful. However, I do note that you're not setting either ldap_tls_cacert or ldap_tls_cacertdir, which may mean that the real problem is that SSSD is unable to verify the certificate of the LDAP server you're connecting to. If neither is specified, it will use the openldap defaults (usually /etc/openldap/cacerts), but you need to make sure that this directory has had cacertdir_rehash run on it, or the certificates won't be usable. Now it runs. That is, sssd-1.5.13-1.fc15.2.x86_64 can establish an SSL/TLS connection with openldap-servers-2.4.15-7.fc11.i586. The following steps lead to the solution: 1. ldap_tls_cacert = /etc/pki/CA/certs/cacert.pem which did not help any further, that is, authentication still failed. 2. Then, according to what you have said in your comments, I checked the certificates of the openldap server, and it showed, that the server certificate (not the CA certificate) had run out. So, I gave the openldap server a new server certificate, whereupon authentication succeeded. It remains to be said, that the indications/error messages in the sssd debug output are just useless, when a connection to the LDAP server fails, to say the least. Also, the openldap server log is not helpfull, it just says: Failed to establish SSL/TLS. If in the future, we want to use only secure connections with certificates for each minor applications, we must have more powerful tools to check these connections. Thank you very much for your attention and your valuable time. suomi Created attachment 525684 [details]
final /etc/sssd/sssd.conf
(In reply to comment #7) > It remains to be said, that the indications/error messages in the sssd debug > output are just useless, when a connection to the LDAP server fails, to say the > least. I agree with you completely here. The full history here is that last year the openldap libraries migrated from using openssl to using mozilla-nss for its crypto support (for regulatory compliance). However, one of the side-effects of this conversion was that openldap now does not report useful error messages on certificate failure. I'm told this is because mozilla-nss doesn't expose such messages properly to its consumers. I am working with the openldap maintainers to try and solve this issue (see the openldap bug I linked to in comment #6) I understand and wish you good luck. suomi |
Created attachment 525532 [details] /etc/sssd/sssd.conf Description of problem: sssd-1.5.13-1.fc15.2.x86_64 always tries to connect to the LDAP Server with either LDAPS (port 636) or with LDAP (port 389) with START_TLS, even if FORCELEGACY in /etc/sysconfig/authconfig is set to true. Either LDAPS or the START_TLS always fails with openldap servers version openldap-servers-2.4.15-7.fc11.i586. It succeeds, however, with openldap servers version openldap-servers-2.4.24-3.fc15.x86_64 Version-Release number of selected component (if applicable): sssd-1.5.13-1.fc15.2.x86_64 How reproducible: always Steps to Reproduce: 1. configure sssd, so that it connects to an openldap server of the above version. 2. restart sssd 3. try to do a user authentication for a user, which is stored on the LDAP server Actual results: The authentication fails. Expected results: The authentication succeeds. Additional info: when starting sssd with debug level 255 and an LDAP URL of LDAP://old.ldap.server (as opposed to an URL of LDAPS://old.ldap.server, you see, that sssd initially connects to the LDAP server correctly (without LDAPS nor START_TLS). It then retrieves the user list, sorts out the users, and caches the users it wants to keep. All OK sofar. But as soon as an authentication request is submitted to sssd, it again tries to connect the LDAP server with either LDAPS or START_TLS, even if you have set cache_credentials = true . Then, the connection fails and authentication fails also.