Bug 742204

Summary: sssd LDAP authentication fails with specific versions of openldap-servers
Product: [Fedora] Fedora Reporter: anax_casablanca <anax>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: 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 02:49:04 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
/etc/sssd/sssd.conf
none
/tmp/sssd_LDAP.log
none
/etc/sssd/sssd.conf
none
final /etc/sssd/sssd.conf none

Description anax_casablanca 2011-09-29 07:39:41 EDT
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.
Comment 1 Stephen Gallagher 2011-09-29 08:15:20 EDT
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.
Comment 2 anax_casablanca 2011-09-29 10:44:29 EDT
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.
Comment 3 Stephen Gallagher 2011-09-29 11:05:54 EDT
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?
Comment 4 anax_casablanca 2011-09-29 11:29:37 EDT
Created attachment 525595 [details]
/tmp/sssd_LDAP.log
Comment 5 anax_casablanca 2011-09-29 11:30:35 EDT
Created attachment 525596 [details]
/etc/sssd/sssd.conf
Comment 6 Stephen Gallagher 2011-09-29 11:57:03 EDT
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.
Comment 7 anax_casablanca 2011-09-30 02:45:12 EDT
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
Comment 8 anax_casablanca 2011-09-30 02:47:25 EDT
Created attachment 525684 [details]
final /etc/sssd/sssd.conf
Comment 9 Stephen Gallagher 2011-09-30 07:22:55 EDT
(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)
Comment 10 anax_casablanca 2011-09-30 09:46:14 EDT
I understand and wish you good luck.

suomi