[RADIATOR] ERR: AuthLDAP2 Could not open LDAP connection to AD domain controllers
Hirayama, Pat
phirayam at fredhutch.org
Fri Feb 26 21:25:26 UTC 2021
Thank you, Heikki. Would the same debugging configuration work for EAP TLS?
Thanks!
-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: Friday, February 26, 2021 02:04
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 25.1.2021 19.00, Hirayama, Pat wrote:
> Thank you for the tip about enabling TLS socket debugging using
>
> StartupHook sub { use IO::Socket::SSL qw(debug3); }
The latest updates to Radiator now have a new configuration parameter
for all LDAP clauses that can enable IO::Socket::SSL debugging without
StartupHook. It works for both direct LDAPS and LDAP with StartTLS. For
example:
<AuthBy LDAP2>
# Existing parameters
# Enable all available IO::Socket:SSL debugging
DebugTLS 3
# Possibly debug LDAP too
#Debug 255
# More parameters
</AuthBy>
Because this is an alternative method to enable IO::Socket::SSL
debugging, the debug messages are still written to STDERR. They can be
viewed directly from console or, for example on operating systems with
systemd, with the journalctl utility or from system log files.
The number is defined by IO::Socket::SSL and currently goes from 0 (off)
to 3 for the largest amount of information.
This will be part of the next release and it's already available in the
patch builds.
Please see below for an example of what IO::Socket::SSL logs when
debugging is enabled.
Thanks,
Heikki
> 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=
>
--
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=CoBUksxYSOqvRWlHfJn64sIAC1cP_eHQ1TH9QQcstxQ&s=qTx-NeoFXXK7p8uGGRqGdzC-SwjoBoyRh05MKuBz8pc&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20210226/0708a790/attachment.html>
More information about the radiator
mailing list