[RADIATOR] ERR: AuthLDAP2 Could not open LDAP connection to AD domain controllers

[Hirayama, Pat]

Hi Heikki,

Thank you for the tip about enabling TLS socket debugging using

 StartupHook sub { use IO::Socket::SSL qw(debug3); }

This allowed me to see that the reason why my connections were failing despite having what appeared to be the correct SSLCiphers line was that the key specified in SSLCAClientKey didn't match the certificate specified in SSLCAClientCert!

Thanks again!

                          -p

--
Pat Hirayama
Systems Engineer | CIT / Systems Engineering | 206.667.4856 | phirayam at fredhutch.org<mailto:phirayam at fredhutch.org> | Fred Hutch | Cures Start Here
________________________________
From: radiator <radiator-bounces at lists.open.com.au> on behalf of Heikki Vatiainen <hvn at open.com.au>
Sent: Thursday, January 21, 2021 05:28
To: radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] ERR: AuthLDAP2 Could not open LDAP connection to AD domain controllers

On 20.1.2021 20.49, Hirayama, Pat wrote:

> Thank you for taking a look.  The TLS setting is certainly suggestive --
> and would explain why it works fine on CentOS 6 and not on Ubuntu 20.  I
> actually got it working with Radiator 4.12 on CentOS 8 -- which is why
> the increased security stance on Ubuntu 20 looks like a promising avenue
> to investigate.  Unfortunately, none of the suggestions at those links
> has gotten it working yet.

Here's what I found out: when I set up an LDAP listener with only TLSv1
enabled, a connection attempt from Radiator on Ubuntu 20.04 fails
similar to what you saw.

Enabling TLS debug for Net::LDAP required loading TLS socket support
with debug enabled in Radiator configuration. To do this, add the
following somewhere near Radiator's configuration file:

    StartupHook sub { use IO::Socket::SSL qw(debug3); }

I then started Radiator's radiusd directly from command line so that it
stays on the foreground. This also allows LDAP and TLS socket debugging
to be logged on the terminal too.

% /opt/radiator/radiator/radiusd -trace 4 -foreground -log_stdout
-log_dir . -db_dir . -config ldap.cfg

Below is a snippet from terminal log. The first and the last line are
Radiator's logging. The log in between comes from the TLS socket module
IO::Socket::SSL. The log shows that TLS handshake starts but doesn't
succeed because of TLS version problem.

Test was done with Radiator on Ubuntu 20.04. SECLEVEL extra parameter
was not set.

If this is set in Radiator's configuration: 'SSLCiphers
DEFAULT at SECLEVEL=1', then TLS handshake succeeds and LDAP can start.

The remote end is RHEL 7 with TLS listener forced to TLSv1.0 only. In
your case it may also be something else than TLS version, but the debug
should show how far it gets. Please let us know how it goes.

00000000 Thu Jan 21 13:15:29 2021 621281: INFO: AuthLDAP2 Connecting to
172.16.172.49 port 636
DEBUG: .../IO/Socket/SSL.pm:3010: new ctx 94622568855936
DEBUG: .../IO/Socket/SSL.pm:762: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:1177: global error: Undefined SSL object
DEBUG: .../IO/Socket/SSL.pm:1177: global error: Undefined SSL object
DEBUG: .../IO/Socket/SSL.pm:764: socket connected
DEBUG: .../IO/Socket/SSL.pm:787: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:832: not using SNI because hostname is unknown
DEBUG: .../IO/Socket/SSL.pm:864: request OCSP stapling
DEBUG: .../IO/Socket/SSL.pm:880: set socket to non-blocking to enforce
timeout=10
DEBUG: .../IO/Socket/SSL.pm:894: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:897: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:907: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:917: waiting for fd to become ready: SSL
wants a read first
DEBUG: .../IO/Socket/SSL.pm:937: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:894: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:897: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:900: SSL connect attempt failed

DEBUG: .../IO/Socket/SSL.pm:900: local error: SSL connect attempt failed
error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol
DEBUG: .../IO/Socket/SSL.pm:903: fatal SSL error: SSL connect attempt
failed error:1425F102:SSL routines:ssl_choose_client_version:unsupported
protocol
DEBUG: ...5.30/IO/Socket.pm:48: ignoring less severe local error
'IO::Socket::IP configuration failed', keep 'SSL connect attempt failed
error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol'
DEBUG: .../IO/Socket/SSL.pm:3059: free ctx 94622568855936
open=94622568855936
DEBUG: .../IO/Socket/SSL.pm:3063: free ctx 94622568855936 callback
DEBUG: .../IO/Socket/SSL.pm:3070: OK free ctx 94622568855936
00000000 Thu Jan 21 13:15:29 2021 656392: ERR: AuthLDAP2 Could not open
LDAP connection to 172.16.172.49 port 636. Backing off for 600 seconds.


--
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.
_______________________________________________
radiator mailing list
radiator at lists.open.com.au
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.open.com.au_mailman_listinfo_radiator&d=DwIF-g&c=eRAMFD45gAfqt84VtBcfhQ&r=lnQBMkNb1mBsioi6aP6ts4Sw0Ua5nVh4esYOAh4qTKU&m=Rn9JQSe7254zREmYjGKUQ9iR-NhQ84xz_wMYB0MEjxY&s=Y5A1RRCSLR8k8nZ196pTjcSajglGckvp2uD9CRk9Ufg&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20210125/928f26b5/attachment.html>