duplicate usernames across multiple NAS that belong to different users
E.g. User1 on NAS1 has the username "user45" User2 on NAS2 has the same username "user45" We're using Yubikeys and SQL for 2FA/MFA, and I've got the Yubikey mappings sorted based in the clients.conf for each NAS For SQL I can see multiple ways of doing this. Add something (e.g NAS shortname) to the supplied username to match unique usernames in SQL Use different SQL dbs for each NAS or Virtual Server (not a fan of this but it is an option) Write some custom SQL queries and tables so that usernames are linked to groups via an index instead of usernames, this wouldn't be hard but not don't know if different SQL servers can use different SQL queries (Is it as simple as changing which query.conf to import?). Being new, I don't know which option will lead us into FreeRadius hell, or if it doesn't really matter. Thank you
On Aug 31, 2021, at 12:20 PM, Jonathan Davis <jonathan@prioritycolo.com> wrote:
User1 on NAS1 has the username "user45"
User2 on NAS2 has the same username "user45"
Generally this is done with different RADIUS servers, but FreeRADIUS can do this.
We're using Yubikeys and SQL for 2FA/MFA, and I've got the Yubikey mappings sorted based in the clients.conf for each NAS
For SQL I can see multiple ways of doing this.
Add something (e.g NAS shortname) to the supplied username to match unique usernames in SQL
Read sites-available/README. You can use virtual servers to handle this. Create two virtual servers, let's say "server1" and "server2". Start them off as copies of the "default" server, but without the "listen" sections. You'll also need to edit the client definition, to tell FreeRADIUS to send all packets from the client to a particular virtual server: client nas1 { ... virtual_server = server1 client nas2 { ... virtual_server = server2
Use different SQL dbs for each NAS or Virtual Server (not a fan of this but it is an option)
Use different *tables*. You'll need two copies of the SQL module. Create mods-enabled/sql1, and mods-enabled/sql2, both as copies of mods-available/sql Then change the names from: sql { ... to: sql sql1 { ... And also change the RADIUS database used in one (or both) files, from: radius_db = "radius" to: radius_db = "radius1" You'll have to create the DB and the tables, see mods-config/sql/main/mysql/schema.sql for what to do. Then also edit the virtual servers "server1" and "server2". Where they say "sql", change that to "sql1" for server1, and "sql2" for server2. This should be at least in the "authorize" section, and the "accounting" section, and "post-auth" if you're using SQL there. There's a few critical changes, but none of them are complex or difficult. You just have to know what to do. :)
Write some custom SQL queries and tables so that usernames are linked to groups via an index instead of usernames, this wouldn't be hard but not don't know if different SQL servers can use different SQL queries (Is it as simple as changing which query.conf to import?).
When you make the above changes, you effectively have 3 virtual servers: * default - packets from most clients go here * server1 - packets from NAS1 go here * server2 - packets from NAS2 go here And you also have 2 SQL databases, with separate tables for each set of users. The benefit of this approach is that you end up with pretty standard SQL schema, tables, etc. You don't need to mangle the usernames, or edit the queries, or do anything special. In fact, the two different SQL modules can continue to use the same queries! Alan DeKok.
On 2021-08-31 6:13 p.m., Alan DeKok wrote:
When you make the above changes, you effectively have 3 virtual servers:
* default - packets from most clients go here * server1 - packets from NAS1 go here * server2 - packets from NAS2 go here
And you also have 2 SQL databases, with separate tables for each set of users.
The benefit of this approach is that you end up with pretty standard SQL schema, tables, etc. You don't need to mangle the usernames, or edit the queries, or do anything special. In fact, the two different SQL modules can continue to use the same queries!
Alan DeKok.
I prefer not mangling / editing / straying from the defaults of FreeRadius. Where I run into hesitation is with the numbers. The example of 2 is actually 12 devices, in addition to another 88 other devices + additional network and workstations we'd be adding. I can handle creating virtual servers for each, but creating that many sql modules seems unwise to do. Can the SQL table used be set anywhere else? I'm still familiarizing myself with SQL and the authorize section, in that the queries only retrieve a known password for the user, which is authorized in the PAP or other module of the authorized section? Having read the virtual servers documentation, I'm not clear on what settings are inherited (if any), from the default to virtual servers, and if virtual servers can extend other virtual servers? Thank you, Jonathan
On Sep 1, 2021, at 11:36 AM, Jonathan Davis <jonathan@prioritycolo.com> wrote:
I prefer not mangling / editing / straying from the defaults of FreeRadius.
The configuration is editable for a reason. If you're going to do something unusual like having multiple users with the same name, then you'll need too edit the configuration. One choice is to keep the configuration mostly "stock", but use virtual servers to create multiple "virtual" servers. The benefit here is that those configurations can be trivially move to different machines, and to different *real* servers. Another choice is to butcher the configuration to resemble nothing like the standard configuration. Change the lookup fields, change the database to have additional magic keys for each user, etc. But that means not only having custom tables, but having custom *contents* of the tables. You really don't want to do that.
Where I run into hesitation is with the numbers. The example of 2 is actually 12 devices, in addition to another 88 other devices + additional network and workstations we'd be adding. I can handle creating virtual servers for each, but creating that many sql modules seems unwise to do.
Sure. FreeRADIUS gives you the flexibility to do most anything you want.
Can the SQL table used be set anywhere else?
You could also change the table names in mods-available/sql, to create unique tables per NAS. That way you can use one SQL module, and just select different tables: acct_table1 = "radacct_%{%{client:nas_table}:-default}" acct_table2 = "radacct_%{%{client:nas_table}:-default}" ... etc. for all of the "table" configurations. i.e. add a dynamic qualifier to the table names. You'll need to create all of those tables, of course. And you can set the table names in the "clients.conf" section: client nas1 { ... nas_table = "nas1" ... } So all of the tables for NAS1 as "radcheck_nas1", etc. But again... you *cannot* do what you want without editing the configuration. There is no magical solution where the server supports multiple identical user names, and magically selects the "right" one based on the NAS. You must understand, design, implement, and test the solution yourself.
I'm still familiarizing myself with SQL and the authorize section, in that the queries only retrieve a known password for the user, which is authorized in the PAP or other module of the authorized section?
No. The queries do a lot more than that. See the docs in the module configuration, and in http://wiki.freeradius.org
Having read the virtual servers documentation, I'm not clear on what settings are inherited (if any), from the default to virtual servers, and if virtual servers can extend other virtual servers?
There is no "inheritance" from one virtual server to another. They are completely independent. The modules are global, however. Alan DeKok.
Hi,
User1 on NAS1 has the username "user45"
User2 on NAS2 has the same username "user45"
You can also try and turn things around and work on the NAS side. Depending on what you are using , some allow you to set/substitute a realm(domain) for the user So nas 1 user becomes user45@nas1 nas 2 becomes user45@nas2. Do not strip the realm and configure the users as user45@realm. Brian
participants (3)
-
Alan DeKok -
Brian Turnbow -
Jonathan Davis