SOLVED Upgrade 11.2->11.3 broke my LDAP

[Fredda]

So I recently updated my testserver to the latest FreeNAS version 11.3-U3.2.
User authentification and mapping for NFS users is done via LDAP and this stopped working.

First problem, the certificate had been expired and the upgrade progress renamed it from cert to cert (migrated for ldap ....), which might sound like a good idea, but it looks like the nslcd can't handle such a name. Or FreeNAS should have put quotes around the name.
Updated the certificate and will probably file a bug report later.

Now at least the nslcd started, but user lookup still did not work.

Code:

[root@nas] /usr/local/etc# id user
id: user: no such user

In the log files it was complained about missing SASL mechanism and comparing the nslcd.conf file I found there was an additional line
in the config file: sasl_mech EXTERNAL

Unfortunately this seems not to be supported by my LDAP server:

Code:

ldapsearch -x -ZZ -LLL -s base -b "" supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN

I could resolve/workaround the issue by setting the encryption mode in the LDAP config to OFF or to manually remove the sasl_mech from
the nslcd.conf file and restart the nslcd.

I'd prefer the ldap accesses to be encrypted. Is there a proper way to archive that? Hacking a config file generated by the middleware does not feel so good.

 

[anodos]

Remove the certificate from the LDAP form and restart the LDAP service. All user-provided CACERTS are now placed in /etc/ssl/truenas_cacerts.pem, which is then used as the CACERT file in the ldap.conf.

 

[Fredda]

OK, I should have been more verbose, I already did that. The updated certificates are not created by FreeNAS
they were created externally und imported into FreeNAS. Also the public key of the CA was imported in to the
CAs section of FreeNAS, this is how the nslcd.conf looks like:

Code:

    uri     ldap://10.xx.xx.xx:389
    base     dc=yyy,dc=xxx,dc=com
    ssl     start_tls
    tls_cacert    /etc/ssl/truenas_cacerts.pem
    tls_cert    /etc/certificates/server_cert_2020.crt
    tls_key    /etc/certificates/server_cert_2020.key
    sasl_mech    EXTERNAL
    tls_reqcert allow
    nss_disable_enumeration yes
    scope     sub
    timelimit    10
    bind_timelimit 10
    map passwd loginShell /bin/sh

The server certifacates are not in the /etc/ssl/truenas_cacerts.pem file, they are located in the the tls_cert and tls_key files.
Only the public CA certificate is inside the truenas_cacerts.pem file.

As I said, the sasl_mech line seems to be the culprit, as it works when I remove the line. LDAP per se works,
e.g. ldapsearch -x -ZZ uid=user prints out the expected output, but I think the "-x" option disables SASL.

In the 11.2 version this line does not show and the ldap access works fine and is TLS encrypted.
So is there a way for the LDAP queries to be encrypted without editing the a middleware created config file or
changing the configuration of the LDAP server?

 

[Fredda]

Remove the certificate from the LDAP form and restart the LDAP service.

Thanks. Should have read better. That indeed did the trick. Instead of replacing the outdated certs I should have simply removed the cert from the dropdown. Now it works and network sniffing shows the LDAP traffic is encrypted.