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

[Rahman Duran]

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.

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. Some of our
WiFi SSIDs are for everyone, So my custom service should use multiple auth
sources, else, I would need to create multiple services for the same SSID,
per auth source, which I try to avoid.

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.

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. 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.

Sorry for the long reply.

Regards

Rahman Duran


That is completely the wrong approach.  It's a very bad idea to try many
different things, and then pick the one which succeeds.   Instead, you
should figure out where the users' data is located, and then use that.

  i.e. qualify the user names with different domains "user at example.com"
versus "user at example.org".  This is a practice going back 20+ years.

  Where you can't do that, find some other method to distinguish users.
i.e. users coming from NAS1 are for ISP1 and database1, while users coming
from NAS2 are for ISP2 and database2.

  Or maybe look at MAC addresses, and associate user accounts with MAC
addresses.  So that when a user logs in, the combination of "user + MAC" is
unique.

  The absolute worst thing you can do is to randomly try a bunch of
databases, hoping that perhaps one will succeed.

  But since you didn't post the *full* debug output (which contains name,
MAC, etc.), I can't offer any more specific advice.

> The problem is testing for "ok", "noop", "notfound" etc with a following
> unlang if condition is not working as expected everywhere.

  It works as *documented*.  If your expectations are different from how it
works, then read the documentation and debug mode to see how it really
works.

> So I am using
> "group" statements as I need to be sure I am checking the correct module
> return value.

  "group" doesn't change the return codes.  So it don't do what you think
it does.

  If you must use multiple databases, you can't use "redundant".  The
"redundant" keyword is for when one database *fails*.  i.e. it's *down*.
The "redundant" keyword isn't really good for trying multiple
authentication types.

  You need to go back and understand the requirements.  You can't simply
poke at the FreeRADIUS configuration until it works.  You have to
understand what you're trying to do.  And once you understand that, the
solution is usually simple.

  From the limited debug output you posted, it looks like users do have
domain names associated with them.  So why not use that?

        if domain 1
                use ldap1
        else if domain 2
                use ldap2

  Why would it be any more complex than that?

  Alan DeKok.