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

List:       freeradius-users
Subject:    Re: ldap redundant-load-balance sanity check and questions
From:       Brantley Padgett via Freeradius-Users <freeradius-users () lists ! freeradius ! org>
Date:       2022-10-12 18:58:53
Message-ID: 903045432.997839.1665601133423 () mail ! yahoo ! com
[Download RAW message or body]

> These are being added to the "control" list.

I did not realize that was significant, but it does make sense. 

Changing the if test to &control:LDAP-test still bypassed the if condition. I finally \
re-read Arran's last comment to his answer on that SO question. Changing the if \
condition to if (&control:LDAP-test[*] == "[groupname]") successfully pulls back the \
group membership. 

Again, thank you Alan, Nick and Arran!


Brantley Padgett 

The question is not how far. The question is, 
do you possess the constitution, 
the depth of faith, to go as far as is needed? 
            -Boondock Saints






On Wednesday, October 12, 2022, 10:36:06 AM CDT, Alan DeKok \
<aland@deployingradius.com> wrote: 





On Oct 12, 2022, at 10:11 AM, Brantley Padgett via Freeradius-Users \
<freeradius-users@lists.freeradius.org> wrote:
> I tried going that route but wasn't able to get the groups to return for the \
> post-auth. Trying again just now, I added in the ldap_server_info common file:

  I recommend a careful reading of the debug output/

> cacheable_name = 'yes'
> cache_attribute = 'LDAP-test'
> 
> then in default I changed the first if test to be
> 
> if (&LDAP-test == "group1") {

  Just the name, which means that by default it's looking in the "request" list.

> Running freeradius -Xx I see it adding the groups to "LDAP-test":
> 
> Wed Oct 12 08:34:26 2022 : Debug: (0) server2: Adding cacheable group object \
> memberships Wed Oct 12 08:34:26 2022 : Debug: (0) server2: &control:LDAP-test += \
> "group1" Wed Oct 12 08:34:26 2022 : Debug: (0) server2: &control:LDAP-test += \
> "somegroup2" Wed Oct 12 08:34:26 2022 : Debug: (0) server2: &control:LDAP-test += \
> "somegroup"

  These are being added to the "control" list.

  See "man unlang"

> [...]
> Wed Oct 12 08:34:26 2022 : Debug: (0) server2: Processing user attributes
> 
> But it errors trying to return the cached name, or at least that's how I understood \
> it:

  No, it errors *finding* the cached name.  Details matter.

> Wed Oct 12 08:34:26 2022 : Debug: (0) post-auth {
> Wed Oct 12 08:34:26 2022 : Debug: (0) if (&LDAP-test == "group1") {
> Wed Oct 12 08:34:26 2022 : ERROR: (0) Failed retrieving values required to evaluate \
> condition 
> I tried to follow the suggestions in this \
> https://stackoverflow.com/questions/58187426/freeradius-problem-with-redundant-load-balance-ldap-group \
> answer, but wasn't sure where the update call needed to go.

  

> I've tried putting in default, this for ldap in the authorize stanza:
> redundant_ldap
> if ((ok || updated) && User-Password && !control:Auth-Type) {
> update control {
> &Auth-Type := LDAP
> }
> update session-state {
> &LDAP-test += &LDAP-test[*]

  Again

    &control:LDAP-Test

versus

    &LDAP-Test.

  They're different.  You can't just assume that the server does what you want, even \
when you tell it to do different things.

  Alan eEKok.

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


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