Understanding how Simultaneous-Use attribute works in Radius
A lot of people who run radius servers sooner or later find out that they need to restrict multiple connections with the same login name to number N (in general number N can be any natural number, but usually N = 1).
Why may you need to use Simultaneous-Use attribute?
If you installed radius server for the first time or just never used this attribute, and have no idea why you may need to use this attribute, below are several examples:
example 1: You are the I.S.P. and decided to give free access for your customers (There are many reasons for this: testing new hardware, advertisement reasons, etc). You can create account name "free" with password "free" and Simultaneous-Use = 10. With these settings not more than 10 ports will be used for free access. Without this restriction your dial-in ports became used very soon for unlimited amount of time.
example 2: You sell the phone cards for $10 each and you charge your customer $1 per minute of his/her conversation. If so, your customer is allowed to talk 10 minutes at max (), but you update his/her deposit after session finishes. Person A bought your telephone card, and shared the PIN with Person B. Situation: Person A called in at 12:00 and began his/her conversation. He/she will be disconnected at 12:10 at max.Person B called in at 12:01 with the same PIN and as Person A is still talking, there is $10 on his/her deposit, so Person B is allowed to begin the conversation with 10 minutes restriction. In the worst case Person A will talk 10 minutes and Person B too. As the result when they both hang up, there will be -$10 on the deposit for their PIN. So you lost $10. If you used Simultaneous-Use attribute for PIN (as PIN is your login name), then Person B wouldn't be able to start his conversation while Person A was online.
example 3: You are the I.S.P. and sell the unlimited internet (user pays some amount of money and uses the internet at any time for unlimited amount of time during for example 1 month). If you don't restrict concurrent connections for this kind of customers, One user will pay for this service and share his/her account with unlimited number of other users, so your service will fail.
More and more examples can be discussed, but I think some reasons why you may need to use Simultaneous-Use attribute faced out. And of course, in examples above, I didn't mean that If you won't use this attribute you won't be able to solve these tasks. There also should be other techniques to get the same results so if this mechanism doesn't fit your needs, or maybe there is better way to do the same, I'll be glad to discuss it with you any time.
How exactly does this work?
It's time to discuss how this mechanism works. We will show how user should be configured correctly with Simultaneous-Use attribute later. For now we suppose that some user e.g. "test" is configured with Simultaneous-Use attribute equal to 1. As mentioned above, this mean that 1 concurrent connections is permitted at any moment of time.
At some point of authentication, the simultaneous-use checking is done. It contains the following steps:
1. If Simultaneous-Use attribute is defined for the entry against which user is authenticating rad_check_multi() procedure is called otherwise all other steps are skipped.
2. rad_check_multi() tries to check whether maximum count is reached using two different sources of information:
a) login is tested against internal base (radutmp file in cistron radius, radacct table in icradius). If count (count_N below) retrieved from this base is less that specified in Simultaneous-Use attribute (simult_Max below), than check rad_check_multi returns with success, otherwise step b) is performed.
b) login is tested against terminal server using rad_check_ts() procedure (sql_check_ts() in icradius). rad_check_ts() procedure just calls checkrad external perl script with required params. checkrad's exit code is returned to rad_check_multi(). If less then count_N number of entries are found on terminal server, than corresponding "stale" record in internal database is removed and rad_check_multi() returns with success, otherwise it returns with failure.
Note: Some less important steps (like Multi link PPP detection) are removed from the scheme above to make things clear enough.
As the result, we can see that terminal server is queried only when radius internal base contains exactly simult_Max number of entries for specified user. That means that checkrad is called only in this case.
Checkrad
As you have noticed checkrad script is used to make the final decision. It is called to check if user is still online for nas/port pair. Checkrad contains number of subroutines coded by different people. Almost every subroutine is nas specific. The main part contains flow control block which calls specific subroutine according the nas type. For example, if your nas is "cisco", checkrad is called with "cisco" as one of the arguments and cisco_snmp subroutine is called. If you use only one type of nases, you can remove all other nas specific subroutines ("can" doesn't mean "should", but it's possible). Every nas specific subroutine uses on of the protocols supported by the nas, including SNMP, FINGER, TELNET, RUSERS. SNMP is preferred, if supported. Checkrad is called with the following arguments:
1. NAS Type. Possible values are: "livingston", "cisco", "multitech", "computone", "max40xx", "max40xx_snmp", "ascend", "portslave", "tc", "pathras", "pr3000", "pr4000", "patton", "digitro", "usrhiper", "netserver", "versanet", "other". All values are clear except final one. If "other" is specified, checkrad doesn't call the subroutine and returns 1 ("dublicate") immediately.
2. Nas IP Address. Haven't checked if hostname instead of ip is permited. If yes, please check hostname is resolvable to the NAS's ip address.
3. Nas Port.
4. Username.
5. Session_id.
6. Community.
Based on this information checkrad queries nas and returns 0 if session is stale, 1 if user is still online, value more then 1 in case of any error.
As you can notice, sixth argument is needed only if SNMP protocol is used. If TELNET is used, checkrad have to retrieve username/password pair from naspasswd file additionally to its arguments. If your nas type isn't listed in the list above, then probably you have to modify checkrad yourself and add nas specific subroutine for your nas yourself or ask someone to do it for you. Basic steps and recommendations about how to do this are described in Troubleshooting section.
Enabling Simultaneous-Use Attribute
Finally, we are ready to configure Simultaneous-Use attribute for specific user/group and make it to work. Configuration for group is almost the same as for user, will describe only user's case, I hope you will be able to do the same for groups without any problem.
Let use describe 2 different situations:
1. We want to restrict user "test" for 4 simultaneous connections. Cisco router is used as the nas.
Steps to be done:
a) Check whether this type of nas is supported by checkrad (We are lucky with "cisco") and what communication protocol is used for it (In case of "cisco" SNMP is used).
b) For SNMP to work, enable SNMP server on the nas, create SNMP read community and allow SNMP access for our radius server. "somecommunity" string will be used in our example:
router# configure terminal
router(config)# snmp-server community "somecommunity" ro
router(config)# exit
We have enabled snmp-server, created read-only (ro) community "somecommunity" and allowed read access from any source.
c) Add nas specific info to your radius server (nas name "router", nas ip 192.168.0.1)
for cistron:
echo -e "192.168.0.1\trouter\tcisco" >> /etc/raddb/naslist
echo -e "192.168.0.1\tSNMP\tsomecommunity" >> /etc/raddb/naspasswd
echo -e "192.168.0.1\tsomesharedsecret" >> /etc/raddb/clients
for icradius:
insert into nas values('', 'router.yourdomain', 'router', '192.168.0.1', 'cisco', 16, 'somesharedsecret', 'somecommunity', 'on');
Note: "ports" field in "nas" table contains value representing number of ports on specific nas. It isn't used by radius server at all.
d) Add user/group specific info to your radius server
for cistron:
cat << __END >> /etc/raddb/users
test Simultaneous-Use = 4
Service-Type = Framed-User,
Framed-Protocol = PPP
__END
for icradius:
insert into radcheck values('', 'test', 'Simultaneouse-Use', 4);
insert into radreply values('', 'test', 'Service-Type', 'Framed-User');
insert into radreply values('', 'test', 'Framed-Protocol', 'PPP');
Note: Two reply items are listed for example purposes and have nothing common with Simultaneous-Use attribute. This attribute is check item.
e) If step c was done before last radius restart ignore this step, otherwise restart your radius server
2. We want to restrict user "test" for 4 simultaneous connections. USR Netserver is used as the nas.
Steps to be done:
a) Check whether this type of nas is supported by checkrad ("netserver" is supported as well) and what communication protocol is used for it (In case of "netserver" TELNET is used).
b) TELNET server is enabled by default on netserver. Net::Telnet perl module should be installed on radius server which is used by checkrad program for TELNET connections. Make sure it is installed.
c) Add nas specific info to your radius server (nas name "router", nas ip 192.168.0.1)
for cistron:
echo -e "192.168.0.1\trouter\tcisco" >> /etc/raddb/naslist
echo -e "192.168.0.1\t!root\tnetserverpassword" >> /etc/raddb/naspasswd
echo -e "192.168.0.1\tsomesharedsecret" >> /etc/raddb/clients
for icradius:
insert into nas values('', 'router.yourdomain', 'router', '192.168.0.1', 'netserver', 16, 'somesharedsecret', '', 'off');
Note: "ports" field in "nas" table contains value representing number of ports on specific nas. It isn't used by radius server at all.
d) Add user/group specific info to your radius server
for cistron:
cat << __END >> /etc/raddb/users
test Simultaneous-Use = 4
Service-Type = Framed-User,
Framed-Protocol = PPP
__END
for icradius:
insert into radcheck values('', 'test', 'Simultaneouse-Use', 4);
insert into radreply values('', 'test', 'Service-Type', 'Framed-User');
insert into radreply values('', 'test', 'Framed-Protocol', 'PPP');
Note: Two reply items are listed for example purposes and have nothing common with Simultaneous-Use attribute. This attribute is check item.
e) If step c was done before last radius restart ignore this step, otherwise restart your radius server
If you find out that your nas type isn't supported on step a, you wont be able to configure "Simultaneous-Use" feature with standard checkrad script. Refer to Troubleshooting section for more information.
That's all. If you have done your configuration exectly the way described above, Simultaneous-Use feature is turned on for user/group and working.
Some times I spent a lot of time finding out why something that is configured as described in manuals and should work, doesn't. If you read this section because your configuration process failed at some point, for example because your nas type isn't supported by checkrad, you are on a right way. I'll try to pay your attention on most common problems. You have to make sure you run up2date software. Common problems:
a) Appropriate perl module used by checkrad isn't installed.
If checkrad is unable to find required module for the nas it won't be able to do it's job. For example if TELNET protocol is used for data retrieval, make sure Net::Telnet module is installed.
b) Your nas type is supported by checkrad, SNMP is used for data retrieval from nas, but simultaneous-use still doesn't work.
1. Make sure communities match on nas and radius configuration
2. Make sure nas is accessible from your radius server through SNMP. For this reason you can use snmpget/snmpwalk programs from UCD-SNMP package like this:
snmpwalk 192.168.0.1 "somecommunity" "system"
where 192.168.0.1 is ip address of your nas, "somecommunity" is community string, system is objectid (use it as is)
You should get information like this:
...
system.sysDescr.0 = bla bla bla
system.sysUpTime.0 = Timeticks: (280696) 0:46:46.96
system.sysContact.0 =
system.sysName.0 = router
...
If output contains responses "No response", "Connection timeout" or something like them, then you have to fix this first. If snmpwalk is unable to retrieve data via SNMP, checkrad won't be able to retrieve it either.
3. Make sure OID in appropriate subroutine is correct for you nas. Say, you use some type of nas. There are several versions of software released for it, and very often new versions of software aren't fully backward compatible with previous ones. So, there is a chance that programmer who coded the subroutine, that worked for him and other people using the same version of software, wont work for you. Don't be surprised if objects referenced by OID used for your nas type, doesn't exists in the SNMP table of your nas at all. In this case you have to find appropriate OID if possible.
c) Your nas type isn't supported by checkrad.
You have to add appropriate subroutine for you nas or ask someone to do it for you. Adding additional subroutine in most cases isn't difficult at all. First decide which protocol should be used for data retrieval. If you have appropriate OID and SNMP is supported you can use SNMP. If not, most nases let you trace online sessions through CLI. If this is the case and you use TELNET protocol to connect to your nas for CLI, then you can use TELNET + CLI scheme for data retrieval. And so on. After you decided which protocol to use, look through checkrad script and see how similar subroutine is coded for another nas types.
Tasks of this article
This article was created to encourage people who had spent a lot of time enabling Simultaneous-Use feature and for some reason failed to achieve the desired result. I'll be glad to receive your questions/suggestions/corrections at wrath <at> geo <dot> net <dot> ge and modify this article accordingly.
George Chelidze