On 12/2/2012 5:23 μμ, Michael Ströder wrote:
No! If one configures TLS support OpenLDAP must not start if any parameter has an invalid value. One could think about starting solely with LDAPI support to make back-config accessible.
Thanks Michael,
Let me ask, for clarification: If we have configured correctly TLS support, and yet we bind like: "ldapsearch -H ldap://" but not using -ZZ, this doesn't mean that we will have a simple non-encrypted connection? This means that the server offers this capability (unless ACLs prevent it, with the exception of - as I have seen - root). So, why not offer it if TLS is misconfigured? If client requires encryption, it could issue: "ldapsearch -H ldap:// -ZZ" or "ldapsearch -H ldaps://" which would fail if server does not offer TLS/SSL.
IMO your operational procedure should mandate that slapd has to be restarted to test if any parameter was changed which affects startup. Or better in your operational concept define a white-list of parameters allowed to be changed via back-config without restart.
Any starting point for creating such a white-list of parameters?
This ITS might also be interpreted that back-config should validate whether all the TLS-related files are actually readable. But this is tricky because slapd drops privileges after startup and at least the private key file is likely not be readable by the slapd demon user.
A question on this: If the private cert is owned by root:root (and OpenLDAP runs under ldap) (chmod 640 or 600 for security), my experience shows that OpenLDAP will not read them (in CentOS, it is usually in "/etc/pki/tls/private". So, I am using a copy of the private key, owned only by ldap user, to make it readable by OpenLDAP. Should/could I do something different?
Thanks again, Nick