[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: FreeRadius with Google PAM - Hardcode LDAP Servers for rlm_ldap
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2020-08-14 23:29:33
Message-ID: F76B8CC4-DB4A-4186-9417-125E6E71B00B () deployingradius ! com
[Download RAW message or body]

On Aug 14, 2020, at 2:39 PM, Brandt Winchell <brandt.winchell@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.


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


[prev in list] [next in list] [prev in thread] [next in thread]