Radius server - out of the box

  • 1
  • Question
  • Updated 3 years ago
Hello. Does anyone know if it is possible and how to set the AP to use the an external radius with SQL database. We would like to restrict the user to the speed and quantity of the collected data who are enrolled in the SQL database. Any idea, any suggestion?
Photo of Aless


  • 1 Post
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Aless,

Yes, that is very definitely possible. HiveOS offers all the primitives to achieve this, you just need to find a way to tie everything together as you want it at the external RADIUS server. What you do with a SQL database is the sole concern of the RADIUS server, not HiveOS. Isn't separation of concerns great! :)

Look for documentation and features of your chosen RADIUS platform and its extensibility model at that point.

You can apply a user profile via the Access-Accept packet that kicks off the session, sent by a third party RADIUS server, to restrict a client. This is documented by Aerohive and elsewhere here on the community, just search for it in Google.

You can terminate a session via a CoA-Request packet from an external RADIUS server.

You can change the user profile applied dynamically via a CoA-Request packet. This means that you can apply a more restrictive profile, if you wish to, as a user goes over thresholds for data consumed.

If you wish, you can instead set up period 802.1X re-authentication via the Termination-Action and Session-Timeout attributes to impose changes: https://tools.ietf.org/html/rfc3580#section-3.17

You will know the amount of data received via the Interim-Update and and Stop forms of Accounting-Request packets that are sent via the standard RADIUS attributes.

It is strongly recommended to use an Acct-Multi-Session-Id and not an Acct-Session-Id to reference a client's association when using CoA.

When roaming occurs from one BSS to another BSS, you will observe a Stop and a subsequent Start and the Acct-Session-Id will change.

BSS transition can occur from one AP to another or on the same AP between the 2.4 GHz and 5 GHz radio.

This is correct and highly desirable behaviour but you therefore have a race condition with CoA that uses an Acct-Session-Id. (A race constant does not exist with the Acct-Multi-Session-Id that is constant across all related sessions.)

See https://tools.ietf.org/html/rfc3580#section-2.2

(Referencing via a User-Name is conceptually unreliable where anonymous EAP outer identities are allowed/supported in an environment, so I would not recommend trying this. Also, be careful in general with identities, you will likely want to either bind from Auth to Accounting via a Class attribute so that you can know the inner identity when accounting starts or return the inner identity in a User-Name attribute in the Access-Accept packet so that the inner identity is accounted with.)

Note that you will likely want to wait until HiveOS 6.5r3 and 6.6r2 release as Acct-Multi-Session-Id use is only stable and reliable in these forthcoming versions, there are currently issues with it being missed from some Start forms of Accounting-Request packet and changing when a user profile is reassigned. These HiveOS versions are due provisionally around the American thanksgiving holiday this year.

Referencing a session via the Acct-Multi-Session-Id was introduced in HiveOS 6.6r1 after I raised this as an issue during the 6.4r1 beta process. I am unsure if this has or will be backported to 6.5r3, the golden LTS release. This is a question that only the PLMs could answer if they wish to. (Bear in mind that this is prerelease, still in development software.)

If not, you would want to use the feature release branch, currently 6.6rX.

If you have software that processes Accounting-On and Accounting-Off forms of Accounting-Request packet to maintain a list of live sessions, these are currently sent by HiveOS on a per-BSS basis. This MAY change in a future HiveOS release but this currently causes handling issues with the built-in session tracking functionality in FreeRADIUS and Radiator that expect these to be sent only on a per-NAS basis. It means that live sessions can erroneously be considered invalid. For now, you would need to discard these packets so that they are not processed.

(There was an ambiguity in the RFC that lead to differing interpretations as to what the RFC intended. I therefore reported this as an erratum and this has been verified to clarify that only per-NAS behaviour is compliant: https://www.rfc-editor.org/errata_search.php?rfc=2866&eid=4485)