FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap

[Alan DeKok]

On Aug 10, 2020, at 12:04 PM, Brandt Winchell <brandt.winchell at thinkon.com> wrote:
> I have an issue which I am sure is easy to fix but I cannot find the correct file/setting.  Let me explain:
> 
> Environment:
> Active Directory - backend authentication.  The AD environment is setup as a hub & spoke design.  This means not all domain controllers (GC) are accessible from everywhere (by design & security)
> Freeradius - CentOS7 server FreeRadius-3.0.13

  Updated packages are available from http://packages.networkradius.co,

> Source Setup:
> It is basically a setup following this site:
> https://kb.hillstonenet.com/en/wp-content/uploads/2019/09/SSLVPN-Two-factor-Authentication-with-Google-Authenticator.pdf

  OK..

> Issue:
> When I have the FreeRadius server in subnet80 (172.16.80.0/24 hub site and can talk to any GC server), the configuration works fine.  So I know the basic configurations are working as designed.
> When I move the FreeRadius server into subnet 99 (172.16.99.0/24 restricted site that can only talk to 172.16.80.0/24), radius fails to get any results from GC servers.  There is a firewall between these subnets.

  So... you put a firewall between FreeRADIUS and LDAP, which prevents them from communicating.

  The short answer is "don't do that".

> I have configured the following files to specify which GC servers FreeRadius should use:
> /etc/raddb/mods-available/ldap
>                ldap {
>                               server = 'dc01.domain.local'
>                               server = 'dc02.domain.local'

  That's nice, except that the LDAP servers don't know which ones are reachable from where.  So they might give FreeRADIUS an LDAP redirect, to an LDAP server it can't reach.

> When I run "radiusd -CX".  I get an ready to process requests for configuration check.

  Because it doesn't try to open connections to the LDAP server.

> When I run "radiusd -X", this is the where the process fails/hangs:
> rlm_ldap (ldap): Connecting to ldap://dc01.domain.local:389 ldap://dc02.domain.local:389
> rlm_ldap (ldap): Waiting for bind result...
> rlm_ldap (ldap): Bind successful

  Which means that FreeRADIUS can talk to dc02.domain.local.

> rlm_ldap (ldap): Reserved connection (5)
> (0)     EXPAND (userPrincipalName=%{%{Stripped-User-Name}:-%{User-Name}})
> (0)        --> (userPrincipalName=user1 at domain.local)
> (0)     Performing search in "DC=domain,DC=local" with filter "(userPrincipalName=user1 at domain.local)", scope "sub"
> (0)     Waiting for search result...
> 
> This will sit there until the LDAP search times out.

  Because the LDAP server it's trying to talk to is unreachable.

> When I perform a packet capture during this time, what I see:
> 1 radius performs a DNS query for forestdnszones.domain.local SOA dc01.domain.local

  Because dc02.domain.local is giving an LDAP redirect to forestdnszones.domain.local.  And forestdnszones.domain.local  isn't reachable.

> 2 dns server responds with records of ALL GC servers
> 3 radius then tries to connect to a GC server it does not have access to (due to the security restrictions)

  Exactly.

> Resolution:
> It seems that the FreeRadius LDAP module is trying to find the SRV record for LDAP.  Of course DNS responds with all LDAP SRV records.
> What I need to be able to do is restrict what LDAP servers FreeRadius is trying to use.  This seems very similar to SSSD Service Discovery.

  The short answer here is "don't break your network".

  Either make sure that all GC servers are reachable from FreeRADIUS, *or* make sure that the GC servers know about the network topology.  i.e. the GC servers don't give redirects to ones which are unreachable.

  The longer answer is that FreeRADIUS doesn't implement LDAP itself.  It uses the OpenLDAP client library to implement LDAP.  And it's not trivial to "filter" those redirects.

  And even if it could filter those redirects, what would it do?  If the GC returns "talk to forestdnszones.domain.local", what should FreeRADIUS do?  Ignore it?  Connect instead to some random other LDAP server?

  The solution here isn't poking FreeRADIUS, unfortunately.  The solution is fixing your network so that it isn't broken.

  Alan DeKok.