Description of problem:
One of the most common setup cases for LDAP is to use a self-signed certificate for the company's LDAP server. When an encrypted connection is needed (either in the form of LDAPS or LDAP+TLS), by default the SSSD will demand a certificate that it can validate.
Not all users will be aware, however, that they need to download a CA certificate for the self-signed server. We should add a checkbox 'Allow authentication via self-signed certificates' that translates to the sssd.conf value:
ldap_tls_reqcert = allow
(The default if this option is unspecified is "demand")
This means that the certificate will be used even if it is not verified against a CA cert.
Version-Release number of selected component (if applicable):
I do not quite agree with this as this setting is not secure - if you do not explicitely establish the trust to the CA certificate (or to the self-signed certificate) any MITM can impersonate the LDAP server and be able to fool the machine to allow anybody to log-in.
I'd prefer to implement some way to pull the certificate from the ldap connection and store it so it can be trusted. This is similar to what openssh does although here it would be part of the authconfig code. But this is F14 work to do.
Mockups to account for this change are available in the latest draft (draft 5) of the authconfig-gtk mockups. The screens of interest are as follows:
I think I follow what you're suggesting, Tomas. We should add perhaps ldap_tls_reqcert = once. This would make the assumption that the connection is safe the first time. On the first connection made by the SSSD, we should store the CA cert into the proper directory, run the cacertdir_hash routine and then always rely on that for future connections.
Is this an accurate rephrasing of your suggestion above?
I thought of implementing the first connection in authconfig itself but if you would do that in SSSD it would make sense as well. Whatever you prefer. If the implementation is done on the SSSD side there is still remaining issue how to implement change of the certificate in case of legitimate change of the certificate on server (expiration etc.). We would need to somehow trigger a connection which would remove the old certificate and install a new one.
Hmm, this is going to need a bit more thought. Ideally, we should present the user the option to accept the certificate. So that would probably be better done in authconfig rather than SSSD.
We're still speaking in general terms, however. I'm not even sure at this point whether we can get this directly from the LDAP connection.
It should be definitely possible to get it from the LDAP connection at least in the self-signed host certificate case. It will require quite bit of code though. And yes I also think that it would be probably better to do this in authconfig rather than SSSD.
Should we consider certmonger for tracking cert expiration? This is exactly what it is designed for.
Will the "ldap_tls_reqcert = once" or "ldap_tls_reqcert = allow" options also be added to the "auth" kickstart option? It would be great to be able to do "auth --enableldapauth --ldap_tls_reqcert=once" within a kickstart script.