OpenLDAP server enable TLSv1.0

Hello,

I am migrating from NIS to LDAP; therefore, I installed OpenLDAP on a Rocky Linux 9.2 server. Most of the more recent clients are easy to migrate, thanks to SSSD. However, I must migrate some older clients (like Red Hat Enterprise Linux 4). I could not connect these clients to the OpenLDAP server via an encrypted connection. Apparently, they do not support TLSv1.3 and TLSv1.2 but only TLSv1.0 (at least, that showed up when I looked at some captured traffic).

This leads to my Question: How can I enable TLSv1.0 on my OpenLDAP server running on Rocky Linux 9.2?

I already tried to set update-crypto-policies –set LEGACY, and set in the OpenLDAP configuration TLSProtocolMin to 3.1. But nothing enabled TLSv1.0.

INFO: I know TLSv1.0 is deprecated and by no means save anymore, never the less I would rather use TLSv1.0 than no encryption at all. Moreover, updating these clients currently or in the near future is impossible.

Thank you very much for your help!

ldap services maps via NSS rather than SSSD relies on nscd to cache the entries.
nscd on earlier rhels was temperamental and needed regular restarting.
without nscd there will be long delays when looking up anything, and in case you dont know these lookups are going on all the time, just an ls of a file with a group perm in ldap will cause a lookup, and if not cached a long delay in a simple ls.
sssd is engineered from the outset to fix this with much better caching.
If I were you I would install a ldap to nis gateway, that builds the nis maps from ldap, and install nis slaves bound to the master on every rhel4,5,6 system.
update the slaves overnight with a cronjob with a randomised delay to its startup to spread the load on the nis master.
that way each server will have its own nis-slave which acts like a cache and wont need nscd at all (which is a troublesome beast at the best of times), and then move all your newer systems, ie rhel7 and above to use ldap.
Im guessing those legacy and unsupported systems are low in numbers hence why i make this recommendation.
regards peter

TLS 1.0 is disabled completely in all crypto policies for 9, this includes for legacy. You will not be able to use 1.0 on Rocky Linux 9 when using the default system-wide cryptographic policies.

You can try to create custome sub policies to enable TLS 1.0. But this may or may not work for you.

Completely, as in not built and included in the binaries, or something to that effect.

I totally failed to connect to local “eduroam” WiFi with el9 due to that.
All I got by tinkering policies was “unsupported protocol” error.

Part of that is – I guess – due to el9 having openssl 3, while el8 still has 1.1.1*.
There is no point to include in openssl 3 any legacy, unsupported, and vulnerable code.


Wow, that is – let me check Red Hat Enterprise Linux Retired Life Cycle Dates - Red Hat Customer Portal
oh, RH declared RHEL 4 dead no earlier than May 18, 2022. 17+ years is respectable. :nerd_face:

I have already migrated some older clients. Some used nscd (around CentOS 6) and some did not. However, I have not noticed any major delays without the use of nscd. How it behaves in the long run, we will see…
Nevertheless, the approach of using something like an NIS gateway is interesting, and I may try to fiddle around with it.

A whole different approach that I’ve used on small scale and might not apply at all
was to create local config with Ansible. Rather than query LDAP/NIS for data, have it local.
(Granted, it was a cluster and users would authenticate with ssh keys – no passwords set by me.)

The good part is that “everything” is local and does not need cache, like nscd.
The bad part is that configuration management (Ansible) has to run frequently, to propagate changes.

The worst part is that the Ansible in el9 (package ‘ansible-core’) is a Python application that
no longer supports python versions that are older than the 2.7 that is in el7.
One can get around that by running ansible 2.9 on el7 host, although there are limits on how old clients even that version can handle. Ansible is not the only such tool though.

Thanks for the tip.
I tried to create a custom sub policy to enable TLSv1.0. However this did not change a thing. I suspect that in OpenSSL 3.x TLS version < TLSv1.2 are either removed, or OpenSSL is not built with support for these versions as @jlehtone said.

For a small number of clients, with only local users, this would be a fairly simple solution. I think for a cluster where you know your nodes are up, you probably don’t even need to use Ansible, just a script that uses scp to propagate changes would do.
Unfortunately, this wouldn’t work for us as we use Pass-Through Authentication, which is possible with OpenLDAP (I’ve just realised that’s why the NIS gateway suggestion doesn’t work either).

1 Like

How about LDAP server on el8 host?

That is a really good idea. I did not even think about using el8 at that time.
It shouldn’t be too complicated to migrate the OpenLDAP installation to another system as long as the OpenLDAP versions match.
I will take this solution into consideration; thank you very much.

Currently, in my opinion, there are two possible options:

  1. Since Roky Linux 9 does not support TLS versions older than 1.2, use Roky Linux 8.x as @jlehtone suggested, and migrate the data.
  2. The older clients do not use encryption and are (hopefully) replaced pretty soon.

Regarding the first option: The OpenLDAP versions do not match, which would mean, in the worst case, I have to use a small program or script to transfer the data between the servers.

Nevertheless, thank you all very much for your help :slight_smile:

I had – a long time ago – NIS. Then moved to openldap. Later did add Kerberos next to it for authentication. Eventually the openldap server was on el6. That got near its EOL, so next host was to be el8. (Clients were mainly sssd on el7.) Alas, Red Hat deprecated openldap-server, so option was either to trust that openldap-server stays in the picture, or try something “in the box”. Namely, the dirsrv (aka 389ds). The schema and ACL’s did differ a bit between openldap of el6 and 389ds of el8, but nothing major. Slapcat → sed → 389ds. The server remains on el8, while clients are now el9.

Ok, that was not about the version (and 389ds versions of el8 and el9 are different too). A question, can openldap replicate with different version of the server? To keep the main database on el9, but replicate to el8 “proxy” that would serve the “old guard” until they retire. (Quick websearch – very old discussions – said: “maybe”.)

At some point I also considered using 389 Directory Server. But as far as I know, 389DS does not have a feature like OpenLDAP’s pass-through authentication, so I would have to synchronise passwords to the OpenLDAP server.

I trust that the OpenLDAP server will remain available for Roky Linux. Fortunately, OpenLDAP is widely available or can be built from source fairly easily.

I think it is not even necessary to deal with the problem of version differences. I just need to use something like a reverse proxy or gateway that still supports TLSv1.0 and redirects the request to the OpenLDAP server.