Hi 2008/11/11 <tnt@kalik.net>:

Use huntgroups to group ports.

blah1@example.com Huntgroup-Name == whatever

Thanks. I took a look at huntgroups and it looks userful but I think it is not right for what I am trying to do. I think I did not explain well enough. I need to restrict a specifc user to say 2 specific NAS ports and then define a different account to some different specific NAS ports. Currently as long as an account is only ever going to use one NAS port I can restrict it by adding the entry to the radcheck table. So for example if I have 10 users, I have 10 entries with the NAS port and the == operator. However if I want to add some accounts with multiple entries then if I put more than one entry in radcheck for the same username then it never authenticates because I assume it is trying to ensure the user matches all entries which it obviously does not. If I use the += operator or := operators then it never seems to restrict but always authenticates no matter what the port is. I hope this explains what I am trying to do a little better. Regards Sean -- Sean Preston

Hi 2008/11/11 <tnt@kalik.net>:

...

I need to restrict a specifc user to say 2 specific NAS ports and then define a different account to some different specific NAS ports. Currently as long as an account is only ever going to use one NAS port I can restrict it by adding the entry to the radcheck table. So for example if I have 10 users, I have 10 entries with the NAS port and the == operator. However if I want to add some accounts with multiple entries then

.. use huntgroups.

Ok I think I understand what needs to be done. So the next question then is how do I setup huntgroups to be in the same database as everything else because as it stands it looks like it can only be a file and I am going to have hundreds of groups and it would be easier to manage in the database. Regards Sean -- Sean Preston

Sean Preston wrote:

Hi

2008/11/11 <tnt@kalik.net>:

...

...

I need to restrict a specifc user to say 2 specific NAS ports and then define a different account to some different specific NAS ports. Currently as long as an account is only ever going to use one NAS port I can restrict it by adding the entry to the radcheck table. So for example if I have 10 users, I have 10 entries with the NAS port and the == operator. However if I want to add some accounts with multiple entries then

.. use huntgroups.

Ok I think I understand what needs to be done. So the next question then is how do I setup huntgroups to be in the same database as everything else because as it stands it looks like it can only be a file and I am going to have hundreds of groups and it would be easier to manage in the database.

Regards Sean

I wrote documentation for how to implement huntgroups in SQL. It does require FreeRADIUS version 2.x because it depends on unlang. You won't need to modify FreeRADIUS 2.x, all you'll need to do is edit some config files and add a table to your database. The documentation is attached as a text file to this email. HTH, John -- John Dennis <jdennis@redhat.com> Howto Implment Huntgroups in SQL with FreeRADIUS 2.x John Dennis <jdennis@redhat.com> Huntgroups provide a mechanism to group NAS's into groups. Each NAS can be a member of a particular hunt group. When a user authentication request arrives you can then tag the request with the hunt group name the NAS is a member of. This is done by adding the attribute value pair <Huntgroup-Name,name> to the list of request pairs. During request processing the Huntgroup-Name attribute can be checked to make decisions about how to handle the request. For example you may want to restrict the authentication mechansim based on the type of NAS. Traditionally in FreeRADIUS huntgroups were implemented in the preprocess module (rlm_preprocess) which at start up read the configuration file /etc/raddb/huntgroups to associate each NAS with a huntgroup. But what if you want to configure FreeRADIUS to use SQL to store your data for users, groups, NAS's, etc? It would be awkward to have to rely on a flat file for huntgroups when everything else is in SQL. With the introduction of ulang in FreeRADIUS 2.0 it is easy to implement huntgroups using SQL. These are the following steps necessary. The example uses MySQL as the backend database, but it's easy to adjust for another SQL server. 1) Create a huntgroup table where we store each NAS and the huntgroup it is a member of, we'll call this table radhuntgroup. CREATE TABLE radhuntgroup ( id int(11) unsigned NOT NULL auto_increment, groupname varchar(64) NOT NULL default '', nasipaddress varchar(15) NOT NULL default '', nasportid varchar(15) default NULL, PRIMARY KEY (id), KEY nasipaddress (nasipaddress) ) ; 2) Populate the radhuntgroup table with your NAS information. For our example we'll add one NAS whose ip-address is 2.2.2.2 and put it in the huntgroup "foo". insert into radhuntgroup (groupname, nasipaddress) values ("foo", "2.2.2.2"); select * from radhuntgroup; +----+-----------+--------------+-----------+ | id | groupname | nasipaddress | nasportid | +----+-----------+--------------+-----------+ | 1 | foo | 2.2.2.2 | NULL | +----+-----------+--------------+-----------+ 3) Locate the authorize section in your radiusd.conf or sites-enabled/defaut configuration file and edit it. First make sure the preprocess module is not being called since we're providing the same functionality by other means. So either comment out the preprocess line or make sure it's absent altogether. Then at the top of the authorize section where the preprocess module would have been insert these lines: update request { Huntgroup-Name := "%{sql:select groupname from radhuntgroup where nasipaddress=\"%{NAS-IP-Address}\"}" } What this does is perform a lookup in the radhuntgroup table using the ip-address as a key to return the huntgroup name. It then adds an attribute/value pair to the request where the name of the attribute is Huntgroup-Name and it's value is whatever was returned from the SQL query. If the query did not find anything then the value is the empty string. Thats all you need to do. Now let's finsh the example by seeing how you might use the huntgroup information. Suppose you want to assure any user who is in the group FOO-AUTH-ONLY is coming in on a NAS for which FOO-AUTH is a requirement. You could use the group checking feature in the SQL module. Let's start by putting the user Bob in the FOO-AUTH-ONLY group. We do this by adding him in the radusergroup table: select * from radusergroup; +----------+----------------+----------+ | username | groupname | priority | +----------+----------------+----------+ | Bob | FOO-AUTH-ONLY | 0 | +----------+----------------+----------+ Then let's define a rule in the radgroupcheck table which says if the user is in the FOO-AUTH-ONLY group then they must have a Huntgroup-Name whose attribute is "foo". select * from radgroupcheck +----+----------------+----------------+----+----------+ | id | groupname | attribute | op | value | +----+----------------+----------------+----+----------+ | 1 | FOO-AUTH-ONLY | Huntgroup-Name | == | foo | +----+----------------+----------------+----+----------+ Now lets trace through the sequence of events. 1) A new request arrives, in the request are the following attribute/value pairs (along with other attribute/value pairs) <User-Name,"Bob"> <NAS-IP-Address,2.2.2.2> 2) The authorize section executes and the "update request" we added in step 3 performs a SQL query on the radhuntgroup table. The value 2.2.2.2 is substituted for the variable %{NAS-IP-Address} in the query string. This matches row 1 in our radhuntgroup table and the query returns "foo" as the huntgroup name. Then the request is updated with the attribute/value pair <Huntgroup-Name,"foo">. 3) Later the SQL modules runs. If group checking is enabled the first thing it does is lookup the user name in the radusergroup. In our example Bob is looked up and the group name FOO-AUTH-ONLY is returned. We now know Bob is in the FOO-AUTH-ONLY group. 4) Next the sql group check runs. The radgroupcheck table is consulted, for every group the user is a member of an <attribute,operator,value> tuple are returned and those are then compared to the attribute/value pairs in the request to see if there is a match by applying the operator to the value(s) found in the request to the value in the radgroupcheck row. In our example the radgroupcheck table has a row whose groupname is FOO-AUTH-ONLY which Bob is a member of, that row has an attribute called Huntgroup-Name. The request also has an attribute named Huntgroup-Name which was added earlier by our huntgroup table query. Because both the request and the radgroupcheck rule have an attribute named Huntgroup-Name their values are then evaluated with the operator in the rule (equality in this instance, e.g. ==) and since the operator test succeeds the radgroupcheck test succeeds.

Adrian wrote:

The Users file would look like this:

DEFAULT Huntgroup-Name == “Test_Group”

Authentication-Type = Accept, (*** this line no longer works in 2.1.1. It errors out with Invalid Octet string “Accept” for attribute name “Authentication-Type”)

Because that attribute doesn't exist. It has *never* existed. In 1.x, this invalid configuration would get silently ignored. In 2.x, you get an error. This tells you that the configuration doesn't do what you think it does.

In Freeradius 2.1.1 I’ve implemented the huntgroup table in the backend which works well (using mysql and the guide provided below by John.) I need to know how can I send the attributes above to the NAS based on the sql huntgroup match which I get back from the SQL query? I’ve tried to add a group in the radgroupreply table that sends back all necessary attributes however that did not work as the huntgroup was not being checked against the radgroupreply table.

The SQL "radgroup" defaults to be for user groups, not huntgroups.

Running radiusd –X I can see that the huntgroup is identified correctly and I get a ++ [request] returns ok from it however I’m not sure how to send it the above attributes from sql instead of the users flatfile.

See the "dialup.conf" file. The SQL queries for group queries are editable. You can change them to select based on huntgroups if you want. Alan DeKok.

In Freeradius 2.1.1 I've implemented the huntgroup table in the backend which works well (using mysql and the guide provided below by John.) I need to know how can I send the attributes above to the NAS based on the sql huntgroup match which I get back from the SQL query? I've tried to add a group in the radgroupreply table that sends back all necessary attributes however that did not work as the huntgroup was not being checked against the radgroupreply table.

No. It will be checked in radgroupcheck table. You should add Huntgroup-Name check there. Ivan Kalik Kalik Informatika ISP