[EXT] Fetching memberOf attribute

[Brian Julin]

Matvey Teplov <matvey.teplov at 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.