[prev in list] [next in list] [prev in thread] [next in thread]
List: freeradius-users
Subject: RE: how to use groups within freeradius
From: "Ken Felix" <kfelix () jdltech ! com>
Date: 2011-06-28 13:31:45
Message-ID: 28DA477FD8C52F46AB0CFC87800FA47E05E81CFF () atlas ! jdltech ! com
[Download RAW message or body]
Phil
you examples was straight on, and very helpful. I ended up using SQLgroup within \
"/etc/freeradius/users + huntgrousps" and the groups that I've created & it worked \
the very 1st time, & with no problems. To answer your other question, this is with \
freeradius version;
root@TACACS:/etc/init.d# freeradius -v | grep Version
freeradius: FreeRADIUS Version 1.1.3, for host i486-pc-linux-gnu, built on Mar 30 \
2007 at 22:44:34 root@TACACS:/etc/init.d#
Thanks
-----Original Message-----
From: freeradius-users-bounces+kfelix=jdltech.com@lists.freeradius.org on behalf of \
Phil Mayers
Sent: Tue 6/28/2011 3:55 AM
To: freeradius-users@lists.freeradius.org
Subject: Re: how to use groups within freeradius
On 06/27/2011 09:29 PM, Ken Felix wrote:
>
> Can anybody post a simple howto with regards to using groups within
> freeradius? What we would like todo is restricted some user from
> logging into various firewalls. I've created usergroups and defined
>
Which version of FreeRADIUS are you using?
Anyway, the group config you've written doesn't do what you want. All it
says is "if you're this username and coming from these IPs, you're in
the gruop".
You're not actually acting in the group membership.
There are lots of ways to do this, but personally I prefer to keep SQL
groups entirely user-based, and use huntgroups for NAS IPs, then compare
the two. So:
raddb/huntgrousp:
restricted NAS-IP-Address == 192.0.2.1
raddb/sites-enabled/xxx:
authozie {
if (Huntgroup-Name == restricted) {
if (SQL-Group == "restricted") {
# ok to login
}
else {
reject
}
}
}
...or if you prefer to us a "users" file, in raddb/users:
DEFAULT Huntgroup-Name == restricted, SQL-Group == "restricted"
Fall-Through = No
DEFAULT Huntgroup-Name == restricted, Auth-Type := Reject
Fall-Through = No
There are lots of other ways to accomplish this. The point being, you
need to actually check the group, and if you define the group so that it
depends on the username, and they thing they're permitted to access,
then you're essentially writing a whitelist and would need something
like, in your example, raddb/users:
DEFAULT SQL-Group == xxx
Fall-Through = No
DEFAULT SQL-Group == yyy
Fall-Through = No
DEFAULT Auth-Type := Reject
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic