802.1x/iPSK DB access delegation.
Dear folks, I hope you are enjoying the Christmas season and my best wishes for the 2022, Sorry if this question is not strictly related to FreeRadius but rather on the tools it interacts with for a better management of the WiFi accesses. I'm looking for suggestions/ideas that can point me in the right direction I have used Freeradius with its 2.0 version for my home project few years back, Now I'm in charge of providing wireless access in an environment with a few small companies. To better organize the air-media and avoid media competition or conflicts we would like to have just one/two SSIDs and then grant access to companies' employees or devices. So far so good, because for devices that can use 802.1x we can proxy Access-requests to the RADIUS server of each company. Problems come with non smart devices that still use PSK; I know iPSK helps a lot but I don't know how to delegate the management of MAC addresses. I'm not taking into account a text file to manage them; can we use a DB for iPSK too? And related to the DB is there a way to manage iPSK devices in this way? Just one table and a value specific to each company and small web interface that will handle only fields specific to each company? Would you have any other ideas to share with the community? Thanks, Alex
On Dec 29, 2021, at 3:35 AM, Alex Zetaeffesse <fzetafs@gmail.com> wrote:
I have used Freeradius with its 2.0 version for my home project few years back, Now I'm in charge of providing wireless access in an environment with a few small companies.
It would be best to upgrade to v3. It not only has more features, v2 is EOL, with no more bug fixes or security fixes.
Problems come with non smart devices that still use PSK; I know iPSK helps a lot but I don't know how to delegate the management of MAC addresses. I'm not taking into account a text file to manage them; can we use a DB for iPSK too?
Sure. Why not?
And related to the DB is there a way to manage iPSK devices in this way? Just one table and a value specific to each company and small web interface that will handle only fields specific to each company?
It depends on what you want to do, and what limitations the NAS has. iPSK authentication is pretty much just MAC authentication, which returns a Tunnel-Password attribute to the NAS: https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_... So you can put the MAC address into a DB, just like you do with normal users. The difficulty is that normal users come in with User-Name like "user@example.com". MAC addresses don't have a company name associated with them. You're likely going to have to create a custom table here, with "MAC, tunnel password, company" as columns. You can create a web interface which gives each company a view on that table. And every time a company adds a MAC address, the system *also* adds the company name automatically. FreeRADIUS doesn't need the company name, (unless you use it for VLAN assignment), But you'll need to track the company name for the web administration system. You probably don't want a separate table for each company. Because then FreeRADIUS would have to query each table in turn to see if the MAC is in that table. Alan DeKok.
Thanks Alan, On Wed, Dec 29, 2021 at 3:17 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 29, 2021, at 3:35 AM, Alex Zetaeffesse <fzetafs@gmail.com> wrote:
I have used Freeradius with its 2.0 version for my home project few years back, Now I'm in charge of providing wireless access in an environment with a few small companies.
It would be best to upgrade to v3. It not only has more features, v2 is EOL, with no more bug fixes or security fixes.
Indeed, I didn't mention it but of course that's the way to go.
Problems come with non smart devices that still use PSK; I know iPSK helps a lot but I don't know how to delegate the management of MAC addresses. I'm not taking into account a text file to manage them; can we use a DB for iPSK too?
Sure. Why not?
And related to the DB is there a way to manage iPSK devices in this way? Just one table and a value specific to each company and small web interface that will handle only fields specific to each company?
It depends on what you want to do, and what limitations the NAS has.
I'm doing some tests with the vWLC 9800 and a couple of 3700 APs.
iPSK authentication is pretty much just MAC authentication, which returns a Tunnel-Password attribute to the NAS:
https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_...
So you can put the MAC address into a DB, just like you do with normal users.
The difficulty is that normal users come in with User-Name like " user@example.com". MAC addresses don't have a company name associated with them.
You're likely going to have to create a custom table here, with "MAC, tunnel password, company" as columns. You can create a web interface which gives each company a view on that table. And every time a company adds a MAC address, the system *also* adds the company name automatically.
Exactly, I would return the VLAN attribute too in order to guarantee privacy among the companies.
FreeRADIUS doesn't need the company name, (unless you use it for VLAN assignment), But you'll need to track the company name for the web administration system.
Of course, I'll define an admin for each company in charge of administering 802.1x capable and non-capable devices and grant access to him/her to the web GUI.
You probably don't want a separate table for each company. Because then FreeRADIUS would have to query each table in turn to see if the MAC is in that table.
I didn't know FR could query different sources of authentication/authorization sequentially (especially if tables are on different servers) but I guess that would introduce a lag in the response time back to the NAS Maybe a SQL proxy (that's on my side)? Then the first reply would be served. And uh by writing this I realized I could expose the service to a potential DoS for specific MAC addresses. Ok, much better a single table in a single DB where checks before storing a record can be done simply and quickly!
Alan DeKok.
Thanks! Alex
On Dec 29, 2021, at 10:15 AM, Alex Zetaeffesse <fzetafs@gmail.com> wrote:
I didn't know FR could query different sources of authentication/authorization sequentially (especially if tables are on different servers) but I guess that would introduce a lag in the response time back to the NAS
Yes. FR can do pretty much anything. It's just that you usually don't want to do many queries. It's inefficient, and slow.
Maybe a SQL proxy (that's on my side)? Then the first reply would be served. And uh by writing this I realized I could expose the service to a potential DoS for specific MAC addresses. Ok, much better a single table in a single DB where checks before storing a record can be done simply and quickly!
Exactly. Also, the table used by FR doesn't have to be the same ones used by the web tool. You can create views, foreign keys, etc. The point is that the DB used by FreeRADIUS should be (a) local, and (b) fast. Alan DeKok.
Just a small update on the project. I have realized that with Cisco 9800 and 3702I I must use FlexConnect but in the FlexProfile I am limited to 16 VLANs and hence the solution with Cisco scales up to 16 companies. I wonder if anybody in the ML has experiences where local switching can be done with more than 16 VLANs (with other than Cisco HW). Alex On Wed, Dec 29, 2021 at 4:51 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 29, 2021, at 10:15 AM, Alex Zetaeffesse <fzetafs@gmail.com> wrote:
I didn't know FR could query different sources of authentication/authorization sequentially (especially if tables are on different servers) but I guess that would introduce a lag in the response time back to the NAS
Yes.
FR can do pretty much anything. It's just that you usually don't want to do many queries. It's inefficient, and slow.
Maybe a SQL proxy (that's on my side)? Then the first reply would be served. And uh by writing this I realized I could expose the service to a potential DoS for specific MAC addresses. Ok, much better a single table in a single DB where checks before storing a record can be done simply and quickly!
Exactly.
Also, the table used by FR doesn't have to be the same ones used by the web tool. You can create views, foreign keys, etc.
The point is that the DB used by FreeRADIUS should be (a) local, and (b) fast.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sorry for resuming this thread but I resumed working on this project too. Each company may use PEAP (not really the best I know) or EAP-TLS (or TTLs) for smart devices and iPSK (MAC addr as username and the RADIUS returns the PSK) for IoT devices. As to the CRL my understanding is that the CRL must be concatenated to the CA or the CA chain. And whenever a cert is revoked the CRL must be updated and the FR instance restarted. Things from this standpoint haven't changed so far, have thay? So if each company wants to manage their own devices independently we must have one FR instance per company. I guess it's possible to run different FR instance on the same host though using docker would be a more elegant solution. Eventually there will be as many FR instances as the tenants for Smart Devices, one possible DB for IoT devices (one table per tenant?) and as many CRL as the number of tenants. Alex On Wed, Dec 29, 2021 at 4:51 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 29, 2021, at 10:15 AM, Alex Zetaeffesse <fzetafs@gmail.com> wrote:
I didn't know FR could query different sources of authentication/authorization sequentially (especially if tables are on different servers) but I guess that would introduce a lag in the response time back to the NAS
Yes.
FR can do pretty much anything. It's just that you usually don't want to do many queries. It's inefficient, and slow.
Maybe a SQL proxy (that's on my side)? Then the first reply would be served. And uh by writing this I realized I could expose the service to a potential DoS for specific MAC addresses. Ok, much better a single table in a single DB where checks before storing a record can be done simply and quickly!
Exactly.
Also, the table used by FR doesn't have to be the same ones used by the web tool. You can create views, foreign keys, etc.
The point is that the DB used by FreeRADIUS should be (a) local, and (b) fast.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Alex Zetaeffesse