"redundant" block works in "default" virtual server, but does not work in "inner-tunnel"

[Alan DeKok]

On Mar 5, 2022, at 10:55 AM, Rahman Duran <rahman.duran at erzurum.edu.tr> wrote:
> 
> Why try to do things this complex? I am trying to do things more granulary
> but maybe I am overthinking it. I want to log more details about why
> rejecting request. I want to reject when the auth source should not find
> user so it should not go on remaining sections. I see I can not use unlang
> and config sections of freeradius like a scripting/programming language.

  Unlang is *somewhat* like a programming language.  But it's designed to make most RADIUS policies very simple.  The downside is that if you're doing something very unusual, it can be hard to do in unlang.

  But then again, complex things are hard to do in any language.

> We one one LDAP server but multiple types of accounts in "separate" ldap
> subtrees. So I do not use root LDAP tree but define multiple LDAP instances
> for these account types. All the accounts have the same "domain name" (but
> unique username part), not by my choice but this is how it is.

  It's really a terrible way to design an LDAP tree.

  If all of the usernames are unique, then why not maintain a "username to subtree" mapping?  That way you look up the user once, get the subtree, and you know exactly what to do.

  Again, the process of "try this, oops it didn't work, try something else" is fragile, slow, complex, and just terrible design.

> I am trying to configure Freeradius in a way so I use it as our central NAC
> appliance. We will use it for policing all our wired/wireless networks
> with different levels of access for different users (all have the same
> domain names), groups etc. Only getting Access-Accept or Access-Reject
> reply is not enough for us, I want to log, which service rule the request
> matched, is it rejected because of a wrong password or because of a non
> existing username.

  That's a separate problem.

  Fix the horrible use of subtrees first.  Once that's done, everything else is trivial.

> I read all the documentation already but I admit I could misunderstand
> some, like "redundant" usage. As far as I see there is no direct way to
> make Freeradius to stop trying the next ldap module in a subsection (a
> group), if the previous one found a user.

  Read the debug output.  See what the ldap module returns (ok / fail / etc.).  Then write an "if" condition to check for that.  All of this is documented.

> For my usage it is ok to go on
> searching for users in the following ldap modules but I should avoid it if
> I can, as it will be a waste of resources.

  Or, fix the lookup so you:

a) look up the unique username

b) get a subtree

c) use that subtree to check the users password

d) profit

  You're trying to put together some horribly complex solution because of a complex LDAP structure.  That's bad.  Instead, you should *simplify* the LDAP structure.  The solution will then also be simple.

  Alan DeKok.