As you have observed, the first huntgroup that is matched will always be used. Its not a bug, or a feature, its just the way it is ;-) You can however specify more than one attribute to match per line, for example: xDSL NAS-IP-Address == 1.1.1.1, NAS-Port-Type == Async AdminA NAS-IP-Address == 1.1.1.1 would match xDSL only if NAS-Port-Type is Async, otherwise AdminA would match. As per the example huntgroups file provided in the release: # This file can also be used to define restricted access # to certain huntgroups. The second and following lines # define the access restrictions (based on username and # UNIX usergroup) for the huntgroup. you can restrict access to the huntgroup to certain users or groups: AdminA NAS-IP-Address == 1.1.1.1 User-Name = bob, Group = admin Means only User-Name "bob", or anyone in the "admin" group may access this huntgroup. You could try something like the above, with the AdminX groups defined before xDSL. Not sure if that would achieve what you desire... Give it a try and see how you go :-) regards, Mike
-----Original Message----- From: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of Lutz Petersen Sent: Wednesday, 22 June 2005 7:07 PM To: freeradius-users@lists.freeradius.org Subject: Huntgroups-Problem (bug or feature ?)
We have the following szenario, in which i got a problem:
We use huntgroups to allocate different types of dialins (isdn, dsl, and so on). So we have a huntgroups File which looks similar to this:
xDSL NAS-IP-Address == 1.1.1.1 xDSL NAS-IP-Address == 1.1.1.2 xDSL NAS-IP-Address == 1.1.1.3
Wireless-802.11 NAS-IP-Address == 1.1.2.1 Wireless-802.11 NAS-IP-Address == 1.1.2.2 Wireless-802.11 NAS-IP-Address == 1.1.2.3
and so on. Access is huntgroup based, and via Calling-Station-Id or NAS-Port-Type attributes and so on.
Now, we tried to make special groups for admin access on different servers. So we added some groups like
AdminA NAS-IP-Address == 1.1.1.1 AdminA NAS-IP-Address == 1.1.2.1
AdminB NAS-IP-Address == 1.1.1.3 AdminB NAS-IP-Address == 1.1.2.3
and so on. Reason was to get a radius based way which admin (group) will be allowed to get access on which NAS (additional to other restrictions).
Now, it doesn't work. As I checked out, it doesn't work when an ip address of a NAS was within the huntgroups file earlier for another group. So my question: is it ok not to build different huntgroups which contains in some cases servers with the same ip address ? Or other questioned - why ? That would be a nice feature. Ok, not an daily configuration scheme, but it would help to do some access restriction things.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html