NAS-IP-Address modified during Access-Request process
Hi everybody, I have a big problem in freeradius installed in version 1.1.4 on RHEL 5, and today it's the third day i'm looking for a solution :( Here is the problem: I configured Freeradius to look in openldap directory to auth and auth an user. The authentication phase is OK During the auth phase, a ldap search is done : if the user is member of a group identified by the host ip he wants to connect, the user is authorized. The problem is here : freeradius receives an Access-Request packet with a NAS-IP-Address (the good one) and to search in the ldap, it doesn't send the ip received in the packet but another one ! Why this attribute is modified ? Is there any cache (the other ip comes from another equipment) ? Thanks for any helpful idea Here are /etc/raddb/users (I also tried with ldap-group == "%{NAS-IP-Address}" ) -------------------------------------------------------- DEFAULT ldap-group == "%{Client-Ip-Address}", Auth-Type := LDAP Service-Type = 1, Fall-Through = no DEFAULT Auth-Type := Reject Fall-Through = no, Reply-Message = "You are not authorized to log in to this host :(" -------------------------------------------------------- /etc/raddb/clients.conf -------------------------------------------------------- client 126.50.0.0/8 { secret = secretsecret shortname = shortname } -------------------------------------------------------- radius LOG (with radiusd -X) -------------------------------------------------------- rad_recv: Access-Request packet from host *126.50.0.148*:1645, id=17, length=82 NAS-IP-Address = *126.50.0.148* NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "testadmin" Calling-Station-Id = "XX.XX.XX.XX" User-Password = "XXXXXXXXX" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 4 modcall[authorize]: module "preprocess" returns ok for request 4 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'dc=example,dc=com' radius_xlat: '(uid=testadmin)' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=example,dc=com, with filter (uid=testadmin) rlm_ldap: ldap_search() failed: LDAP connection lost. rlm_ldap: Attempting reconnect rlm_ldap: attempting LDAP reconnection rlm_ldap: closing existing LDAP connection rlm_ldap: (re)connect to 127.0.0.1:389, authentication 0 rlm_ldap: could not set LDAP_OPT_X_TLS_REQUIRE_CERT option to allow rlm_ldap: starting TLS rlm_ldap: bind as uid=radius,ou=applications,dc=example,dc=com/radiuspass to 127.0.0.1:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in dc=example,dc=com, with filter (uid=testadmin) rlm_ldap: ldap_release_conn: Release Id: 0 radius_xlat: '(|(&(objectClass=GroupOfNames)(member=uid\3dtestAdmin\2cuid\3dtest01\2cou\3dusers\2cdc\3dexample\2cdc\3dcom))(&(objectClass=GroupOfUniqueNames)(uniquemember=uid\3dtestAdmin\2cuid\3dtest01\2cou\3dusers\2cdc\3dexample\2cdc\3dcom)))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=example,dc=com, with filter (&(cn=* 126.50.0.147* )(|(&(objectClass=GroupOfNames)(member=uid\3dtestAdmin\2cuid\3dtest01\2cou\3dusers\2cdc\3dexample\2cdc\3dcom))(&(objectClass=GroupOfUniqueNames)(uniquemember=uid\3dtestAdmin\2cuid\3dtest01\2cou\3dusers\2cdc\3dexample\2cdc\3dcom)))) rlm_ldap::ldap_groupcmp: User found in group 126.50.0.147 rlm_ldap: ldap_release_conn: Release Id: 0 users: Matched entry DEFAULT at line 3 modcall[authorize]: module "files" returns ok for request 4 rlm_ldap: - authorize rlm_ldap: performing user authorization for testadmin radius_xlat: '(uid=testadmin)' radius_xlat: 'dc=example,dc=com' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=example,dc=com, with filter (uid=testadmin) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user testadmin authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 4 modcall: leaving group authorize (returns ok) for request 4 rad_check_password: Found Auth-Type LDAP auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group LDAP for request 4 rlm_ldap: - authenticate rlm_ldap: login attempt by "testadmin" with password "XXXXXXXXX" rlm_ldap: user DN: uid=testAdmin,uid=test01,ou=users,dc=example,dc=com rlm_ldap: (re)connect to 127.0.0.1:389, authentication 1 rlm_ldap: could not set LDAP_OPT_X_TLS_REQUIRE_CERT option to allow rlm_ldap: starting TLS rlm_ldap: bind as uid=testAdmin,uid=test01,ou=users,dc=example,dc=com/XXXXXXXXX to 127.0.0.1:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user testadmin authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 4 modcall: leaving group LDAP (returns ok) for request 4 Login OK: [testadmin/XXXXXXXXX] (from client petitnom port 1 cli 126.100.100.6) Sending Access-Accept of id 17 to 126.50.0.148 port 1645 Service-Type = Login-User Finished request 4 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... -------------------------------------------------------- -- KeV
I have a big problem in freeradius installed in version 1.1.4 on RHEL 5, and today it's the third day i'm looking for a solution :(
Upgrade. This was likely fixed ages ago. http://wiki.freeradius.org/Red_Hat_FAQ Ivan Kalik Kalik Informatika ISP
thanks for the quick answer :) Indeed, the version installed is not the last one but the "no longer maintained one" I just did yum install freeradius. I will fix this right now Thanks again -- KeV
Hi, I installed freeradius 2 but my problem is still there. To remember it : I configured Freeradius to look in openldap directory to authenticate and authorize an user. The authentication phase is OK During the authorize phase, a ldap search is done : if the user is member of a group identified by the host ip he wants to connect, the user is authorized. The problem is here : freeradius receives an Access-Request packet with a NAS-IP-Address (the good one) and to search in the ldap, it doesn't send the ip received in the packet but another one ! Why this attribute is modified ? Is there any cache (the other ip comes from another equipment) ? To precize : I think there is some cache enabled anywhere (the ip used for ldap filter is always the one of the first request), is there any way to disable it ? Before testing, I created the group for IP1 and I added the test user to it. Test 1: - I ran radiusd -X - I try to connect with IP 1. => OK - I try to connect with IP 2 => OK (not right result because to check the membership it's the first IP which is used) Then, I kill radiusd. test 2 : - I ran radiusd -X - I try to connect with IP2 => KO (expected because the group for IP 2 doesn't exist) - I try to connect with IP1 => KO (not expected because the group for IP1 exists) To help, the logs : ------------------------------ rad_recv: Access-Request packet from host 126.50.0.148 port 1645, id=34, length=80 NAS-IP-Address = 126.50.0.148 NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "testuser" Calling-Station-Id = "126.100.100.6" User-Password = "XXXXX" +- entering group authorize {...} ++[preprocess] returns ok rlm_ldap: Entering ldap_groupcmp() [files] expand: dc=example,dc=com -> dc=example,dc=com [files] expand: (uid=%{User-Name}) -> (uid=testuser) rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=example,dc=com, with filter (uid=testuser) rlm_ldap: ldap_search() failed: LDAP connection lost. rlm_ldap: Attempting reconnect rlm_ldap: attempting LDAP reconnection rlm_ldap: closing existing LDAP connection rlm_ldap: (re)connect to localhost:389, authentication 0 rlm_ldap: starting TLS rlm_ldap: bind as ou=radius,ou=applications,dc=example,dc=com/XXXXX to localhost:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in dc=example,dc=com, with filter (uid=testuser) rlm_ldap: ldap_release_conn: Release Id: 0 [files] expand: (&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:LDAP-UserDn})) -> (&(objectClass=GroupOfUniqueNames)(uniquemember=uid\3dtestuser\2cuid\3dtest01\2cou\3dusers\2cdc\3dexample\2cdc\3dcom)) rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=example,dc=com, with filter (&(cn=126.50.0.147)(&(objectClass=GroupOfUniqueNames)(uniquemember=uid\3dtestuser\2cuid\3dtest01\2cou\3dusers\2cdc\3dexample\2cdc\3dcom))) rlm_ldap::ldap_groupcmp: User found in group 126.50.0.147 rlm_ldap: ldap_release_conn: Release Id: 0 [files] users: Matched entry DEFAULT at line 1 ++[files] returns ok [ldap] performing user authorization for testuser [ldap] expand: (uid=%{User-Name}) -> (uid=testuser) [ldap] expand: dc=example,dc=com -> dc=example,dc=com rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=example,dc=com, with filter (uid=testuser) [ldap] looking for check items in directory... [ldap] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap] user testuser authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 ++[ldap] returns ok Found Auth-Type = LDAP +- entering group LDAP {...} [ldap] login attempt by "testuser" with password "azerty12" [ldap] user DN: uid=testuser,uid=test01,ou=users,dc=example,dc=com rlm_ldap: (re)connect to localhost:389, authentication 1 rlm_ldap: starting TLS rlm_ldap: bind as uid=testuser,uid=test01,ou=users,dc=example,dc=com/azerty12 to localhost:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful [ldap] user testuser authenticated succesfully ++[ldap] returns ok Login OK: [testuser] (from client petitnom port 1 cli 126.100.100.6) Sending Access-Accept of id 34 to 126.50.0.148 port 1645 Nokia-IPSO-User-Role = "adminRole" Nokia-IPSO-SuperUser-Access = 1 Service-Type = Login-User Finished request 1. Going to the next request Waking up in 4.9 seconds. Cleaning up request 1 ID 34 with timestamp +52 Ready to process requests. ------------------------------ -- KeV
participants (2)
-
Ivan Kalik -
kevin leblanc