Matching multiple LDAP-groups during post-auth

[Chris Wopat]

On Wed, May 19, 2021 at 4:39 PM Alan DeKok <aland at deployingradius.com> wrote:
>
>   libldap is using the horrible RedHat "NSS" library which pretends to be OpenSSL, and gets it wrong.  It might work, but it definitely won't work if you're doing EAP-TLS.

Fortunately it still does work (issues below aside). We'll see if that
continues? We're stuck with Centos for the moment, the fact that
Redhat killed Centos 8 prematurely (end of this year) may affect taht
decision. TBD, possibly for another time.


>          (1)     elsif (LDAP-Group == "optical-users")  -> FALSE
>         (1)     else {
>         (1)       update reply {
>         ((1)         Local-Reject-Check += "No matching optical"
>
>   The rules check for:
>
>         if member of network-admin
>                 ok
>         else
>                 reject
>
>         AND SEPARATELY
>
>         if member of optical-admin
>                 ok
>         else
>                 reject
>
>   The first test passes, the second doesn't.  That's why it's rejecting.
>
> > Here's the post-auth section, which I'm also posting in-line in this email.
>
>   The description you posted says that the user should match both a network group and an optical group.  That's what the rules do.
>
>   So the question is, what do you want it to do?  Write it down in plain english.  And it should then be possible to translate it to "unlang".

Yes exactly. We're looking to handle situations where:

1) A user may be a member of a single network-* and single optical-* group
2) A user may be a member of a single network-* group (and no optical-*)
3) A user may be a member of a single optical-* group (and no network-*)

1 works fine, 2 and 3 do not.

Re-reading my original message and a few follow ups
(http://lists.freeradius.org/pipermail/freeradius-users/2021-March/099660.html)
I can see that this is unclear.

It feels like there should be an easy way to nest or deal with this in
unlang with some basic if/else stuff but for whatever reason my brain
cannot come up with it. We would strongly prefer to not have to create
more new LDAP groups for this (ie ones that are called
network-and-optical-admins) or whatever, but i guess technically that
would be one workaround, but more confusing for those who admin LDAP
group membership.

Cheers,
Chris