RE: rlm_sql and huntgroups
Thanks for your pointer Alan, i've searched the list at http://www.mail-archive.com/[EMAIL PROTECTED]/ but didn't come up with an answer. When I put the Huntgroup-Name attribute in my radreply table; everything works fine. When I put it in the radgroupreply table in the same fashion; it doesn't work thanks for any help to the solution Bart -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: maandag 8 december 2003 19:27 To: [EMAIL PROTECTED] Subject: Re: rlm_sql and huntgroups Bart Van Daal [EMAIL PROTECTED] wrote: is this a problem with hunt-groups or with all other check items in the mysql radgroupcheck table? It's a problem just with huntgroups. See the list archives for a description of the problem, and the solution. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_sql and huntgroups
Hello, I just wanted to know if there's any progress or solution for using huntgroups and rlm_sql? greets, Bart - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: rlm_sql and huntgroups
thanks, is this a problem with hunt-groups or with all other check items in the mysql radgroupcheck table? Bart -Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: maandag 8 december 2003 16:26 To: [EMAIL PROTECTED] Subject: Re: rlm_sql and huntgroups Bart Van Daal [EMAIL PROTECTED] wrote: I just wanted to know if there's any progress or solution for using huntgroups and rlm_sql? So far no patch has been posted that I've seen, so it seems to be a low priority. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_sql and huntgroups
Bart Van Daal [EMAIL PROTECTED] wrote: is this a problem with hunt-groups or with all other check items in the mysql radgroupcheck table? It's a problem just with huntgroups. See the list archives for a description of the problem, and the solution. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroups
Maybe I am using huntgroups wrong, but I would like huntgroup0 to use ports 1-8, huntgroup1 use ports 9-16 and huntgroup2 use ports 17-24 I am using mysql, and would like to keep using this as much as possible. I added username Huntgroup-Name == test1 to my radcheck table where username has its own entry for Password in that same table. I added test1 NAS-IP-Address == 192.168.69.24, NAS-Port-ID == 1-7 I all I get is a rejected pair when trying to log in. Should this all be in the DB somewhere? Any help? Anson Rinesmith Internet Operations Manager Big River Telephone Company 800-455-1608 x106 573-382-0555 www.bigrivertelephone.com Real People. Real Service. Real Simple. image001.jpg
huntgroups per usergroup
Hello List, I'm using mysql to authenticate all our users. I've set up a huntgroup which denies access based on called-station-id like this: hg called-station-id==3456778 hg called-station-id==1689988 hg called-station-id==9983789 Then i've added an record in the table radcheck: ++---+++--+ | id | UserName | Attribute | op | Value| ++---+++--+ | 3 | test | Huntgroup-Name | == | hg | | 2 | test | User-Password | == | guess| ++---+++--+ It works like a charm like this. BUT is there a way a can add the same record to the radgroupcheck table? I tried with ++--+++-+ | id | GroupName| Attribute | op | Value | ++--+++-+ | 8 | hgtest | Huntgroup-Name | := | hg | ++--+++-+ i've also tried '==' as an op but the users in the hgtestgroup always get authenticated. Thanks for any help :) Bart best regards Bart van Daal Tel + 32 3 780 74 80 www.edpnet.net EDPnet Technical Department EDPnet confidential proprietary business information - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_passwd and groups, huntgroups
Dear Cameron Slye, First, only one index (*) is allowed in file format and it must be near user-name. Second, rlm_passwd adds all attrbiutes to config_items, while huntgorups expects it to be in request (request_items). In order to add group name (as you was told it's better to use your own group attribute) to request_items instead of configure_items you must use ~ modificator for group attribute name. --Wednesday, November 5, 2003, 11:26:19 PM, you wrote to [EMAIL PROTECTED]: CS I am trying to setup freeradius to read a group file to allow people to CS use a huntgroup. If I setup the huntgroups file with User-Name = CS testuser it works, if I set it as Group or Group-Name = ssusers it fails. CS master.passwd file is authing correctly, that is not the issue. CS I have changed the order of the authorize section to have group_master CS before preprocess. I have removed the entire rlm_unix section, that CS solved the segfaulting, but still rejects request. CS I am using version 0.9.2 on FreeBSD 4.8 CS Below is the group file, huntgroup file, and a pruned radiusd -X output CS of a request. CS The interesting part.. It gets the group name, but then says no CS huntgroup access. CS rlm_passwd: Added Group-Name: 'ssusers' to config_items CSmodcall[authorize]: module group_master returns ok for request 0 CS No huntgroup access: [cslye] (from client test port 0) CSmodcall[authorize]: module preprocess returns reject for request 0 CS modcall: group authorize returns reject for request 0 CS Any ideas? Thanks.. Sorry for long email, hoping to include CS everything first time. CS Next thing I am going to try is putting all the rlm_unix stuff back and CS getting it to segfault again, on a --enable-developer build. CS group file: CS ssusers:testuser,testuser2,testuser3 CS huntgroup file: CS slipstream Called-Station-Id =~ 1856$ CS Group-Name = ssusers CS Below is the debug output. CS Starting - reading configuration files ... CS reread_config: reading radiusd.conf CS Module: Loaded passwd CS passwd: filename = /usr/local/etc/raddb/master.group CS passwd: format = *Group-Name:*,User-Name CS passwd: authtype = (null) CS passwd: delimiter = : CS passwd: ignorenislike = yes CS passwd: allowmultiplekeys = no CS passwd: hashsize = 100 CS rlm_passwd: nfields: 2 keyfield 1(User-Name) listable: yes CS Module: Instantiated passwd (group_master) CS Module: Loaded preprocess CS preprocess: huntgroups = /usr/local/etc/raddb/huntgroups CS preprocess: hints = /usr/local/etc/raddb/hints CS preprocess: with_ascend_hack = no CS preprocess: ascend_channels_per_line = 23 CS preprocess: with_ntdomain_hack = no CS preprocess: with_specialix_jetstream_hack = no CS preprocess: with_cisco_vsa_hack = no CS Module: Instantiated preprocess (preprocess) CS passwd: filename = /usr/local/etc/raddb/master.passwd CS passwd: format = *User-Name:Crypt-Password: CS passwd: authtype = pap CS passwd: delimiter = : CS passwd: ignorenislike = yes CS passwd: allowmultiplekeys = no CS passwd: hashsize = 100 CS rlm_passwd: nfields: 3 keyfield 0(User-Name) listable: no CS Module: Instantiated passwd (passwd_master) CS Module: Loaded files CS files: usersfile = /usr/local/etc/raddb/users CS files: acctusersfile = /usr/local/etc/raddb/acct_users CS files: preproxy_usersfile = /usr/local/etc/raddb/preproxy_users CS files: compat = no CS Module: Instantiated files (files) CS Ready to process requests. CS rad_recv: Access-Request packet from host XXX.XXX.XXX.XXX:2755, id=137, CS length=63 CS User-Name = testuser CS User-Password = passwd CS Framed-Protocol = PPP CS Called-Station-Id = 9162221856 CS modcall: entering group authorize for request 0 CS rlm_passwd: Added Group-Name: 'ssusers' to config_items CSmodcall[authorize]: module group_master returns ok for request 0 CS No huntgroup access: [cslye] (from client test port 0) CSmodcall[authorize]: module preprocess returns reject for request 0 CS modcall: group authorize returns reject for request 0 CS Delaying request 0 for 1 seconds CS Finished request 0 CS Going to the next request CS --- Walking the entire request list --- CS Waking up in 1 seconds... CS --- Walking the entire request list --- CS Waking up in 1 seconds... CS --- Walking the entire request list --- CS Sending Access-Reject of id 137 to XXX.XXX.XXX.XXX:2755 CS Waking up in 4 seconds... CS --- Walking the entire request list --- CS - CS List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- ~/ZARAZA , 2x2, . () - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_passwd and groups, huntgroups
That was it, thanks..
passwd group_master {
filename = ${raddbdir}/master.group
format = ~GM:::*,User-Name
I had =GM:::
3APA3A wrote:
Dear Cameron Slye,
First, only one index (*) is allowed in file format and it must be near
user-name. Second, rlm_passwd adds all attrbiutes to config_items, while
huntgorups expects it to be in request (request_items). In order to add
group name (as you was told it's better to use your own group attribute)
to request_items instead of configure_items you must use ~ modificator
for group attribute name.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_passwd and groups, huntgroups
I am trying to setup freeradius to read a group file to allow people to use a huntgroup. If I setup the huntgroups file with User-Name = testuser it works, if I set it as Group or Group-Name = ssusers it fails. master.passwd file is authing correctly, that is not the issue. I have changed the order of the authorize section to have group_master before preprocess. I have removed the entire rlm_unix section, that solved the segfaulting, but still rejects request. I am using version 0.9.2 on FreeBSD 4.8 Below is the group file, huntgroup file, and a pruned radiusd -X output of a request. The interesting part.. It gets the group name, but then says no huntgroup access. rlm_passwd: Added Group-Name: 'ssusers' to config_items modcall[authorize]: module group_master returns ok for request 0 No huntgroup access: [cslye] (from client test port 0) modcall[authorize]: module preprocess returns reject for request 0 modcall: group authorize returns reject for request 0 Any ideas? Thanks.. Sorry for long email, hoping to include everything first time. Next thing I am going to try is putting all the rlm_unix stuff back and getting it to segfault again, on a --enable-developer build. group file: ssusers:testuser,testuser2,testuser3 huntgroup file: slipstream Called-Station-Id =~ 1856$ Group-Name = ssusers Below is the debug output. Starting - reading configuration files ... reread_config: reading radiusd.conf Module: Loaded passwd passwd: filename = /usr/local/etc/raddb/master.group passwd: format = *Group-Name:*,User-Name passwd: authtype = (null) passwd: delimiter = : passwd: ignorenislike = yes passwd: allowmultiplekeys = no passwd: hashsize = 100 rlm_passwd: nfields: 2 keyfield 1(User-Name) listable: yes Module: Instantiated passwd (group_master) Module: Loaded preprocess preprocess: huntgroups = /usr/local/etc/raddb/huntgroups preprocess: hints = /usr/local/etc/raddb/hints preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = no preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = no Module: Instantiated preprocess (preprocess) passwd: filename = /usr/local/etc/raddb/master.passwd passwd: format = *User-Name:Crypt-Password: passwd: authtype = pap passwd: delimiter = : passwd: ignorenislike = yes passwd: allowmultiplekeys = no passwd: hashsize = 100 rlm_passwd: nfields: 3 keyfield 0(User-Name) listable: no Module: Instantiated passwd (passwd_master) Module: Loaded files files: usersfile = /usr/local/etc/raddb/users files: acctusersfile = /usr/local/etc/raddb/acct_users files: preproxy_usersfile = /usr/local/etc/raddb/preproxy_users files: compat = no Module: Instantiated files (files) Ready to process requests. rad_recv: Access-Request packet from host XXX.XXX.XXX.XXX:2755, id=137, length=63 User-Name = testuser User-Password = passwd Framed-Protocol = PPP Called-Station-Id = 9162221856 modcall: entering group authorize for request 0 rlm_passwd: Added Group-Name: 'ssusers' to config_items modcall[authorize]: module group_master returns ok for request 0 No huntgroup access: [cslye] (from client test port 0) modcall[authorize]: module preprocess returns reject for request 0 modcall: group authorize returns reject for request 0 Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 137 to XXX.XXX.XXX.XXX:2755 Waking up in 4 seconds... --- Walking the entire request list --- - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_passwd and groups, huntgroups
Cameron Slye [EMAIL PROTECTED]wrote: I am trying to setup freeradius to read a group file to allow people to use a huntgroup. If I setup the huntgroups file with User-Name = testuser it works, if I set it as Group or Group-Name = ssusers it fails. Group or Group-Name are for checking the /etc/group file. If you want to use rlm_passwd to define *another* file for group entries, then create a new attribute, and use that. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_passwd and groups, huntgroups
I have made one called Group-Name-GM, added it to the dictionary, and it does the same thing. rad_recv: Access-Request packet from host 209.210.251.61:3065, id=154, length=63 User-Name = testuser User-Password = password Framed-Protocol = PPP Called-Station-Id = 9162221856 modcall: entering group authorize for request 0 rlm_passwd: Added Group-Name-GM: 'ssusers' to config_items modcall[authorize]: module group_master returns ok for request 0 No huntgroup access: [testuser] (from client test port 0) modcall[authorize]: module preprocess returns reject for request 0 modcall: group authorize returns reject for request 0 Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 154 to XXX.XXX.XXX.XXX:3065 Module: Loaded passwd passwd: filename = /usr/local/etc/raddb/master.group passwd: format = *Group-Name-GM:*,User-Name passwd: authtype = (null) passwd: delimiter = : passwd: ignorenislike = yes passwd: allowmultiplekeys = no passwd: hashsize = 100 rlm_passwd: nfields: 2 keyfield 1(User-Name) listable: yes Module: Instantiated passwd (group_master) Alan DeKok wrote: Cameron Slye [EMAIL PROTECTED]wrote: I am trying to setup freeradius to read a group file to allow people to use a huntgroup. If I setup the huntgroups file with User-Name = testuser it works, if I set it as Group or Group-Name = ssusers it fails. Group or Group-Name are for checking the /etc/group file. If you want to use rlm_passwd to define *another* file for group entries, then create a new attribute, and use that. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_passwd and groups, huntgroups
I have tried using the example config with no luck also. I have tried
GM instead of Group-Name. I dont know what else to try.. Any ideas?
passwd group_master {
filename = ${raddbdir}/master.group
format = =Group-Name:::*,User-Name
hashsize = 50
ignorenislike = yes
allowmultiplekeys = yes
delimiter = :
}
Cameron Slye wrote:
I have made one called Group-Name-GM, added it to the dictionary, and it
does the same thing.
rad_recv: Access-Request packet from host 209.210.251.61:3065, id=154,
length=63
User-Name = testuser
User-Password = password
Framed-Protocol = PPP
Called-Station-Id = 9162221856
modcall: entering group authorize for request 0
rlm_passwd: Added Group-Name-GM: 'ssusers' to config_items
modcall[authorize]: module group_master returns ok for request 0
No huntgroup access: [testuser] (from client test port 0)
modcall[authorize]: module preprocess returns reject for request 0
modcall: group authorize returns reject for request 0
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 154 to XXX.XXX.XXX.XXX:3065
Module: Loaded passwd
passwd: filename = /usr/local/etc/raddb/master.group
passwd: format = *Group-Name-GM:*,User-Name
passwd: authtype = (null)
passwd: delimiter = :
passwd: ignorenislike = yes
passwd: allowmultiplekeys = no
passwd: hashsize = 100
rlm_passwd: nfields: 2 keyfield 1(User-Name) listable: yes
Module: Instantiated passwd (group_master)
Alan DeKok wrote:
Cameron Slye [EMAIL PROTECTED]wrote:
I am trying to setup freeradius to read a group file to allow people to
use a huntgroup. If I setup the huntgroups file with User-Name =
testuser it works, if I set it as Group or Group-Name = ssusers it
fails.
Group or Group-Name are for checking the /etc/group file. If
you want to use rlm_passwd to define *another* file for group entries,
then create a new attribute, and use that.
Alan DeKok.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroups sql
is it possible to do the following via SQL? given a huntgroups file that contains: netscreen NAS-IP-Address == 128.205.10.75 ccfw-beane NAS-IP-Address == 128.205.10.76 construct SQL entries that function the same as the following users file entries: jcmurphy Auth-Type := UNIX, Huntgroup-Name == netscreen NS-User-Group = Off-Campus, NS-User-Group += On-Campus jcmurphy Auth-Type := UNIX, Huntgroup-Name == ccfw-beane NS-User-Group = beane1 from what i can tell, you cant, but i'd like some confirmation of that before i start to consider what i'd have to do to rlm_sql to make it work. jeff - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with huntgroups
Hi Alan, i solve my problem: i don't know why, but when i make RPM, radius don't start (due to error with huntgroups), but when i try install from tgz (with compilation and installation) all works fine! Thaks, bye Marian Alan DeKok napsal(a): Marian Rychtecky [EMAIL PROTECTED] wrote: i have some problem with starting FRS (free-radius-server) FRS? Why are you inventing new acronyms that no one else uses? rlm_preprocess: Error reading /etc/raddb/huntgroups radiusd.conf[877]: preprocess: Module instantiation failed. Rights of /etc/raddb/huntgroups: -rw-r--r--1 root root 1863 Oct 18 22:08 huntgroups Nothing was change (content of huntgroups after installation are "#" comment with no configuration), still run "raddb -xx" ! Are you *sure*? I strongly doubt that. The huntgroup file which ships with the server works with the server. If it doesn't work for you, then you've modified it. On Internet i found (as content of huntgroups): "DEFAULT NAS-IP-Address = 11.10.10.11, Rewrite-Function = "max_fixup" NULL" .but this is not work too (same error). That's a file from GNU Radiusd, which isn't compatible with FreeRADIUS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Marian Rychteck [EMAIL PROTECTED] +420 603 373 396 Na Pin 281 405 05 Dn, Czech Republic http://www.mari.cz
Huntgroups and IPPOOL allocation based on NAS Request
Hi Currently attempting to set-up multiple ippools, which are correctly assigned due to the NAS making the request. --start huntgroups- llgcis01-hunt NAS-IP-Address == 127.0.0.1 btsurf01-hunt NAS-IP-Address == 10.1.1.100 ---end huntgroups ---start users DEFAULT Huntgroup-Name == llgcis01-hunt, Pool-Name := llgcis01 Fall-Through = Yes DEFAULT Huntgroup-Name == btsurf01-hunt, Pool-Name := btsurf01 Fall-Through = Yes q4xvzfm0 Auth-Type := Local, User-Password ==5e7lvwqh ---end users- When using radtest, no dynamic ip is allocated rad_recv: Access-Request packet from host 127.0.0.1:1968, id=235, length=60 User-Name = q4xvzfm0 User-Password = 5e7lvwqh NAS-IP-Address = 255.255.255.255 NAS-Port = 10 modcall: entering group authorize modcall[authorize]: module preprocess returns ok modcall[authorize]: module chap returns noop modcall[authorize]: module mschap returns noop rlm_realm: No '@' in User-Name = q4xvzfm0, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop users: Matched q4xvzfm0 at 7 modcall[authorize]: module files returns ok modcall: group authorize returns ok rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [q4xvzfm0] (from client localhost port 10) modcall: entering group post-auth rlm_ippool: Could not find Pool-Name attribute. modcall[post-auth]: module llgcis01 returns noop rlm_ippool: Could not find Pool-Name attribute. modcall[post-auth]: module btsurf01 returns noop modcall: group post-auth returns noop Sending Access-Accept of id 235 to 127.0.0.1:1968 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 235 with timestamp 3f8bceb2 Nothing to do. Sleeping until we see a request. Although if I change the users file to be ( the difference being huntgoup := ) ---start users DEFAULT Huntgroup-Name := llgcis01-hunt, Pool-Name := llgcis01 Fall-Through = Yes DEFAULT Huntgroup-Name := btsurf01-hunt, Pool-Name := btsurf01 Fall-Through = Yes q4xvzfm0 Auth-Type := Local, User-Password ==5e7lvwqh ---end users--- An Ip Pool Address is returned, although from the incorrect pool. Since the radtest is from 127.0.0.1, I would expect that the correct huntgroup llgcis01-hunt determined and hence an ip address being returned from the correct pool. Any help would be appreciated. --Jim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroups phrasing via SQL
i'm trying to figure out how to create the appropriate records (in mysql) that will achieve the same results as the following users entries: jcm004 Auth-Type := Local, User-Password == jcm004, Huntgroup-Name == huntgroup1 NS-User-Group = dev1, jcm004 Auth-Type := Local, User-Password == jcm004, Huntgroup-Name == huntgroup2 NS-User-Group = dev2 huntgroups 1 2 simply map to individual devices (one device in each hunt group). the ultimate goal is to be able to place the user into different groups depending upon which device they connect to. i was able to do this via the 'users' file, but i'm having trouble figuring how what i need to insert into the sql tables. hints? thanks! jeff - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [bug?] [gdb trace] Segmentation fault when using huntgroups
Rens Houben [EMAIL PROTECTED] wrote: The chain of functions in rlm_preprocess should pass a REQUEST* data structure, too. So why didn't it? Because no one made it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [bug?] [gdb trace] Segmentation fault when using huntgroups
In other news for Fri, Oct 03, 2003 at 10:01:36AM -0400, Alan DeKok has been seen typing: Rens Houben [EMAIL PROTECTED] wrote: So why didn't it? Because no one made it. Okay, so is this a configuration error on my part (and if so, where do I start looking to fix it?) or a bug in freeradius? Alan DeKok. -- Rens Houben |opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP key at http://swordbreaker.systemec.nl/~shadur/shadur.key.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [bug?] [gdb trace] Segmentation fault when using huntgroups
[EMAIL PROTECTED] (Rens Houben) wrote: Because no one made it. Okay, so is this a configuration error on my part (and if so, where do I start looking to fix it?) or a bug in freeradius? It's a bug in the server. As for how to fix it, I already said that in one of my earlier posts: Look at the stack trace, and make the functions in rlm_preprocess pass a REQUEST*, if they don't already. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[bug?] [gdb trace] Segmentation fault when using huntgroups
I've been working with Freeradius for some time now, and for some reason
whenever I tried to configure huntgroups, a segfault occurred. Recently
I got back to work on it and got around to pushing the unstripped
version through gdb, as well as adding an insane number of extra DEBUG2
statements through the code until I found the exact point where it
broke.
This error occurs when the calling IP address matches an entry in the
huntgroups, regardless of any other information in the database.
I've included the GDB trace from a pristine 0.9.1 debuild below, with
sections I believe to be irrelevant snipped for brevity, and sensitive
details censored for security's sake. The full (but censored) output can
be found at http://hiryuu.systemec.nl/~shadur/radius/gdblog.txt .
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-linux...
(gdb) run
Starting program: /usr/sbin/freeradius -X
Starting - reading configuration files ...
reread_config: reading radiusd.conf
Config: including file: /etc/freeradius/proxy.conf
Config: including file: /etc/freeradius/clients.conf
Config: including file: /etc/freeradius/snmp.conf
Config: including file: /etc/freeradius/sql.conf
{reading lots of config entries}
Module: Loaded preprocess
preprocess: huntgroups = /etc/freeradius/huntgroups
preprocess: hints = /etc/freeradius/hints
preprocess: with_ascend_hack = no
preprocess: ascend_channels_per_line = 23
preprocess: with_ntdomain_hack = no
preprocess: with_specialix_jetstream_hack = no
preprocess: with_cisco_vsa_hack = no
Module: Instantiated preprocess (preprocess)
Module: Loaded realm
realm: format = suffix
realm: delimiter = @
Module: Instantiated realm (suffix)
Module: Loaded SQL
sql: driver = rlm_sql_mysql
sql: server = deleted
sql: port =
sql: login = deleted
sql: password = deleted
sql: radius_db = radius
sql: acct_table = radacct
sql: acct_table2 = radacct
sql: authcheck_table = radcheck
sql: authreply_table = radreply
sql: groupcheck_table = radgroupcheck
sql: groupreply_table = radgroupreply
sql: usergroup_table = usergroup
sql: nas_table = nas
sql: dict_table = dictionary
sql: sqltrace = no
sql: sqltracefile = /var/log/freeradius/sqltrace.sql
sql: deletestalesessions = yes
sql: num_sql_socks = 5
sql: sql_user_name = %{User-Name}
sql: default_user_profile =
sql: query_on_not_found = no
rlm_sql (sql): Driver rlm_sql_mysql (module rlm_sql_mysql) loaded and linked
rlm_sql (sql): Attempting to connect to deleted@deleted:/radius
rlm_sql (sql): starting 0
rlm_sql (sql): Attempting to connect rlm_sql_mysql #0
rlm_sql_mysql: Starting connect to MySQL server for #0
rlm_sql (sql): Connected new DB handle, #0
rlm_sql (sql): starting 1
rlm_sql (sql): Attempting to connect rlm_sql_mysql #1
rlm_sql_mysql: Starting connect to MySQL server for #1
rlm_sql (sql): Connected new DB handle, #1
rlm_sql (sql): starting 2
rlm_sql (sql): Attempting to connect rlm_sql_mysql #2
rlm_sql_mysql: Starting connect to MySQL server for #2
rlm_sql (sql): Connected new DB handle, #2
rlm_sql (sql): starting 3
rlm_sql (sql): Attempting to connect rlm_sql_mysql #3
rlm_sql_mysql: Starting connect to MySQL server for #3
rlm_sql (sql): Connected new DB handle, #3
rlm_sql (sql): starting 4
rlm_sql (sql): Attempting to connect rlm_sql_mysql #4
rlm_sql_mysql: Starting connect to MySQL server for #4
rlm_sql (sql): Connected new DB handle, #4
Module: Instantiated sql (sql)
{ More snippage }
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp.
Ready to process requests.
rad_recv: Access-Request packet from host 111.222.333.444:45695, id=118, length=48
User-Name = testuser
User-Password = zronk
modcall: entering group authorize
[New Thread 16384 (LWP 22237)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 22237)]
0x40440333 in groupcmp (instance=0x0, req=0x0, request=0x811df28, check=0x810a1c8,
check_pairs=0x810a1c8, reply_pairs=0x0) at rlm_unix.c:215
215 if (!req-username) {
(gdb)
(gdb) backtrace
#0 0x40440333 in groupcmp (instance=0x0, req=0x0, request=0x811df28, check=0x810a1c8,
check_pairs=0x810a1c8, reply_pairs=0x0) at rlm_unix.c:215
#1 0x08050a46 in paircompare (req=0x0, request=0x811df28, check=0x810a1c8,
check_pairs=0x810a1c8,
reply_pairs=0x0) at valuepair.c:97
#2 0x08050c9a in paircmp (req=0x0, request=0x811df28, check=0x810a1c8, reply=0x0) at
valuepair.c:304
#3 0x40295192 in hunt_paircmp (request=0x811df28, check=0x810a1c8) at
rlm_preprocess.c:266
#4 0x4029579c in huntgroup_access (huntgroups=0x810a060, request_pairs=0x811df28)
at rlm_preprocess.c:534
#5 0x40295b79
Re: [bug?] [gdb trace] Segmentation fault when using huntgroups
[EMAIL PROTECTED] (Rens Houben) wrote: This error occurs when the calling IP address matches an entry in the huntgroups, regardless of any other information in the database. The issue appears to be that the entry in the 'huntgroups' file is doing a comparison using the 'Group' attribute. It looks like that's not supported... I've included the GDB trace from a pristine 0.9.1 debuild below, with sections I believe to be irrelevant snipped for brevity, and sensitive details censored for security's sake. The full (but censored) output can be found at http://hiryuu.systemec.nl/~shadur/radius/gdblog.txt . The issue is that the paircmp() call in hunt_paircmp(), of rlm_preprocess, passes a NULL for the REQUEST* data structure. It shouldn't. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [bug?] [gdb trace] Segmentation fault when using huntgroups
In other news for Thu, Oct 02, 2003 at 02:37:41PM -0400, Alan DeKok has been seen typing: [EMAIL PROTECTED] (Rens Houben) wrote: This error occurs when the calling IP address matches an entry in the huntgroups, regardless of any other information in the database. The issue appears to be that the entry in the 'huntgroups' file is doing a comparison using the 'Group' attribute. It looks like that's not supported... I'm not sure if it's what you mean, but the Huntgroup-Name == 'hiryuu' directive is part of the radgroupcheck table rather than radcheck. I've included the GDB trace from a pristine 0.9.1 debuild below, with sections I believe to be irrelevant snipped for brevity, and sensitive details censored for security's sake. The full (but censored) output can be found at http://hiryuu.systemec.nl/~shadur/radius/gdblog.txt . The issue is that the paircmp() call in hunt_paircmp(), of rlm_preprocess, passes a NULL for the REQUEST* data structure. It shouldn't. I'm aware of that. I'm wondering why, but that traceback's about as far as I got. Alan DeKok. Rens. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [bug?] [gdb trace] Segmentation fault when using huntgroups
Rens Houben [EMAIL PROTECTED] wrote: The issue is that the paircmp() call in hunt_paircmp(), of rlm_preprocess, passes a NULL for the REQUEST* data structure. It shouldn't. I'm aware of that. I'm wondering why, but that traceback's about as far as I got. The chain of functions in rlm_preprocess should pass a REQUEST* data structure, too. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [bug?] [gdb trace] Segmentation fault when using huntgroups
In other news for Thu, Oct 02, 2003 at 04:42:17PM -0400, Alan DeKok has been seen typing: Rens Houben [EMAIL PROTECTED] wrote: I'm aware of that. I'm wondering why, but that traceback's about as far as I got. The chain of functions in rlm_preprocess should pass a REQUEST* data structure, too. So why didn't it? Alan DeKok. - Rens - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Huntgroups Problem
Hi everyone, I have encountered strange problem lately, and i don't know how to manage it Here what happens: I got users defined in /etc/passwd and /etc/shadow, additionaly there is a mirror in radius users file as follows (OS is the Sun OS 7) /etc/passwd aloboda:x:1001:101:Adam Loboda, Admin., inz. eks., IZO, Warszawa:/export/home/aloboda:/bin/sh /etc/shadow aloboda:M/xTQF/Kys9Rg::: additionaly there is a /etc/group file : warszawa::104:aloboda,grzes,mariusz,zbyszek,szczepan,pgrubek,mirek,michal,muki,chabrosj,goral,wosik,krisbo,daniel,daras,mariuszc,marior,mchorazy,marcinsw,starcu,backup,ania,pawlo,darek,kania,kobe,hania,dagma,kasiar,elan,mgudzak,kasiac,rafal,marekk,jkawka,mistar,pkowalcz,polpak,mkozak,wdrozenia,mariuszg katowice::105:kupkap,jacek,adam,mistela,opole_k,opole_m,backup,kamilaf,kkrystek,marekk,michalc,przemekz,mariuszw,rafald,robertp,marcins,irekp,piotro,teresap,saymon,ania,pawlo,darek,kania,kobe,hania,dagma,kasiar,elan,mgudzak,kasiac,rafal,katowice,jkawka,szczepan,polpak,aloboda,mkozak,wdrozenia lublin::111:jzuk,mkozak,mistar,tmalyska,jkusinsk,mmazur,pgrom,mtomczyk,backup,ania,pawlo,darek,kania,kobe,hania,dagma,kasiar,elan,mgudzak,kasiac,rafal,jkawka,aloboda,szczepan,marekk,mkozak,wdrozenia krakow::113:bolekg,irzenski,andrew,backup,ania,pawlo,darek,kania,kobe,hania,dagma,kasiar,elan,mgudzak,kasiac,rafal,jkawka,szczepan,polpak,aloboda,marekk,mkozak,wdrozenia,michalc,marekk cpd::114:jbanas,pioboche,pignaczak,kolasae,myrtap,mpaudyn,aloboda test::117:aloboda In radius 'users' file i have declared # Adam Loboda aloboda Auth-Type := System, Huntgroup-Name == "gdansk" Service-Type = Shell-User, cisco-avpair = "shell:priv-lvl=15" aloboda Auth-Type := System, Huntgroup-Name == "warszawa" Service-Type = Shell-User, cisco-avpair = "shell:priv-lvl=7" aloboda Auth-Type := System, Huntgroup-Name == "lublin" Service-Type = Shell-User, cisco-avpair = "shell:priv-lvl=1" so that user 'aloboda' could log in to few NASes in different huntgroups with different Cisco privilege levels (notice cisco-avpairs) But regardless of that definition, RADIUS always takes into consideration definition of group from /etc/group (i dont want it to do it) only, it ignores the users 'Huntgroup-Name' condition, if the user is not placed in proper group in the /etc/group file. In result, the user 'aloboda' cannot log in to a NAS from Huntgroup called 'gdansk', because he in not assigned to this group in the /etc/group file. It receives a huntgroup reject. How to configure RADIUS to authenticate users against unix files (Auth-Type := System) and ignore /etc/group definitions??? Please HELP Adam Loboda Polish TELCO
FreeRADIUS+SQL: Huntgroups + Concunency checks
Two questions... 1) I want to check that users are allowed access to NASs based on where the NAS is located (We are a WISP providing access at several apartment complexes) my huntgroups file looks like... # Apartment complex 1 PBNAS-IP-Address == 10.1.2.90 PBNAS-IP-Address == 10.1.2.91 PBNAS-IP-Address == 10.1.2.92 PBNAS-IP-Address == 10.1.2.93 # Apartment complex 2 AANAS-IP-Address == 10.1.3.90 AANAS-IP-Address == 10.1.3.91 that, along with more of the same. so, users at apartment complex 1 are assigned to a group, and that group is allowed to connect to Access Points at Apartment Complex 1, but not at Apartment Complex 2 Simmalar thing for Apartment Complex 2 If possible, out testing exipment will be in yet another group allowed to connect to either Apartment Complex 1 or 2 (hope this makes sense...) Acording to the huntgroups file, I would use Huntgroup-Name == name, which I thought should go in my radgroupreply table, and when I tried it it did not work (Access was allowed universaly) Any thoughts? What am I doing wrong? 2) How do I go about setting up concunrcy checking, so that people cannot clone MAC addresses? I'm also a little woried about users roaming or not cleanly disconnecting and getting rejected because it looks like they are connected twice. -- Ryan Castellucci (530) 757-4686 x22 SoliSys LLC - http://www.solisys.com/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroups
Has anyone on the list had an abnormal amount of huntgroups. I am writing a virtual ISP type of application and I was curious to see if anyone had any undesirable results with this formula. I am guessing I could have thousands of hunt groups. Maybe I should just modify free radius to process huntgroups in a SQL database? Or is that possible already and I have overlooked it somewhere. TIA Jeremy - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroups question
Hi list, I read from http://www.onlamp.com/pub/a/onlamp/excerpt/radius_5/index1.html?page=2: ...a huntgroup can be a set of ports, a specific piece of RADIUS client equipment, or a set of calling station IDs that you want to separate from other ports. But i can't find exactly the docs for setting things up based on the calling station id, can anyone point me to the docs ? Regards, -- Olivier - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: huntgroups in users file
On Thu, 2003-06-19 at 10:05, gunce ciftci wrote: Hi All, I am stuck at a point while configuring FreeRadius 0.8.1 for a pool of NAS's and annex's. I want to give a group of admin users such ip's that they are above 10.0.0.100 and won't be affected by simultaneous-use parameter. My users and huntgroups file are below (ip's are changed) users: --- DEFAULT Huntgroup-Name==admin, Auth-Type :=System User-Service-Type = NAS-Prompt-User, Framed-IP-Address = 10.0.0.100+, ^ That comma shouldn't be there, can't find any other errors... Chris DEFAULT Auth-Type :=System, BSimultaneous-Use:=1 User-Service-Type = NAS-Prompt-User, Framed-IP-Address = 10.0.0.1+ huntgroups: --- admin NAS-IP-Address == A.B.C.D User-Name = gunce, User-Name = gciftci However, when a user, other than gunce and gciftci logs in to A.B.C.D, (ahmet logs in) radiusd -X says and gives 10.0.0.100+ .. modcall: entering group authorize modcall[authorize]: module preprocess returns ok huntgroups: Matched admin at 2 users: Matched DEFAULT at 1 modcall[authorize]: module files returns ok modcall: group authorize returns ok rad_check_password: Found Auth-Type System auth: type System modcall: entering group authenticate modcall[authenticate]: module unix returns ok modcall: group authenticate returns ok Login OK: [ahmet] (from client ras port 32 cli [03334445566) Sending Access-Accept of id 149 to A.B.C.D:4504 User-Service-Type = NAS-Prompt-User Framed-IP-Address = 10.0.0.100+ Finished request 2 .. I could not figure out what is the wrong thing, could anybody point me please? Is it related with my understanding of huntgroups or users file? Regards, - Gunce - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroups in users file
Hi All, I am stuck at a point while configuring FreeRadius 0.8.1 for a pool of NAS's and annex's. I want to give a group of admin users such ip's that they are above 10.0.0.100 and won't be affected by simultaneous-use parameter. My users and huntgroups file are below (ip's are changed) users: --- DEFAULT Huntgroup-Name==admin, Auth-Type :=System User-Service-Type = NAS-Prompt-User, Framed-IP-Address = 10.0.0.100+, DEFAULT Auth-Type :=System, BSimultaneous-Use:=1 User-Service-Type = NAS-Prompt-User, Framed-IP-Address = 10.0.0.1+ huntgroups: --- admin NAS-IP-Address == A.B.C.D User-Name = gunce, User-Name = gciftci However, when a user, other than gunce and gciftci logs in to A.B.C.D, (ahmet logs in) radiusd -X says and gives 10.0.0.100+ .. modcall: entering group authorize modcall[authorize]: module preprocess returns ok huntgroups: Matched admin at 2 users: Matched DEFAULT at 1 modcall[authorize]: module files returns ok modcall: group authorize returns ok rad_check_password: Found Auth-Type System auth: type System modcall: entering group authenticate modcall[authenticate]: module unix returns ok modcall: group authenticate returns ok Login OK: [ahmet] (from client ras port 32 cli [03334445566) Sending Access-Accept of id 149 to A.B.C.D:4504 User-Service-Type = NAS-Prompt-User Framed-IP-Address = 10.0.0.100+ Finished request 2 .. I could not figure out what is the wrong thing, could anybody point me please? Is it related with my understanding of huntgroups or users file? Regards, - Gunce - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Regexp in huntgroups file
On Tue, Jan 21, 2003 at 05:03:30AM -0500, Alan DeKok wrote: Nils =?ISO-8859-1?Q?R=F8nhovde?= [EMAIL PROTECTED] wrote: If I have a group of NAS'es in the address-range 10.1.1.0-32, how should I express this in a single statement i the huntgroups file. My best idea is like this testNAS-Ip-Address =~ ^10\.1\.1\.[0-32] Regular expressions are over *characters*, not *numbers*. Try: test NAS-IP-Address =~ ^10\.1\.1\.(0|1[0-9]?|2[0-9]?|3[0-2]?|[4-9]) Looks slightly unreadable, doesn't it? :) Alan, how about to implement a few operators on IP's? E.g., '' for 'is contained within', so, in this case: NAS-IP-Address 10.1.1.0/27. -- Fduch M. Pravking - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Regexp in huntgroups file
Nils =?ISO-8859-1?Q?R=F8nhovde?= [EMAIL PROTECTED] wrote: If I have a group of NAS'es in the address-range 10.1.1.0-32, how should I express this in a single statement i the huntgroups file. My best idea is like this test NAS-Ip-Address =~ ^10\.1\.1\.[0-32] Regular expressions are over *characters*, not *numbers*. Try: testNAS-IP-Address =~ ^10\.1\.1\.(0|1[0-9]?|2[0-9]?|3[0-2]?|[4-9]) You've got to specify all possible character representations. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
HInts, Huntgroups and Users Files
Title: HInts, Huntgroups and Users Files Good morning, I am very new to Radus Server and especially new to freeradius. I have inherited a very old Ascend Radius Server that is running on a SUN box. I want to move this to Linux and run it under freeradius. The USERS file on the Sun box is just a flat text file, which contains the usernames, passwords, and attributes such as Framed-Protocol, Filter-ID, etc., but it appears that freeradius handles thing differently. If the username and passwords are not placed in the users file, then where are they put. The "How the USERS file is processed" states "After the items of a request have been mangled by the "hints" and "huntgroups" files, the users file is processed." What does this mean? Do I put the username and passwords in the "hints" file or what? Can anyone help me out here? Thanks Ken
Re: HInts, Huntgroups and Users Files
At 08:46 AM 12/9/2002 -0800, Miller, Kenneth L NWP wrote: Good morning, I am very new to Radus Server and especially new to freeradius. I have inherited a very old Ascend Radius Server that is running on a SUN box. I want to move this to Linux and run it under freeradius. The USERS file on the Sun box is just a flat text file, which contains the usernames, passwords, and attributes such as Framed-Protocol, Filter-ID, etc., but it appears that freeradius handles thing differently. If the username and passwords are not placed in the users file, then where are they put. The How the USERS file is processed states After the items of a request have been mangled by the hints and huntgroups files, the users file is processed. What does this mean? Do I put the username and passwords in the hints file or what? No, it uses a users file in the same way as your old Ascend Radius server. It has the additional files hints and huntgroups which *may* be used, but are definitely not required in a basic config. In fact, if you aren't using them, comment their contents out entirely. You should be able to modify the Ascend users file to be used under FreeRADIUS. Note that the syntax is slightly different under FreeRADIUS and that some of the attribute names may be changed slightly. IE: Framed-Address becomes Framed-IP-Address under FreeRADIUS. If your Ascend file looks like: someuserPassword = letmein Framed-Address = 255.255.255.254 Framed-Netmask = 255.255.255.255 ... You could convert it to FreeRADIUS syntax: someuserAuth-Type := LOCAL, User-Password == letmein Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 ( note the 'operators'; :=, ==, =; have different meanings )! Hope this helps, -Chris -- \\\|||/// \ StarNet Inc. \ Chris Parker \ ~ ~ / \ WX *is* Wireless!\ Director, Engineering | @ @ |\ http://www.starnetwx.net \ (847) 963-0116 oOo---(_)---oOo--\-- \ Wholesale Internet Services - http://www.megapop.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HInts, Huntgroups and Users Files
if you installed freeradius into linux then look at man 5 users if you still have questions then you are welcome to send email =) PS. also see the sample users file which came with freeradius Evren On Mon, 9 Dec 2002, Miller, Kenneth L NWP wrote: Good morning, I am very new to Radus Server and especially new to freeradius. I have inherited a very old Ascend Radius Server that is running on a SUN box. I want to move this to Linux and run it under freeradius. The USERS file on the Sun box is just a flat text file, which contains the usernames, passwords, and attributes such as Framed-Protocol, Filter-ID, etc., but it appears that freeradius handles thing differently. If the username and passwords are not placed in the users file, then where are they put. The How the USERS file is processed states After the items of a request have been mangled by the hints and huntgroups files, the users file is processed. What does this mean? Do I put the username and passwords in the hints file or what? Can anyone help me out here? Thanks Ken - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
HInts, Huntgroups and Users Files
Title: HInts, Huntgroups and Users Files Good morning, I have been reading the documentation and information contained in the Hints, Huntgroups and Users files. I have also read the file on how the USERS file is processed. It states, "After the items of a request have been mangled by the "hints" and "huntgroups" files, the users file is processed." I've looked at the "Hints" file and the information there is very ambiguous. It states "A special non-protocol name value pair called "Hint" can be set to match on in the "users" file." Does this mean that I can set the "Hint = " value to anything?, say like the first letters of a user-name? Then, Do I have to put the "Hints = " value in the "Huntgroups" file under the Huntgroup name? Example: Huntgroup1 User-name = XYZ, Hint = value, Group = Huntgroup1 I think this now links the "Hints" file and the "Huntgroups" file together, then, do I need to enter the "Hints" and "Huntgroups" values in the "USERS" file to link it with the "Hint" and "Huntgroups" file? Example user1 Password == "xxyyzz", Hint = value, Group = Huntgroup 1 Filter-Id = value Etc. If the above is correct, then somewhere it should be stated that these files are dependent on each other and the parameters are passed between them. Stating "After the items of a request have been mangled by the "hints" and "huntgroups" files, the users file is processed." Doesn't tell how these 3 files are related and what needs to be done in each file in order to get them working. The "processing_users_file" in freeradius 0.8 is unclear to me. Can anyone help me out here? Thanks Ken
Example of realms/hints/huntgroups files
I´m trying to differentiate my RAS with REALM any my PPP and ISDN users with realms/hints/huntgroups, but it isnt work. Can anyone send me this files as example? regards lmc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Example of realms/hints/huntgroups files
so you want to differentiate Async and ISDN users? Like you dont want Async users to connect to ISDN lines? if you are using cisco it is sending the port type in authentication requests of either Async or ISDN you can check this only (I guess) without needing to use realms etc. Evren On Thu, 28 Nov 2002, Leandro Machado wrote: I´m trying to differentiate my RAS with REALM any my PPP and ISDN users with realms/hints/huntgroups, but it isnt work. Can anyone send me this files as example? regards lmc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
freerad0.5: huntgroups
hello everybody. i am currently setting up a radius-server using freeradius 0.5 under redhat 7.1 for several cisco-routers. well, at least i'm trying to. currently, i've got huntgroups working, but it's quite uncomfortable to handle adding a not-so-small-list of users under every NAS-IP-Address in the huntgroups-file. It gets quite monstrous and unreadable. when i set this server up i tried to $INCLUDE a list of users (editable, extra textfile for every huntgroup) under every NAS-IP-Address, but that didn't work the way i wanted (acutally, it did not work at all - which means that even users whose huntgroup-access did not match were able to logon to the system). to display what i mean: ---file: huntgroups (now) hgr NAS-IP-Address == 10.1.1.1 User-Name = acre, User-Name = hunbun, [...] etc. what did not work was this: hgr NAS-IP-Address == 10.1.1.1 $INCLUDE users.allow hgr NAS-IP-Address == 10.1.1.2 $INCLUDE users.allow etc. i'm now looking for a way to cut those files down to a minimum (design it to be more comfortable for admins like me :) and organize it in a way that makes the files more comfortable to read and more scriptable, perhaps, to add users/systems, delete users/systems etc. i'll gladly appreciate ideas, tips and hints. thank you very much in advance. kind regards, m. pawlowski. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroups + LDAP
On Thu, 29 Aug 2002 [EMAIL PROTECTED] wrote: Hi, On Wed, 28 Aug 2002, Kostas Kalevras wrote: A huntgroup (if we are talking about the same thing) is defined in the huntgroups file in freeradius. Defining it in ldap is of no use. You can do much more cleaver things with the huntgroups file. You could use though the Huntgroup-Name and User-Profile attributes and define separate user profiles for each hungroup. In more detail: Yes, we're talking about the same thing :) Probably not :-) The huntgroups are defined based on NAS ip adresses and ports. If i understand you correctly you want group membership. FYI, my users are stored in LDAP and gets authenticated via Auth-Type := LDAP I already tried using the Huntgroup-Name attribute but it was never matched. IIRC, the group name was being checked against the system group file. How could I tell freeradius to check the group membership on an LDAP server? And check it for any match on the users file? What I'm trying to accomplish is to check every user who log in for their group membership then compare if it has a DEFAULT entry match on the users file, then run an external program which calculates its remaining time and return the Session-Timeout attribute. You could also check the counter module, if you want to impose user time limits. Here's an entry from my users file: DEFAULT Huntgroup-Name == testing Exec-Program-Wait = /usr/local/sbin/testing %u %n %p, Fall-Through = Yes I've read some docs re: Ldap-Group attribute but it requires that every user dn must be entered on its group dn. For example, dn: cn=users,ou=groups,dc=foo,dc=com objectClass: posixGroup objectClass: groupOfUniqueNames cn: users gidNumber: 1101 memberUid: arise uniqueMember: uid=arise,ou=People,dc=foo,dc=com This works well if you have few users but what if you have 10,000+ users in different hungtgroups? You need to add all of them on its own group dn. Is there any other way of doing this? Like checking the radiusHuntgroupName attribute then compare if it matches on the huntgroups file. Is there anything I miss here? Thanks for the time. regards, Ron Check the groupmembership_attribute in doc/rlm_ldap. You should just add a group membership attribute in the user entries with the name or DN of the group the users belongs to. -- Kostas Kalevras Network Operations Center [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 10 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroups + LDAP
Hi, On Wed, 28 Aug 2002, Kostas Kalevras wrote: A huntgroup (if we are talking about the same thing) is defined in the huntgroups file in freeradius. Defining it in ldap is of no use. You can do much more cleaver things with the huntgroups file. You could use though the Huntgroup-Name and User-Profile attributes and define separate user profiles for each hungroup. In more detail: Yes, we're talking about the same thing :) FYI, my users are stored in LDAP and gets authenticated via Auth-Type := LDAP I already tried using the Huntgroup-Name attribute but it was never matched. IIRC, the group name was being checked against the system group file. How could I tell freeradius to check the group membership on an LDAP server? And check it for any match on the users file? What I'm trying to accomplish is to check every user who log in for their group membership then compare if it has a DEFAULT entry match on the users file, then run an external program which calculates its remaining time and return the Session-Timeout attribute. Here's an entry from my users file: DEFAULT Huntgroup-Name == testing Exec-Program-Wait = /usr/local/sbin/testing %u %n %p, Fall-Through = Yes I've read some docs re: Ldap-Group attribute but it requires that every user dn must be entered on its group dn. For example, dn: cn=users,ou=groups,dc=foo,dc=com objectClass: posixGroup objectClass: groupOfUniqueNames cn: users gidNumber: 1101 memberUid: arise uniqueMember: uid=arise,ou=People,dc=foo,dc=com This works well if you have few users but what if you have 10,000+ users in different hungtgroups? You need to add all of them on its own group dn. Is there any other way of doing this? Like checking the radiusHuntgroupName attribute then compare if it matches on the huntgroups file. Is there anything I miss here? Thanks for the time. regards, Ron users file: DEFAULT Hungroup-Name == foo, User-Profile := uid=foo-profile,dc=company,dc=com Hope it helps -- Kostas Kalevras Network Operations Center [EMAIL PROTECTED]National Technical University of Athens, Greece Work Phone: +30 10 7721861 'Go back to the shadow' Gandalf - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Huntgroups + LDAP
hi all, i'm currently migrating from cistron radius to freeradius + ldap backend. on cistron radius, we're using huntgroups and run an external program to return the Session-Timeout for a particular system group. was it still the same for freeradius? does it check for the huntgroup name via LDAP? can someone shed some light pls? thanks in advance. regards, ron - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Questions about huntgroups
I am having a hard time getting the server to recognize huntgroups I defined, which prompts these questions: 1) does running in -xx mode display the results of any huntgroup matching? I am not seeing any matches on the huntgroups I have defined in the debug output. 2) Alan, are you *sure* that I can use Client-IP-Address in the huntgroups file, and that it's not added to the request packet until after the preprocess step is completed? It seems to ignore this entirely. 3) It would be helpful for me to be able to use this in 'huntgroups': providerA Client-IP-Address =~ ^64\.105\. Does huntgroups support the use of regular expressions? Any help appreciated as always. Regards, Dave = David C. Troy [[EMAIL PROTECTED]] 410-544-6193 Sales ToadNet - Want to go fast?410-544-1329 FAX 570 Ritchie Highway, Severna Park, MD 21146-2925 www.toad.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Questions about huntgroups
David C. Troy [EMAIL PROTECTED] wrote: 1) does running in -xx mode display the results of any huntgroup matching? Yes. 2) Alan, are you *sure* that I can use Client-IP-Address in the huntgroups file, and that it's not added to the request packet until after the preprocess step is completed? It seems to ignore this entirely. Hmm... it should be added *before* the huntgroup checks are done. Looking at the code, yes, it is. 3) It would be helpful for me to be able to use this in 'huntgroups': providerA Client-IP-Address =~ ^64\.105\. Uh... you probably want quotes around any regex: ^64\.105\. And that will *never* do what you want. Regexes are over string quantities, not numbers, like IP addresses. Hmmm... that being said, it would be a good idea. typing OK, the CVS snapshot from tonight should update rlm_preprocess, which will allow that regex to work. Does huntgroups support the use of regular expressions? It should. It calls the normal comparison routine, which supports regexes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroups
Does current radius version supports networks in huntgroups -- Andrei Koulik. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: huntgroups by client ip
Mervyn Jack [EMAIL PROTECTED] wrote: The nation-wide provider of dial-up ports that we are renting some ports off, will not/cannot give us the NAS-IP-Address's that our customers calls may come in on. Due to the fact there are too many, and they may change. Can you do Huntgroup selections by something other than NAS-IP-Address? You should be able to do it on pretty much anything you want. What may be more useful is 'Client-IP-Address', which is the source IP of radius packet. This IP is usually the NAS, or the server proxying the packets to you. Alan Dekok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroups by client ip
Hi list. The nation-wide provider of dial-up ports that we are renting some ports off, will not/cannot give us the NAS-IP-Address's that our customers calls may come in on. Due to the fact there are too many, and they may change. Can you do Huntgroup selections by something other than NAS-IP-Address? If got these to play with. rad_recv: Access-Request packet from host 203.xxx.xxx.120:1812, id=206, length=265 NAS-IP-Address = 203.xxx.xxx.49 NAS-Port-Type = Async Called-Station-Id = 142 Calling-Station-Id = 3587x Service-Type = Framed-User Framed-Protocol = PPP Password = \221\304\xxx\xxx\333\356\240 User-Name = xxx Proxy-State =0x4..snip.. -- Mervyn Jack, Technical Director, Country Netlink Pty Ltd. PO Box 529, Cobram, Vic. Australia, 3644 Ph +61 3 5871 1000 Fax +61 3 5871 1874 Mobile 0409 960 520 mailto:[EMAIL PROTECTED] http://www.cnl.com.au ICQ 354419 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
