Ability to disable SSL certificate checking for LDAPS (636)?
We're rebuilding some radius servers from Centos 7 to Ubuntu 22, due to the Centos 8 debacle. Both are 3.0.x. We ported our config over, which uses LDAPS:// on 636 on a Microsoft Windows 2022 AD server. We do not want to use TLS on 389. Something seems different behaviourally between the servers, the new Ubuntu server (FreeRADIUS 3.0.26) appears to be attempting to validate the certificate much more heavily. This must be an AD thing, but we get this stuff about "DomainDnsZones" and "ForestDnsZones" when we attempt to authenticate, and it hence fails. The bind is successful and omitted below: ======================================== TLS: hostname (ForestDnsZones.ad.MYDOMAIN.net) does not match common name in certificate (ad.MYDOMAIN.net). TLS: can't connect: (unknown error code). Unable to chase referral "ldaps://ForestDnsZones.ad.MYDOMAIN.net/DC=ForestDnsZones,DC=ad,DC=MYDOMAIN,DC=net" (-1: Can't contact LDAP server) TLS: hostname (DomainDnsZones.ad.MYDOMAIN.net) does not match common name in certificate (ad.MYDOMAIN.net). TLS: can't connect: (unknown error code). Unable to chase referral "ldaps://DomainDnsZones.ad.MYDOMAIN.net/DC=DomainDnsZones,DC=ad,DC=MYDOMAIN,DC=net" (-1: Can't contact LDAP server) ======================================== While debugging I saw somewhere that Centos OpenSSL may be compiled or configured differently than Ubuntu, and perhaps that's why.
From our ldap conf: server = "ldaps://ad.MYDOMAIN.net" port = 636 identity = "CN=freeradius,OU=Applications,DC=ad,DC=MYDOMAIN,DC=net" password = <> base_dn = "DC=ad,DC=MYDOMAIN,DC=net"
options { chase_referrals = yes #chase_referrals = no } tls { ca_file = ${certdir}/DigiCertGlobalRootG2.crt.pem start_tls = no } Seeing if any options exist outside of regenerating/re-issueing / re-installing this cerficate, adding "DomainDnsZones" and "ForestDnsZones" to it? I can't find any docs for this, but is there any type of "don't validate" flag? I've set chase_referrals to no, and it still won't work (but it doesn't give the above error). Cheers Chris
On Apr 25, 2024, at 2:17 PM, Chris Wopat <me@falz.net> wrote:
We're rebuilding some radius servers from Centos 7 to Ubuntu 22, due to the Centos 8 debacle.
Both are 3.0.x. We ported our config over, which uses LDAPS:// on 636 on a Microsoft Windows 2022 AD server. We do not want to use TLS on 389.
Many other things have changed between CentOS7 and Ubuntu 22. The most important being OpenSSL. CentOS7 installs OpenSSL 1.0 by default, which is very very old. Ubuntu 22 installs a much newer version. Newer versions of OpenSSL do much more stringent certificate checks.
Something seems different behaviourally between the servers, the new Ubuntu server (FreeRADIUS 3.0.26) appears to be attempting to validate the certificate much more heavily.
Yes. That's OpenSSL.
This must be an AD thing, but we get this stuff about "DomainDnsZones" and "ForestDnsZones" when we attempt to authenticate, and it hence fails. The bind is successful and omitted below:
DomainDnsZones and ForestDnsZones are all Active Directory things.
========================================
TLS: hostname (ForestDnsZones.ad.MYDOMAIN.net) does not match common name in certificate (ad.MYDOMAIN.net). TLS: can't connect: (unknown error code). Unable to chase referral "ldaps://ForestDnsZones.ad.MYDOMAIN.net/DC=ForestDnsZones,DC=ad,DC=MYDOMAIN,DC=net" (-1: Can't contact LDAP server)
TLS: hostname (DomainDnsZones.ad.MYDOMAIN.net) does not match common name in certificate (ad.MYDOMAIN.net).
That should be fixed. The TLS certificate is wrong. Either the referral should be to ad.MYDOMAIN.net, or the TLS certificate should contain the same name as the referring hostname: DomainDnsZones.ad.MYDOMAIN.net i.e. this isn't a FreeRADIUS issue. The TLS configuration on Active Directory is wrong.
Seeing if any options exist outside of regenerating/re-issueing / re-installing this cerficate, adding "DomainDnsZones" and "ForestDnsZones" to it?
I can't find any docs for this, but is there any type of "don't validate" flag? I've set chase_referrals to no, and it still won't work (but it doesn't give the above error).
There's no option in the LDAP module to disable certificate checks. That's generally a bad idea. :( Alan DeKok.
Indeed the way that AD works can be a bit of a mystery. I walked back my troubleshooting to just do unencrypted 389 LDAP non-tls non-ssl and well, I must have another issue. Somehow LDAP isn't expanding to actually search for the user? (0) Received Access-Request Id 8 from 10.189.5.22:1645 to 10.213.15.19:1812 length 69 (0) User-Name = "MYUSER" <snip> (0) suffix: No '@' in User-Name = "MYUSER", looking up realm NULL (0) suffix: No such realm "NULL" <snip> (0) ldap: EXPAND (sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}}) (0) ldap: --> (sAMAccountname=) <snip> It seems like that last part: ldap: --> (sAMAccountname=) should include the username such as: ldap: --> (sAMAccountname=MYUSER) from my mods-enabled/ldap, for testing I have a really basic filter right now, but I've also tried the recommended one for AD in the comments: ldap { user_dn = "LDAP-UserDn" user { base_dn = "${..base_dn}" filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})" sasl { } } Someone hit me with the clue-bat as to how possibly this is disappearing somehow when it gets to LDAP search? I also confirmed with wireshark that it's omitting the username from the search. %{%{Stripped-User-Name}:-%{User-Name}}
On Apr 25, 2024, at 3:55 PM, Chris Wopat <me@falz.net> wrote:
I walked back my troubleshooting to just do unencrypted 389 LDAP non-tls non-ssl and well, I must have another issue. Somehow LDAP isn't expanding to actually search for the user?
That's odd.
(0) Received Access-Request Id 8 from 10.189.5.22:1645 to 10.213.15.19:1812 length 69 (0) User-Name = "MYUSER" <snip> (0) suffix: No '@' in User-Name = "MYUSER", looking up realm NULL (0) suffix: No such realm "NULL" <snip> (0) ldap: EXPAND (sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}}) (0) ldap: --> (sAMAccountname=) <snip>
It should print out the strings it's expanding. i.e. %{Stripped-User-Name} --> "" So something odd is going on. Which version are you running? Alan DeKok.
On Thu, Apr 25, 2024 at 3:40 PM Alan DeKok <aland@deployingradius.com> wrote:
It should print out the strings it's expanding. i.e. %{Stripped-User-Name} --> ""
So something odd is going on. Which version are you running?
3.0.26, which appears to be the current package on Ubuntu 22. I'm going to revert the config back to defaults and do more testing, I'd have to imagine it's something in my config, although it was copied bit by bit from the functional old Centos old server, which was 3.0.13. --Chris
We were able to get this working, Somehow one of the vendor specific dictionaries we have, that was copied over from old server, had some weird stuff in it: VENDOR Infinera 21296 BEGIN-VENDOR Infinera ATTRIBUTE User-Name 1 string ATTRIBUTE User-Password 2 string encrypt=1 ATTRIBUTE Reply-Message 18 string Why were those 3 attributes in the vendor definition? I have no idea, but they were. This version has a default 'dictionary.infinera' in /usr/share, the old one didn't. I commented them out from that vendor definition. I commented out those attributes from here (they're global, right?) and it all worked, including LDAPS. What I believe was happening with my original issue was 1) the username wasn't actually passed to the LDAP query 2) AD did some 'referral' thing searching for those 'DomainDNSZones' server 3) That failed the SSL cert check since they're not in the name since step 1 is now fixed, it doesn't do the step 2 "extra referral" check on weird domain names. Sorry for the noise. --Chris
On 26/04/2024 12:46, Chris Wopat wrote:
3.0.26, which appears to be the current package on Ubuntu 22.
You may find it worthwhile to use the Network RADIUS provided packages - https://packages.networkradius.com/ - and move to version 3.2.3 The 3.0 branch is now feature fixed and only receiving bug fixes. 3.2 is configuration compatible with 3.0 but has a number of enhancements. -- Nick Porter
On Fri, Apr 26, 2024 at 9:54 AM Nick Porter <nick@portercomputing.co.uk> wrote:
You may find it worthwhile to use the Network RADIUS provided packages - https://packages.networkradius.com/ - and move to version 3.2.3
The 3.0 branch is now feature fixed and only receiving bug fixes.
3.2 is configuration compatible with 3.0 but has a number of enhancements.
I had no idea there were packages provided for 3.2 - thanks! Will eyeball this.
participants (3)
-
Alan DeKok -
Chris Wopat -
Nick Porter