Sean Preston wrote:
Hi
2008/11/11 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>
Howto Implment Huntgroups in SQL with FreeRADIUS 2.x
John Dennis <[EMAIL PROTECTED]>
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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
