Re: [EXT] Fetching memberOf attribute

3 Jun 2025

      Guys,

Thank you very much! Indeed, the mods-available/always was missing in the installation. I had to re-adjust the configuration to:

post-auth {

if (&control:ldap-LDAP-Group[*] == "CN=Radius_ReadOnly_Group,DC=Groups,DC=abc,DC=abc") {
                        update reply {
                                Fortinet-Group-Name := "ro_group"
                                Juniper-Local-User-Name := "ro_role"
                                Reply-Message := "Authorized as RO user"
                                }
                        update control {
                                Auth-Type := Accept
                                }
                        accept
                        }

if (&control:ldap-LDAP-Group[*] == "CN=Radius_ReadWrite_Group,DC=Groups,DC=abc,DC=abc") {
                        update reply {
                                Fortinet-Group-Name := "rw_group"
                                Juniper-Local-User-Name := "rw_role"
                                Reply-Message := "Authorized as RW user"
                                }
                        update control {
                                Auth-Type := Accept
                                }
                        accept
                        }

if (&control:ldap-LDAP-Group[*] == "CN=Radius_Admin_Group,DC=Groups,DC=abc,DC=abc") {
                        update reply {
                                Fortinet-Group-Name := "admin_group"
                                Juniper-Local-User-Name := "admin_role"
                                Reply-Message := "Authorized as Admin"
                                }
                        update control {
                                Auth-Type := Accept
                                }
                        accept
                        }
        update {
                reply:Reply-Message := "Unauthorized - No group found"
                control:Auth-Type := Reject
                }
        reject

        }
}

I just wanted to let you know that everything is now working as expected.

Best regards Matvey Teplov
+31 62 705 12 73

________________________________
From: Brian Julin <BJulin@clarku.edu>
Sent: 03 June 2025 16:14
To: Matvey Teplov <matvey.teplov@nomios.nl>; freeradius-users@lists.freeradius.org <freeradius-users@lists.freeradius.org>
Subject: Re: [EXT] Fetching memberOf attribute

Matvey Teplov <matvey.teplov@nomios.nl> wrote:
...
Picking this outstanding action. I tried "reject" before, and it is a problem. The startup comes with:
/etc/freeradius/3.0/sites-enabled/default[85]: Failed to find "reject" as a module or policy.
We have these defined in our config.  Maybe this is an obsolete way to reject things I do not know at this point:

modules {
  always fail {
    rcode = fail
  }

  always reject {
    rcode = reject
  }

  always handled {
    rcode = handled
  }

  always ok {
    rcode = ok
    simulcount = 0
    mpp = no
  }
}
...
Also, the simple '==' doesn't work either, and that's why the loop is there. It is coming back with during authentication:
(0)     if (&control:ldap-LDAP-Group[*] == "CN=Radius_ReadOnly_Group,DC=Groups,DC=abc,DC=abc") {
(0)     ERROR: Failed retrieving values required to evaluate condition
That's strange.  Either something with the version you are running, or maybe that statement is getting run over more than once, and sometimes the attribute is empty.  It can be difficult to run statements at the correct phase with all the encapsulation layers involved in EAP-PEAP.  The splat statement definitely works for us, but we do a lot of explicit cache handling.  Specifically we've defined this:

  cache {
    key = "%{User-Name}"
   # Just enough time to get us from autz to auth
    ttl = 15
    add_stats = "no"
    update {
      control:ldap-LDAP-Group := &control:ldap-LDAP-Group[*]
    }
  }

...and we always call "cache" before accessing the attribute.

We access it once in our Autz-Type for wifi, to deny password guessing attempts for certain accounts, and then in our Auth-Type for WiFi to do the actual group memberships.

...and then we have the EAP session resumption running another layer of caching on top of that so it's really quite an astounding pile of duct tape and bubblgum.  But that's EAP-PEAP for you.