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