FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap

[Alan DeKok]

On Aug 14, 2020, at 2:39 PM, Brandt Winchell <brandt.winchell at thinkon.com> wrote:
> (in reference to fix the network)
> The network is perfectly fine.

  So... everything works, and you're not asking for any more help?

  Realistically, the network is not fine.  If it was fine, then FreeRADIUS would be able to talk to all GC servers.

  And I've never understood the reasoning behind people who ask questions and then argue with the answers.  If you know better than us, you don't need to ask questions.  And if you don't know better than us, it would be polite to learn from others.  As it stands now, you're just arguing for the sake of arguing.

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

  That's nice.

  Have you told AD about these restrictions?  i.e. does AD check the source network, and refer clients to *only* those GC servers which are reachable from that source network?

  Hint:  No.

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

  As I tried to explain, this isn't about FreeRADIUS.  The AD server is returning a referral to FreeRADIUS.  That referral is the DNS name of a GC server.  That DNS name resolves to an IP address which is unreachable from FreeRADIUS.

 You've split your network into multiple segments which can't talk to each other.  Then, you've made sure that AD doesn't know about this split.

  That's the problem.  It isn't difficult.  Your options for a solution are:

a) un-break your network so that each segment can talk to any GC server

b) fix AD so that it returns only reachable GC servers when queried from a segment.

  No amount of poking FreeRADIUS will fix this issue.  It isn't a FreeRADIUS problem.

> I have a feeling the rlm_ldap is reaching a limit with the size of the search

  Which is why it's getting a referral to a GC server which is unreachable.  Hmm... yes, that's it.

> 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?

  Why ask questions if you're going to argue with the answers?

  Why would we answer questions if you're doing to tell us that we're wrong?

  Alan DeKok.