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