Table of Contents
Updated by Alex Moore
Read Time: 5 mins
Defining RADIUS groups will automatically create RADIUS user groups on your RADIUS server. The name provided, and the priority selected, will determine the name of the group, and the priority of the group, when created on the RADIUS server.
The primary purpose of a RADIUS group is to implement some kind of policy for a group of accounts. For example, you could group all RADIUS usernames that are on active accounts with a reply that provides access out of your network. You can send a RADIUS reply to your concentrator that provisions that RADIUS user with specific download and upload limits based on the service on that account. You could also create a RADIUS group for all delinquent accounts, and implement a reply to send those users to a walled garden until they pay their bill. Because, let’s be honest, we all like money!
The name of the RADIUS group will be used to name the RADIUS user group on the RADIUS server.
Setting a priority here will set the priority in the RADIUS server. If an account is a member of two RADIUS groups with conflicting reply attributes, the lower numbered priority will be used.
Selecting Fall Through will enable the Fall-Through group reply attribute on your RADIUS server. Generally, you will probably enable this on most of your groups, as it will allow your RADIUS server to evaluate each group a member is a part of.
The Account Status limit allows you to include all accounts, regardless of status, or only accounts that have either an inactive or active status. This is commonly used to perform an action like redirecting any inactive accounts to a walled garden.
The Delinquency section allows you to include all accounts, only accounts that are current on their invoices, or only accounts that are delinquent. You could use this to perform an action like redirecting all delinquent accounts to a splash page informing them they must pay their bill to be reactivated.
Non-required fields include Account Groups, Account Statuses, Account Types, and Data Services. When selecting relationships within these fields, if you select multiple items in a section, they are treated as an OR statement. Selections in multiple sections are treated as an AND statement. For example, if, under the Account Status section, you select Active and Lead, and under the Account Type section, you select Residential, the check applied would be as follows in plain English:
Any account who has either an Active status OR a Lead status, AND is Residential will be placed into this RADIUS group.
All changes you make to a RADIUS group will modify the RADIUS users on your RADIUS server as sessions are expired and renew. Deleting a RADIUS group will also remove it from the RADIUS server. If you wish to make changes to your RADIUS groups, and you do not want the changes to affect your RADIUS server(s) until you are done, be sure to disable the RADIUS server in Sonar first, make the changes, then re-enable the RADIUS server and use the Synchronize function.
Example RADIUS Groups
A standard set of RADIUS groups that should exist in any Sonar instance that is using RADIUS to control access and shaping would be as follows: A Delinquent RADIUS group, an Active RADIUS group OR an Inactive RADIUS group, and X DataService lists where each data service has its own RADIUS group. Note that if two data services share the same upload and download speeds, they can be grouped together in the same RADIUS group.
The Delinquent list should be set so that the Account Status is "All account statuses" and the Delinquency is "Delinquent".
The Active or Inactive list should be set so that the Account Status is "Only account statuses that activate an account" or "Only account statuses that do not activate an account". You might not build these groups at all if RADIUS is the only way a user can authenticate, but if you wanted to add a RADIUS reply attribute that acted as a redirect, you might build one for inactive.
Any DataServices RADIUS groups can be built so that Account Status is set to "All account statuses" and Delinquency is set to "all". This way if somehow a delinquent or inactive customer were to gain access they would still be rate limited. In the example screenshots, I have built a RADIUS group for the Bronze Internet, Silver Internet, and Gold Internet services. If two services share the same data rates, you can group them together in the Data Services.
Legacy Equipment, Same Service
Imagine the following scenario, you have an area of your network where new equipment allows you to offer larger packages. You are slowly retrofitting your existing network footprint, but for the time being, you have areas in your network where the new speeds are not yet possible. Rather than creating new services for the new speeds and instructing your billing staff on which services are available in which areas, a simpler approach might be to add all customers with legacy equipment into a "Legacy Equipment" account group. Now you can take the same "Gold Internet" service and apply different data rates based on the account group. In the examples below, we have created "OldGoldInternet" as a RADIUS group to be applied to any accounts that have the gold service but are part of the "Legacy Equipment" in Account Groups. This way no matter what equipment is deployed to the account, your billing staff can just add the Gold Internet as a service to any account. Notice the priority in the other examples was set to 5 but this one is set to 4. Because all members of the "OldGoldInternet" RADIUS group will also belong to the "GoldInterent" RADIUS group we want to make sure this set of reply attributes is followed.
Once you have RADIUS groups built, move on to this article to learn about setting reply attributes.