Looking for general advice on how to configure a (somewhat complex) freeradius server

[R3DNano]

Thanks for your kind reply, Alan, it's been really helpful.

Forgive me if I'm being too dense here, but if I understand you correctly,
you mean a good approach would be to create one virtual server per each
client (at the end of the day you don't have that many ones, but sure their
authentication methods might differ considerably between one and another),
set non-standard ports on each of them to listen to (since two virtual
servers can't listen on the same port) and inside each server's authorize
section, implement the unlang logic to use the correct authentication
sources?

Much appreciated.

On Fri, 11 Jan 2019, 01:15 Alan DeKok <aland at deployingradius.com wrote:

> On Jan 10, 2019, at 6:38 PM, R3DNano <r3dnano at gmail.com> wrote:
> > I'm kind of new to the radius environment and have spent quite some
> > time for the past weeks going through the documentation and manuals
> > that I could find online.
> > I find the wiki pretty complete and the config files are quite well
> > documented as well. Kudos to the authors.
>
>   That's good to hear.
>
> > However, I'm a bit stuck trying to design a somewhat complex structure
> > inside my server, which has multiple clients (i.e.: wifi controllers,
> > VPN, etc) and multiple authentication sources (LDAP, different MySQL
> > databases...) - and don't forget eduroam -
>
>   That's the real problem.  RADIUS is usually about gluing many things
> together.  It's possible, but it's not always simple.
>
> > I'm having a hard time trying to decide where to do the decision
> > making tasks mostly because of fear of configuring it in an improper
> > way.
>
>   The main thing is to realize that the best approach is to look for key
> information.  That key information can be used to tell the different
> situations apart.  It's then a simple (mostly) matter of writing the config
> for each case.
>
> > My problem is that I don't know if the best practice to tackle the
> > issue would be to start by setting the clients up and let them all go
> > through the default server and there, do the decision making with
> > unlang to authenticate them against the corresponding auth source
> > depending on ssid, realm etc... or send them to do eduroam proxying
> > from here, even.
>
>   My $0.02 is this.
>
>   Configure and test each case in isolation.  That makes it simple to "do
> the right thing" for each case.
>
>   The hard part then becomes *combining* the different cases.  This is
> where virtual servers can help.  See raddb/sites-available/README.  If you
> have one client IP that does VPN and only VPN, great!  Create a virtual
> server just for that situation.  You can then tests / validate it in
> isolation.  And once it's working, you can forget about it.
>
>   The harder thing is when you want to do multiple kinds of authentication
> from the same client.  That can be done by keying off of SSID, Realm, etc.
>
>   For example, if your local realm is @example.com, you can do:
>
> authorize {
>         suffix
>         if (Realm != "example.com") {
>                 ... check for "bad" realms so you don't annoy the eduroam
> people ...
>                 update control {
>                         Proxy-To-Realm := "eduroam"     # upstream servers
>                 }
>
>                 # don't do anything else!
>                 return
>         }
>
>         ... now you only have requests for your local realm! ...
>
> }
>
> > I could really use your expertise in this. I'm not looking for someone
> > to spoon feed me, just to point me in the right way.
> > Sometimes, seeing some configuration examples for concrete cases could
> > help, but I can't really seem to find any of these (logically, people
> > don't go around sharing their freeradius config).
>
>   It's really about creating policies.  These are almost always local to
> your site, and therefore not of much use to anyone else.
>
>   The process of *creating* these policies is hard to explain.  The above
> explanation is as good as any.  And as always, a slow steady approach is
> best.
>
>   Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html