Ping? -m On Sat, Dec 5, 2020 at 9:58 PM Matt Zagrabelny <mzagrabe@d.umn.edu> wrote:
Greetings FR-users!
I am having trouble getting FR to bind to LDAP (AD). I believe the issue is with TLS and the CA's, but I am not sure. Any help verifying the problem and finding a solution would be very appreciated.
Here's the version:
$ apt policy freeradius freeradius: Installed: 3.0.17+dfsg-1.1
According to package dependencies and readelf, FR is using libssl for crypto library needs:
$ readelf -d /usr/sbin/freeradius | grep ssl 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.1]
If I use openssl s_client and connect to the AD system without the CA for the AD system's cert, I get an error:
$ echo | openssl s_client -connect ad.umn.edu:636 | grep 'Verification: OK' depth=0 CN = dc-tc2.ad.umn.edu verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = dc-tc2.ad.umn.edu verify error:num=21:unable to verify the first certificate verify return:1 DONE
If I add the authority cert of our AD system to the system's list of CA certs...
$ sudo cp /path/to/cert /usr/local/share/ca-certificates/ad.umn.edu.crt $ sudo update-ca-certificates
...I do not get the error:
$ echo | openssl s_client -connect ad.umn.edu:636 | grep 'Verification: OK' depth=1 DC = edu, DC = umn, DC = ad, CN = OIT-CA1-ADRCA verify return:1 depth=0 CN = dc-tc1.ad.umn.edu verify return:1 Verification: OK DONE
Also, ldapsearch executes successfully when the authority cert is added to the ca-certificates for the system, but fails when the cert is not added to the ca-certificates. ldapsearch is linked against gnutls.
However, even with the cert added to the system list of ca-certificates, it appears FR (at least the LDAP component) is failing. Here is a snippet of "freeradius -X"
rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap): Connecting to ldaps://ad.umn.edu:636 TLS: can't connect: (unknown error code). rlm_ldap (ldap): Bind with CN=d-ins-ldapuser,OU=ServiceAccounts,OU=INS,OU=D,OU=Units,DC=ad,DC=umn,DC=edu to ldaps://ad.umn.edu:636 failed: Can't contact LDAP server
rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /etc/freeradius/3.0/mods-enabled/ldap[8]: Instantiation failed for module "ldap"
The file that the system CA certificates, and hence the AD certificate authority, reside in is:
/etc/ssl/certs/ca-certificates.crt
An strace of the FR shows that it is opening that file:
$ sudo strace -f /usr/sbin/freeradius 2>&1 | grep '^open' | grep ssl
openat(AT_FDCWD, "/usr/lib/freeradius/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3 openat(AT_FDCWD, "/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/ssl/certs/ssl-cert-snakeoil.pem", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 3 openat(AT_FDCWD, "/etc/ssl/private/ssl-cert-snakeoil.key", O_RDONLY) = 3
So... part of me thinks that TLS isn't having issues with the CA of the AD system.
I've tried increasing the debugging level with extra -x for freeradius, but the extra logs don't help me determine where the issue is with ldap.
What do folks think? This is my first foray into LDAP binding.
Thanks for any help!
-m
On Dec 8, 2020, at 8:33 AM, Matt Zagrabelny via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I am having trouble getting FR to bind to LDAP (AD). I believe the issue is with TLS and the CA's, but I am not sure. Any help verifying the problem and finding a solution would be very appreciated.
Here's the version:
None of that really matters.
$ echo | openssl s_client -connect ad.umn.edu:636 | grep 'Verification: OK' depth=1 DC = edu, DC = umn, DC = ad, CN = OIT-CA1-ADRCA verify return:1 depth=0 CN = dc-tc1.ad.umn.edu verify return:1 Verification: OK DONE
That's good.
Also, ldapsearch executes successfully when the authority cert is added to the ca-certificates for the system, but fails when the cert is not added to the ca-certificates. ldapsearch is linked against gnutls.
<sigh> RedHat idiocies. They've since switched back.
However, even with the cert added to the system list of ca-certificates, it appears FR (at least the LDAP component) is failing. Here is a snippet of "freeradius -X"
rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap): Connecting to ldaps://ad.umn.edu:636 TLS: can't connect: (unknown error code).
That seems definitive. The issue is RedHat. They've linked libldap against GNUTLS, which is *not* compatible with OpenSSL. FreeRADIUS tries to use OpenSSL, and then bad things happen. Drop the crappy RedHat packages, and go with working ones. See our web site for more details: https://networkradius.com/packages/ Alan DeKok.
On 12/8/20 2:41 PM, Alan DeKok wrote:
The issue is RedHat. They've linked libldap against GNUTLS, which is *not* compatible with OpenSSL.
Debian links libldap against GnuTLS. AFAIK RedHat never did this. RedHat/CentOS had libldap linked against libnss (Mozilla's crypto lib) until recently. They switched back to libldap linked against OpenSSL. Ciao, Michael.
On Dec 8, 2020, at 9:34 AM, Michael Ströder via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On 12/8/20 2:41 PM, Alan DeKok wrote:
The issue is RedHat. They've linked libldap against GNUTLS, which is *not* compatible with OpenSSL.
Debian links libldap against GnuTLS. AFAIK RedHat never did this.
RedHat/CentOS had libldap linked against libnss (Mozilla's crypto lib) until recently. They switched back to libldap linked against OpenSSL.
Ah yes. Similar, but different. Whether it's libnss or GNUTLS, the underlying issue is the same. Libraries which claim to be "compatible" but aren't. The fix is still the same tho. Use libraries which aren't broken. Alan DeKok.
participants (3)
-
Alan DeKok -
Matt Zagrabelny -
Michael Ströder