Hello everybody. I'll tell you what i wanna do and the problem i get so you could either fix my configuration or give me some new ideas. First, I´m using freeradius 1.1.1 + ldap. What I have is this: I have three radius working in different placement of one organization, these radius authorize against three subtrees of the ldap. When a user is not found they do proxy to another radius. This work quite well. What I want: I want to have another radius ( only one ) to acct as a backup of these servers ( for configuring my ciscos with two servers ). This radius has the complete tree but it must look in each subtree depending on the NAS-IP, not in the whole ldap. If the user is not found in the corresponding subtree it must do proxy to the central radius. I don't know if I have explain it correctly, if I haven't just tell me ( I'm not an english speaker ) For this configuration I've defined three ldaps in radiusd.conf: module{ ldap ldap1{ } ldap ldap2{ } ldap ldap3{ } } ... authorize{ ... autztype customer1{ redundant { group { ldap1 { notfound = return fail = return } files mschap eap notfound = 1 fail = 1 } files } } Autz-Type customer2{ [ similar configuration as above ] } Autz-Type customer3{ [ similar configuration as above ] } } My hints file: DEFAULT NAS-IP-Address == "192.168.51.220" Autz-Type := customer1 DEFAULT NAS-IP-Address == "192.168.51.221" Autz-Type := customer2 DEFAULT NAS-IP-Address == "192.168.51.222" Autz-Type := customer3 Users: DEFAULT Proxy-to-realm := wickwar_central The problem is that it doesn't execute any of Autz-Type sections. The logs: rad_recv: Access-Request packet from host 192.168.51.221:1645, id=200, length=160 User-Name = "cadiz" Framed-MTU = 1400 Called-Station-Id = "0011.9215.c490" Calling-Station-Id = "0004.238d.4b0e" Cisco-AVPair = "ssid=perfil_tipo_a" Service-Type = Login-User Message-Authenticator = 0x27c966f01f1de90c836066e2a019c553 EAP-Message = 0x0202000a01636164697a NAS-Port-Type = Wireless-802.11 Cisco-NAS-Port = "395" NAS-Port = 395 NAS-IP-Address = 192.168.51.221 NAS-Identifier = "ap" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 hints: Matched DEFAULT at 59 modcall[authorize]: module "preprocess" returns ok for request 1 rlm_realm: No '/' in User-Name = "cadiz", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "ntdomain" returns noop for request 1 radius_xlat: '/opt/radius_LOCAL/var/log/radius/radacct/192.168.51.221/auth-detail-20060605' rlm_detail: /opt/radius_LOCAL/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /opt/radius_LOCAL/var/log/radius/radacct/192.168.51.221/auth-detail-20060605 modcall[authorize]: module "auth_log" returns ok for request 1 modcall: leaving group authorize (returns ok) for request 1 auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user auth: Failed to validate the user. Login incorrect: [cadiz/<no User-Password attribute>] (from client ap port 395 cli 0004.238d.4b0e) Delaying request 1 for 1 seconds Finished request 1 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 200 to 192.168.51.221 port 1645 Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 1 ID 200 with timestamp 44840b82 Nothing to do. Sleeping until we see a request. If anyone could give my a hand. I would be grateful. Thanks.
wekz wrote:
I don't know if I have explain it correctly, if I haven't just tell me ( I'm not an english speaker )
Your english is great.
My hints file:
Nearly there. Try: DEFAULT NAS-IP-Address == 192.168.xx.yy, Autz-Type := LDAPx I'm not sure that'll work in a hints file - so you may need to use a "users" file - hints puts items into the request pairs, Autz-Type needs to go into the configure pairs. Try this: modules { # other stuff files filesFirst { usersfile = ${confdir}/usersFirst } } authorize { preprocess filesFirst Autz-Type LDAP1 { # stuff here ldap1 } # other LDAP modules } And in ${confdir}/usersFirst: DEFAULT NAS-IP-Address == 192.168.51.xx, Autz-Type := LDAP1 DEFAULT NAS-IP-Address == 192.168.51.yy, Autz-Type := LDAP2 ...and so on. The other slightly simpler way might be to use a "passwd" (badly named) module, e.g.: modules { passwd nas2autz { filename = ${confdir}/nas2autz format = "*NAS-IP-Address:Autz-Type" # set to 0 to read file on every request - slow # but instant-updates hashsize = 100 } } authorize { preprocess nas2autz Autz-Type LDAP1 { ldap1 } # other Autz } ...and in ${confdir}/nas2autz 192.168.51.xx:LDAP1 192.168.51.yy:LDAP2 Hope that helps Phil
Thanks very much Phil. That works, I think it doesn't work in the hints file for the reasons you told me. Now I've got a new problem. I use the radiusGroupName for making the users belong to VLAN1, VLAN2 or VLAN3. So I enable groupmembership_attribute = radiusGroupName but I left groupname_attribute and groupmembership_filter commented ( in each ldap module ). In other file called users-vlan I defined this: DEFAULT Ldap-Group == Local stuff for assigning VLAN1 ..... The file that determine the users procedence is users-procedence: DEFAULT NAS-IP-Address == 192.168.51.yy, Autz-Type=customer1 ..... The file that proxies ( users-proxy ): DEFAULT proxy-to-realm:=CENTRAL The authorization section: .... users-procedence autztype customer1{ redundant { group { ldap1 { notfound = return fail = return } users-vlan mschap eap notfound = 1 fail = 1 } users-proxy } } ..... The situation is: a user that must be authorized against ldap2 make a match in the users-procedence file and get customer2 autztype. So the user is looked for in ldap2. 1.- If it fails in the logs I could see radius looking for ldap_groupcmp() in ldap3 when all I think it must do is proxy. 2.- In case the user is found it make a search too for ldap group in ldap3. I think in the first case there are two problems: it searches when it doesn't have to ( unnecessary search ), and it searches bad because it does in the last ldap instantiated ( that is ldap3 ) In the second case the problem is that it searches in the last ldap instantiated. (( This configuration works fine when all you have is one ldap )) Is that a bug ?? I found a similar bug in bug-list but it belongs to version 1.0.1 ( bug #163, about unnecessary searches ) and I think a read a bug about searching in the last ldap instantiated ( but I think this has to be with older versions and I can't find it ) I solved this problem yesterday but I don't know how to say... I solved it in a dirty-way ( I hope you understand ). So if you or anyone have an idea ... 2006/6/5, Phil Mayers <p.mayers@imperial.ac.uk>:
wekz wrote:
I don't know if I have explain it correctly, if I haven't just tell me ( I'm not an english speaker )
Your english is great.
My hints file:
Nearly there. Try:
DEFAULT NAS-IP-Address == 192.168.xx.yy, Autz-Type := LDAPx
I'm not sure that'll work in a hints file - so you may need to use a "users" file - hints puts items into the request pairs, Autz-Type needs to go into the configure pairs.
Try this:
modules { # other stuff files filesFirst { usersfile = ${confdir}/usersFirst } }
authorize { preprocess filesFirst Autz-Type LDAP1 { # stuff here ldap1 } # other LDAP modules }
And in ${confdir}/usersFirst:
DEFAULT NAS-IP-Address == 192.168.51.xx, Autz-Type := LDAP1
DEFAULT NAS-IP-Address == 192.168.51.yy, Autz-Type := LDAP2
...and so on.
The other slightly simpler way might be to use a "passwd" (badly named) module, e.g.:
modules { passwd nas2autz { filename = ${confdir}/nas2autz format = "*NAS-IP-Address:Autz-Type" # set to 0 to read file on every request - slow # but instant-updates hashsize = 100 } }
authorize { preprocess nas2autz Autz-Type LDAP1 { ldap1 } # other Autz }
...and in ${confdir}/nas2autz
192.168.51.xx:LDAP1 192.168.51.yy:LDAP2
Hope that helps Phil - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ooo I think I found the solution: in users-vlan i changed the lines for this DEFAULT ldap1-Ldap-Group==Local Tunnel-Type=VLAN, Tunnel-Medium-Type=6, Tunnel-Private-Group-Id=Local, Fall-Through = No DEFAULT ldap1-Ldap-Group==Invitados Tunnel-Type=VLAN, Tunnel-Medium-Type=6, Tunnel-Private-Group-Id=Invitado, Fall-Through = No DEFAULT ldap2-Ldap-Group==Local Tunnel-Type=VLAN, Tunnel-Medium-Type=6, Tunnel-Private-Group-Id=Local, Fall-Through = No DEFAULT ldap2-Ldap-Group==Invitados Tunnel-Type=VLAN, Tunnel-Medium-Type=6, Tunnel-Private-Group-Id=Invitado, Fall-Through = No DEFAULT ldap3-Ldap-Group==Local Tunnel-Type=VLAN, Tunnel-Medium-Type=6, Tunnel-Private-Group-Id=Local, Fall-Through = No DEFAULT ldap3-Ldap-Group==Invitados Tunnel-Type=VLAN, Tunnel-Medium-Type=6, Tunnel-Private-Group-Id=Invitado, Fall-Through = No And it doesn't do unnecessary searches and when it has to, it searches correctly. This works but, is it the better way to do it? 2006/6/7, wekz <fbl.list@gmail.com>:
Thanks very much Phil. That works, I think it doesn't work in the hints file for the reasons you told me.
Now I've got a new problem. I use the radiusGroupName for making the users belong to VLAN1, VLAN2 or VLAN3. So I enable
groupmembership_attribute = radiusGroupName
but I left groupname_attribute and groupmembership_filter commented ( in each ldap module ).
In other file called users-vlan I defined this:
DEFAULT Ldap-Group == Local stuff for assigning VLAN1 ..... The file that determine the users procedence is users-procedence:
DEFAULT NAS-IP-Address == 192.168.51.yy, Autz-Type=customer1 .....
The file that proxies ( users-proxy ): DEFAULT proxy-to-realm:=CENTRAL
The authorization section: .... users-procedence
autztype customer1{ redundant { group { ldap1 { notfound = return fail = return } users-vlan
mschap eap notfound = 1 fail = 1 } users-proxy } } .....
The situation is: a user that must be authorized against ldap2 make a match in the users-procedence file and get customer2 autztype. So the user is looked for in ldap2.
1.- If it fails in the logs I could see radius looking for ldap_groupcmp() in ldap3 when all I think it must do is proxy. 2.- In case the user is found it make a search too for ldap group in ldap3.
I think in the first case there are two problems: it searches when it doesn't have to ( unnecessary search ), and it searches bad because it does in the last ldap instantiated ( that is ldap3 )
In the second case the problem is that it searches in the last ldap instantiated.
(( This configuration works fine when all you have is one ldap ))
Is that a bug ?? I found a similar bug in bug-list but it belongs to version 1.0.1 ( bug #163, about unnecessary searches ) and I think a read a bug about searching in the last ldap instantiated ( but I think this has to be with older versions and I can't find it )
I solved this problem yesterday but I don't know how to say... I solved it in a dirty-way ( I hope you understand ). So if you or anyone have an idea ...
2006/6/5, Phil Mayers < p.mayers@imperial.ac.uk>:
wekz wrote:
I don't know if I have explain it correctly, if I haven't just tell me
(
I'm not an english speaker )
Your english is great.
My hints file:
Nearly there. Try:
DEFAULT NAS-IP-Address == 192.168.xx.yy, Autz-Type := LDAPx
I'm not sure that'll work in a hints file - so you may need to use a "users" file - hints puts items into the request pairs, Autz-Type needs to go into the configure pairs.
Try this:
modules { # other stuff files filesFirst { usersfile = ${confdir}/usersFirst } }
authorize { preprocess filesFirst Autz-Type LDAP1 { # stuff here ldap1 } # other LDAP modules }
And in ${confdir}/usersFirst:
DEFAULT NAS-IP-Address == 192.168.51.xx, Autz-Type := LDAP1
DEFAULT NAS-IP-Address == 192.168.51.yy, Autz-Type := LDAP2
...and so on.
The other slightly simpler way might be to use a "passwd" (badly named) module, e.g.:
modules { passwd nas2autz { filename = ${confdir}/nas2autz format = "*NAS-IP-Address:Autz-Type" # set to 0 to read file on every request - slow # but instant-updates hashsize = 100 } }
authorize { preprocess nas2autz Autz-Type LDAP1 { ldap1 } # other Autz }
...and in ${confdir}/nas2autz
192.168.51.xx:LDAP1 192.168.51.yy:LDAP2
Hope that helps Phil - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
wekz wrote:
DEFAULT ldap3-Ldap-Group==Invitados Tunnel-Type=VLAN, Tunnel-Medium-Type=6, Tunnel-Private-Group-Id=Invitado, Fall-Through = No
And it doesn't do unnecessary searches and when it has to, it searches correctly. This works but, is it the better way to do it?
I think that's the correct way to do it. Certainly if you have >1 ldap module, you need to use the "instancename-Ldap-Group" syntax.
participants (2)
-
Phil Mayers -
wekz