Re: Any idea how to change attribute and not just the value?

[Guy Fraser]

That is not the way to do it. See below:

Max Ahston wrote:

I have been searching ideas the whole day by browsing the archives but 
I've not managed to solve my problem yet.

The setup: 

freeradius-snapshot-20040317 connected to pgsql. We have different nas:es 
(Tigris, Ascend and Cisco to name some).

Earlier the default DNS's was sent to the clients directly from the 
NAS-boxes. But later on we decided we wanted to set specific DNS entries 
for some users, otherwise the default DNS.

The problem is as follows, 

To set the DNS on the tigris, we have to send the following attributes:

       Acc-Dns-Server-Pri = 10.0.0.1,
       Acc-Dns-Server-Sec = 10.0.0.2,
But when we want to set them on the Ascend, this is the attributes we 
must send:

       Ascend-Client-Primary-DNS = 10.0.0.1,
       Ascend-Client-Secondary-DNS = 10.0.0.2,
So what I've tried now that _almost_ works (in 3 cases of 4 :) ) is that 
I've configured some huntgroups:

tigris          NAS-IP-Address == 192.168.100.1

ascend          NAS-IP-Address == 192.168.100.2

in the users file I've the following lines:

DEFAULT Huntgroup-Name == "tigris"
       Port-Limit = 2,
       Fall-Through = 1,
As far as I can recall Fall-Through must be the last entry.

       Login-Service = Rlogin,
       Login-Host = BESTHOST,
       Acc-Dns-Server-Pri = 10.0.0.1,
       Acc-Dns-Server-Sec = 10.0.0.2,
       Framed-Protocol = PPP,
       Framed-Routing = None
DEFAULT Huntgroup-Name == "ascend"
       Port-Limit = 2,
       Fall-Through = 1,
Same as previous.

       Login-Service = Rlogin,
       Login-Host = BESTHOST,
       Ascend-Client-Primary-DNS = 10.0.0.1,
       Ascend-Client-Secondary-DNS = 10.0.0.2,
       Framed-Protocol = PPP,
       Framed-Routing = None
The users gets verified in the SQL-database and the idea is to add the 
attributes for the users we want to set specific DNS's for in the radreply 
table.

So I've added the following to the radreply table:

id | username |          attribute          | op |  value   
----+----------+-----------------------------+----+----------
 1 | test     | Ascend-Client-Primary-DNS   | := | 10.0.0.3
 2 | test     | Ascend-Client-Secondary-DNS | := | 10.0.0.4

 

The default entries in the users table are not prepended nor appended to the
SQL entries. You will either need to do it all in the users file, or all 
in SQL.

When I act as the ascend NAS I get the answer I want from the 
radius-server the the Pri/Sec DNS set to .3 and .4.

It is the last entry.

But when I act as a Tigris and send a auth-req I get both the default 
Acc-Dns-Server entries and the Ascend-Client from the database

That is strange.

This is ofcourse as expected since this is how I configured the server, 
but not what I want in the end :)

I've checked out the attr_rewrite module but from what I've read and what 
I understand in the config, I can only use to to rewrite the value of a 
specific attribute?! 

Is there a way for me to rewrite the attribute itself and not just the 
value? 

One way to solve it is to run two different sql-questions against radreply 
if the request is from a tigris or ascend. Then I can use a stored proc. 
in pgsql to rewrite the attributes and leave the values intact.

Any ideas? 

Sincerely,

Max!
 

I think you are on the right path with the Hunt-Groups, but I have not 
seen it
implemented in SQL.

My guess would be to modify the SQL queries to use NAS specific 
information for
each query. Although there is a NAS table setup in the database it is 
not being used
yet. I have modified the NAS table in my test system to include IP, 
Make, Model,
Options, Lines, Pool Start IP, Pool Stop IP, Location, SNMP Read and few 
other
items. This lets me generate  reports with utilization per location and 
other helpfull
information. In your case you might want to add DNS entries. I have been
considering the creation of a new table called NAS_Group, so that most 
of the
data that is common can be linked to a NAS via a Group entry. You may 
want to
use a simmilar method. You don't nessarily have to group your NAS by 
Make, you
might want to group them by Location for proximity to your DNS servers 
or by some
other criteria. Using this data and the radreply and radgroupreply data 
you should be
able to generate the correct information that you want.

I think you have hit on a good point here, and it may be a good idea to 
expand the
general funcionality of the SQL queries to be able to include NAS and Realm
specific responces.

I have a number of different NAS types that I have to accomodate right 
now, but we
may be doing some wholesale changes heer in the near future that would 
make that
issue go away for me. I doubt I will have time to work on this in the 
near future, I have
a lot of data mining to do in order to figure out if we will be making 
big changes or not.

Have a nice day.

--
Guy Fraser




- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html