RADIUS Implementation with multiple error codes/messages


#1

Typically I do implementations using either Emerald or Powercode, and therefore I’m able to use a very well-implemented RADIUS solution, or BMU to do the account control. Now that I’m doing my first implementation using Sonar, I am seeing some weaknesses in the FreeRADIUS implementation, specifically in how it doesn’t pass an expiration date into the RADIUS SQL database. Specifically, some things I would like to be able to do include having different errors sent by by RADIUS when the account is expired, or when the account doesn’t exist at all. It looks like FreeRADIUS is fairly configurable to achieve some of this, but I just need to figure out the key component so that the expiration date is in the table.

Has anybody done this? Or have any pointers for what may be able to be done?

My thoughts are that these messages will be parsed by Mikrotik hotspot and then forwarded to an external script where each of the error messages will provide different responses for the client letting them know how to proceed with getting back online. Differentiating between a router/MAC not existing in the network, an account being misconfigured in our system (ie. no hotspot user-profile exists), and the account being expired would be a great start.


#2

You can pass any attribute you want by building RADIUS groups. There’s some examples at https://sonar.software/casts. There is no concept of an ‘expiration time’ in Sonar though, so that’s something you’d have to write into the database externally.


#3

Thanks for the response on this. I determined the best way to do this was to utilize RADIUS groups and then build into the /etc/freeradius/sites-enabled/default file, the radgroup matching for each particular type of user that may be rejected. For example, an account is inactive (closed, lead, anything other than active, really) it could be matched on using RADIUS groups to provide the appropriate response back to the client (along with that very important reject notice to the NAS).


#4

You don’t necessarily need to return a more specific error from RADIUS to give the client an appropriate error message explaining the reason that their service is not working. We do this using the address-list functionality in Sonar. We have an address list for each potential reason explaining why the customer cannot connect, and redirect them to a different URL based on each potential reason. It shouldn’t require changes on the RADIUS back end, except maybe for something like distinguishing between “account doesn’t exist” and “wrong password”.