Dynamic User Help
We provide AAA services to a variety of client businesses across North America, and we use FreeRADIUS as the final piece of our authentication process. Because our clients' customers are unknown until they attempt to connect to the network, all user radius credentials are created dynamically, after an initial authentication via another method (typically, credit card charges, access codes, etc.); once that initial auth is complete, we create a credential using the user devices' MAC address to ensure uniqueness, and to facilitate the MAC auth feature of the gateway devices we employ, which permits immediate reconnection following idle time-out without having to open a browser (a limitation of the gateway devices). Of concern to us is that we don't want a user to authenticate in one place of business for which we provide service, then move to another client site, at which MAC authentication is enabled, and have the device automatically connected at the second location. This is mainly due to differences in service offerings at different client sites. What we're looking to do is create an additional table in the radius database. That table would contain the following fields: id primary table key callingstationid self-explanatory nasid identifies the specific site the user is at, and corresponds to our own internal site id nasportid the vlan the user is in groupname the group to which the user is assigned in radusergroup As we create each user's credentials, we'll populate this new table with the information indicated. For each VLAN the user connects to, there would be a separate row so that, as he moves from vlan to vlan, we can update the group assignment in radusergroup so that he'd get the proper group attributes. Does this sound like something that could work? If so, I need a bit of help understanding where we'd put the table query (and the construction of it) in whichever file it should be in (e.g., sites-enabled/default?). The goal is to perform the query, and if there's a corresponding row match, do an update on the username in radusergroup to set the proper group id, and then continue normal processing; if there is no match, we'd simply reject the connection, which would force the gateway to redirect to a captive portal server for initial authentication, as described above). For me, the sticking point is where and how to put the SQL query, so I'd appreciate any pointers I can get. And, too, if there's a better way of doing this, I'd welcome any advice! I hope I've provided enough information to start. Many thanks in advance! Jim
On Sep 9, 2015, at 1:54 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
Does this sound like something that could work?
Yes.
If so, I need a bit of help understanding where we'd put the table query (and the construction of it) in whichever file it should be in (e.g., sites-enabled/default?).
Yes. Typically in the "authorize" section. Do an SQL lookup which matches the MAC. If there's a NASID / port there which does NOT match the current one, reject the user.
For me, the sticking point is where and how to put the SQL query, so I'd appreciate any pointers I can get. And, too, if there's a better way of doing this, I'd welcome any advice!
Just put it in the "authorize" section. Alan DeKok.
Thanks, Alan. We'll play around with it and see what we can do! Jim On 09/09/2015 03:30 PM, Alan DeKok wrote:
On Sep 9, 2015, at 1:54 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
Does this sound like something that could work? Yes.
If so, I need a bit of help understanding where we'd put the table query (and the construction of it) in whichever file it should be in (e.g., sites-enabled/default?). Yes. Typically in the "authorize" section. Do an SQL lookup which matches the MAC. If there's a NASID / port there which does NOT match the current one, reject the user.
For me, the sticking point is where and how to put the SQL query, so I'd appreciate any pointers I can get. And, too, if there's a better way of doing this, I'd welcome any advice! Just put it in the "authorize" section.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 09/09/2015 03:30 PM, Alan DeKok wrote:
On Sep 9, 2015, at 1:54 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
Does this sound like something that could work? Yes.
If so, I need a bit of help understanding where we'd put the table query (and the construction of it) in whichever file it should be in (e.g., sites-enabled/default?). Yes. Typically in the "authorize" section. Do an SQL lookup which matches the MAC. If there's a NASID / port there which does NOT match the current one, reject the user.
For me, the sticking point is where and how to put the SQL query, so I'd appreciate any pointers I can get. And, too, if there's a better way of doing this, I'd welcome any advice! Just put it in the "authorize" section.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OK, so we're finally at the point at which we're attempting to integrate this into our configuration. The intent, per Alan's guidance, is to insert the following statements at the top of the authorize section: if ("%{Called-Station-Id}" =~ "^<some-mac-prefix>") { User-Group-Name = "%{sql: SELECT group_name from <table_name> where \ site_id='%{NAS-Identifier}' and mac_address='%{Calling-Station-Id}' \ and vlan_id='%{NAS-Port-Id}'}" if ("%{User-Group-Name}" != "" { %{sql: update radusergroup set groupname='%{User-Group-Name}' \ where username='%{Calling-Station-Id}'"; } else { reject } } If we find a match on the group_name in the first query, we would update the radusergroup entry for the given MAC address and then simply fall through to allow normal processing to continue. If there's no match, we'd reject the authorization request, which would then cause our gateway to force the user to a captive portal for authentication. Does this series of statements look valid, or is there a better way? Many thanks, Jim
On Feb 23, 2016, at 3:32 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
OK, so we're finally at the point at which we're attempting to integrate this into our configuration. The intent, per Alan's guidance, is to insert the following statements at the top of the authorize section:
if ("%{Called-Station-Id}" =~ "^<some-mac-prefix>") { User-Group-Name = "%{sql: SELECT group_name from <table_name> where \ site_id='%{NAS-Identifier}' and mac_address='%{Calling-Station-Id}' \ and vlan_id='%{NAS-Port-Id}'}"
User-Group-Name needs to be in an "update" section. See "man unlang". update request { User-Group-Name = "%{sql: ... }
if ("%{User-Group-Name}" != "" {
That can be simplified to: if (&User-Group-Name != "") {
%{sql: update radusergroup set groupname='%{User-Group-Name}' \ where username='%{Calling-Station-Id}'";
You can't just put SQL statements into a block. You need an "update" section. See again "man unlang". e.g.: update request { Tmp-String-0 := "%{sql:UPDATE ...}" }
If we find a match on the group_name in the first query, we would update the radusergroup entry for the given MAC address and then simply fall through to allow normal processing to continue.
You'll have to ensure that the RADIUS server is allowed to edit the radusergroup table. IIRC, the default permissions don't allow this. Alan DeKok.
On 02/23/2016 03:36 PM, Alan DeKok wrote:
On Feb 23, 2016, at 3:32 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
OK, so we're finally at the point at which we're attempting to integrate this into our configuration. The intent, per Alan's guidance, is to insert the following statements at the top of the authorize section:
User-Group-Name needs to be in an "update" section. See "man unlang".
update request { User-Group-Name = "%{sql: ... }
That can be simplified to:
if (&User-Group-Name != "") {
You can't just put SQL statements into a block. You need an "update" section. See again "man unlang". e.g.:
update request { Tmp-String-0 := "%{sql:UPDATE ...}" }
You'll have to ensure that the RADIUS server is allowed to edit the radusergroup table. IIRC, the default permissions don't allow this.
Alan DeKok. List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
As ever, thanks, Alan. Somehow, I knew that I'd missed something in the sql update bit. My confusion comes from the final "else" statement; I would think that it belongs inside the update section as well. Would it be "safe" to encapsulate the queries in a single update section, as below? if ("%{Called-Station-Id}" =~ "^<some-mac-prefix>") { update request { User-Group-Name = "%{sql: SELECT group_name from <table_name> where \ site_id='%{NAS-Identifier}' and mac_address='%{Calling-Station-Id}' \ and vlan_id='%{NAS-Port-Id}'}" if (&User-Group-Name != "" { Tmp-String-0 := "%{sql: update radusergroup set \ groupname='%{User-Group-Name}' \ where username='%{Calling-Station-Id}'}"; } else { reject } } } Cheers, Jim
On Feb 23, 2016, at 4:28 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
As ever, thanks, Alan. Somehow, I knew that I'd missed something in the sql update bit. My confusion comes from the final "else" statement; I would think that it belongs inside the update section as well.
No. Again, see "man unlang". This is documented.
Would it be "safe" to encapsulate the queries in a single update section, as below?
No. See "man unlang". The format is documented. You can't just invent syntax and have it work. If you had tried that configuration, the server would complain loudly, and refuse to start. Which would have answered your question. Alan DeKok.
On 02/23/2016 06:35 PM, Alan DeKok wrote:
On Feb 23, 2016, at 4:28 PM, J Kephart <jkephart@safetynetaccess.com> wrote:
As ever, thanks, Alan. Somehow, I knew that I'd missed something in the sql update bit. My confusion comes from the final "else" statement; I would think that it belongs inside the update section as well. No.
Again, see "man unlang". This is documented.
Would it be "safe" to encapsulate the queries in a single update section, as below? No. See "man unlang". The format is documented. You can't just invent syntax and have it work.
If you had tried that configuration, the server would complain loudly, and refuse to start. Which would have answered your question.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks, Alan. I was a little vague on the "man unlang" page, but I think it's starting to make sense. Don't mean to sound dense, just still learning, and there's so much that FR seems able to do, it's a little daunting! Jim
participants (2)
-
Alan DeKok -
J Kephart