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@deployingradius.com wrote:
On Jan 10, 2019, at 6:38 PM, R3DNano <r3dnano@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