yast / yast-auth-server

GNU General Public License v2.0
5 stars 9 forks source link

ldap.conf configuration and location for Kerberos Instance #60

Closed ersaxp closed 4 years ago

ersaxp commented 4 years ago

I don't believe the issue lies with this module, but the installation of a new Kerberos Instance appears to rely on the proper configuration of the OpenLDAP client, specifically making sure that secure ldap is configured in /etc/openldap/ldap.conf:

uri ldaps://ldap.example.com:636/ base dc=example,dc=com timelimit 30 tls_reqcert allow

Without the above configuration, the Kerberos Instance form fails with a SASL Simple Bind error in the installation log.

Configuring the file through "YaST2 -> Network Services -> LDAP and Kerberos Client" does not work; it configures the file, /etc/ldap.conf, which in my testing is not referenced by openldap, and not consequently referenced during the Kerberos Instance installation. I'm making this note as a reference. Please forward this to the appropriate team responsible for the LDAP and Kerberos Client setup under Yast.

Firstyear commented 4 years ago

Looking at the code, it looks like this always expects ldaps to the server, so the ldap.conf setting here that actually matters is "tls_reqcert allow": from the ldap.conf page:

              allow  The  server  certificate  is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally.

This is actually because ldapclient is extremely bad at communicating what went wrong. Almost every failure looks like a bind failure, including a certificate verification error. Like, seriously, look at this:

# ldapwhoami -H ldaps://nonexist.ldap.com
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
# ldapwhoami -H ldaps://ad.blackhats.net.au    <-- this is a real server
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
#  ldapwhoami -H ldaps://ad.blackhats.net.au:389  <<-- wrong port
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

I'm not even sure where to to start on this - the entire ecosystem of LDAP has spent years neglecting communication of clear actionable errors to clients and users, and I think this kind of thing goes so deep that it's not possible for us to resolve. This will be the ruby LDAPClient library that is reporting the status from the openldap client library here. I do not believe this is possible to fix ....