FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap

[Brandt Winchell]

Hello,
I have spent the last few days trying to figure out what can be done.

(in reference to fix the network)
The network is perfectly fine.  The AD replication topology is deliberately designed to be a hub-spoke.  172.16.80.0/24 hub site happens it can talk to all the other GCs by design.
172.16.99.0/24 is only designed to talk to 172.16.80.0/24 by design and security reasons.
So FreeRadius should not have or should have to talk any other GCs as there are 2 perfectly good GCs it is allowed to talk to.

(What I was able to find - Joe's comment about ldap query too broad)
I performed some ldapsearch tests with the same bind account FreeRadius is using (to verify creds).  When I run the search command to the base "dc=domain,dc=local", The results come back right away but I do reach a size limit an the end of the output.
When I run the same command but base "ou=users,dc=domain,dc=local", I get all the results of the OU and no size limit error/warning.
.
I played around with the ldap.conf file.  No matter what I set there seemed to make no difference.
.
When I played with the LDAP {} section of /etc/raddb/mods-available/ldap, I was able to get some results.
When I set the base_dn = 'DC=domain,DC=local' -> base_dn = 'OU=users,DC=domain,DC=local'
I get the search results back right away.
.
Now I cannot leave this setting as not all my users exists under that one OU.  That is just where the test account resides.
.
I have a feeling the rlm_ldap is reaching a limit with the size of the search but no matter what is set in ldap.conf makes no difference.  I see no option within the ldap{} module to set a size/time limit
Are there any more debug logs I can view during this process to validate it is a size limit?

Thanks
B

-----Original Message-----
From: Freeradius-Users <freeradius-users-bounces+brandt.winchell=thinkon.com at lists.freeradius.org> On Behalf Of Alan DeKok
Sent: August 10, 2020 1:45 PM
To: FreeRadius users mailing list <freeradius-users at lists.freeradius.org>
Subject: Re: FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap

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-f
> actor-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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html