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