Matching multiple LDAP-groups during post-auth

[Chris Wopat]

On Wed, Mar 31, 2021 at 7:04 AM Alan DeKok <aland at deployingradius.com> wrote:
>
> On Mar 31, 2021, at 7:42 AM, Chris Wopat <me at falz.net> wrote:
> >
> > .. there's 31 combinations of 5 items, meaning 31 IF statements, which
> > is unruly.
>
>   I'm not sure why you need those combinations.  Why not just:
>
> * do network layer
> AND
> * do optical layer?
>
>   Perhaps the rules really are "network 1 AND optical 1 gets A, network 1 AND optical 2 gets B", with A / B being completely different.  In that case, you really do need massive amounts of ANDs.
>
>   The general solution is to split your rules into independent sets, and then combine the sets.


We do this currently, but have an issue with having a reject at the
end of each, as it will reject users that are only a part of the 2nd
group.


> > Very helpful thank you. I haven't used "case" before- since it's in a
> > switch, in the link above, you mention " have to use the switch / case
> > structure since a user can be member of multiple groups". Does this
> > mean that the switch/case statement will update the reply for *all*
> > matching cases, not just the first hit?
>
>   It only uses the first one it finds.
>
>   Why not just do 3 IFs for network later, followed by 2 IFs for optical layer?
>
>   You can always add an extra "if" to catch the case of "no matching group was found".
>
>         if network 1
>                 update reply for network 1
>         else if network 2
>                 ...
>         else
>                 update reply with fake attribute saying "no match"
>
>         if optical 1
>                 update reply for optical 1
>         else if ...
>                 ...
>         else
>                 update reply with fake attribute saying "no match"
>
>         if reply has "no match"
>                 reject

This is very similar to what we're doing now, except your 'no match'
stuff, which may in fact be the actual fix.

To clarify, you're using some BS reply-item, which is in some vendor
dictionary just to store this variable string, then comparing that at
the end? In theory this sounds like it would resolve this for us.

Looking at the dictionary file, it says to use between 3000 and 4000
for local attributes, perhaps just plopping something like this in
that file would work?

  ATTRIBUTE      Local-Reject-Check         3000    string

OR perhaps as an int:

  ATTRIBUTE      Local-Reject-Check         3000    integer


What we have now is:

network:
  if / elsif / elsif / (no reject currently, or it wouldn't make it to
the optical check if not in network group)

optical:
  if / elsif / else reject


The solution you list seems sane on paper, we hadn't thought about
using a reply item to store a variable for a later check, but assuming
that's all possible, I think this is our winner.

--Chris