Wrong behaviour of rlm_ldap module + users file
Hi, this problem is simple (everything not shown here is v1.1.6 out-f-the-box radiusd configuration): users file line: john.doe@test.com Auth-Type := EAP, User-Password == "a", Ldap-Group == "wifi" this is a test line, john.doe@test.com uses EAP-MD5 , but I want to check if he's in the Ldap-Group named 'wifi'. radiusd.conf lines, ldap section: filter ="(uid=%{User-Name})" edir_account_policy_check=no password_attribute = userPassword groupmembership_filter = "(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))" This is where I actually suck. I think this is correct, but it won't work as expected because: rad_recv: Access-Request packet from host 149.132.5.108:35285, id=0, length=160 User-Name = "john.doe@test.com" NAS-IP-Address = 127.0.0.1 Calling-Station-Id = "02-00-00-00-00-01" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x0200001f0170616f6c6f2e676169617264656c6c6940756e696d69622e6974 Message-Authenticator = 0x14b3675352d738629cc1bb21695f3122 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 radius_xlat: '/var/log/radius/radacct/127.0.0.1/auth-detail-20070726' rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/127.0.0.1/auth-detail-20070726 modcall[authorize]: module "auth_log" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: Looking up realm "test.com" for User-Name = "john.doe@test.com" rlm_realm: Found realm "test.com" rlm_realm: Proxying request from user john.doe to realm test.com rlm_realm: Adding Realm = "test.com" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: EAP packet type response id 0 length 31 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'dc=test,dc=com radius_xlat: '(uid=john.doe@test.com)' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ldap.test.com:636, authentication 0 rlm_ldap: setting TLS mode to 1 rlm_ldap: setting TLS CACert File to /usr/local/etc/raddb/certs/crl/root.pem rlm_ldap: bind as cn=ldapreader,ou=servizi,dc=test,dc=com/blargh to ldap.test.com:636 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in dc=test,dc=com, with filter (uid=john.doe@test.com) rlm_ldap: ldap_release_conn: Release Id: 0 radius_xlat: '(&(objectClass=GroupOfNames)(member=uid\3djohn.doe@test.com\2cou\3dusers\2cdc\3dtest\2cdc\3dcom))' This is where the problem arises. I don't want to check if uid=john.doe@test.com esists. rlm_ldap wants to, but that's not what I told him to do. I never told rlm_ldap to verify if john.doe@test.com is an LDAP user. Now he is, but only because I created him. rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=test,dc=com, with filter (&(cn=wifi)(&(objectClass=GroupOfNames)(member=uid\3djohn.doe@test.com\2cou\3dusers\2cdc\3dtest\2cdc\3dcom))) rlm_ldap::ldap_groupcmp: User found in group wifi and THIS is what I want rlm_ldap to do. I want to check this and only this, since john.doe@test.com is a member of wifi and doesn't exist anywhere else in the LDAP tree. He isn't a user. He's just an object in group wifi. That's what happens in my production environment. john'doe's login fails because the first useless search fails. I know I'm doing something horribly wrong, and I can't find out what's my major malfunction. Help! rlm_ldap: ldap_release_conn: Release Id: 0 users: Matched entry john.doe@test.com at line 32 Bye, Inverse.
On Thu, 2007-07-26 at 14:56 +0200, inverse wrote:
Hi,
this problem is simple (everything not shown here is v1.1.6 out-f-the-box radiusd configuration):
users file line: john.doe@test.com Auth-Type := EAP, User-Password == "a", Ldap-Group == "wifi"
Totally wrong. You want: john.doe@test.com Cleartext-Password := "a", Ldap-Group == "wifi" Don't set auth type Don't compare the password; set the server-side one
this is a test line, john.doe@test.com uses EAP-MD5 , but I want to check if he's in the Ldap-Group named 'wifi'.
radiusd.conf lines, ldap section:
filter ="(uid=%{User-Name})" edir_account_policy_check=no password_attribute = userPassword groupmembership_filter = "(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))"
This is where I actually suck. I think this is correct, but it won't work as expected because:
rad_recv: Access-Request packet from host 149.132.5.108:35285, id=0, length=160 User-Name = "john.doe@test.com" NAS-IP-Address = 127.0.0.1 Calling-Station-Id = "02-00-00-00-00-01" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x0200001f0170616f6c6f2e676169617264656c6c6940756e696d69622e6974 Message-Authenticator = 0x14b3675352d738629cc1bb21695f3122 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 radius_xlat: '/var/log/radius/radacct/127.0.0.1/auth-detail-20070726' rlm_detail: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/127.0.0.1/auth-detail-20070726 modcall[authorize]: module "auth_log" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: Looking up realm "test.com" for User-Name = "john.doe@test.com" rlm_realm: Found realm "test.com" rlm_realm: Proxying request from user john.doe to realm test.com rlm_realm: Adding Realm = "test.com" rlm_realm: Authentication realm is LOCAL. modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: EAP packet type response id 0 length 31 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'dc=test,dc=com radius_xlat: '(uid=john.doe@test.com)' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ldap.test.com:636, authentication 0 rlm_ldap: setting TLS mode to 1 rlm_ldap: setting TLS CACert File to /usr/local/etc/raddb/certs/crl/root.pem rlm_ldap: bind as cn=ldapreader,ou=servizi,dc=test,dc=com/blargh to ldap.test.com:636 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in dc=test,dc=com, with filter (uid=john.doe@test.com) rlm_ldap: ldap_release_conn: Release Id: 0 radius_xlat: '(&(objectClass=GroupOfNames)(member=uid\3djohn.doe@test.com\2cou\3dusers\2cdc\3dtest\2cdc\3dcom))'
This is where the problem arises. I don't want to check if uid=john.doe@test.com esists. rlm_ldap wants to, but that's not what I told him to do. I never told rlm_ldap to verify if john.doe@test.com is an LDAP user. Now he is, but only because I created him.
You've got the "ldap" module in "authorize". Remove it. You will need to put it in "instantiate" so that it gets initialised, but you don't want to check it during authorize.
rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in dc=test,dc=com, with filter (&(cn=wifi)(&(objectClass=GroupOfNames)(member=uid\3djohn.doe@test.com\2cou\3dusers\2cdc\3dtest\2cdc\3dcom))) rlm_ldap::ldap_groupcmp: User found in group wifi
and THIS is what I want rlm_ldap to do. I want to check this and only this, since john.doe@test.com is a member of wifi and doesn't exist anywhere else in the LDAP tree. He isn't a user. He's just an object in group wifi. That's what happens in my production environment. john'doe's login fails because the first useless search fails. I know I'm doing something horribly wrong, and I can't find out what's my major malfunction.
Remove "ldap" from the "authorize" section and put it in the "instantiate" section
Hi, I tried the suggestion and it didn't work, here are the involved radiusd.conf sections. You will also notice mschap and similars, that's because we also have dialup users who need an ldap lookup for their belonging to a dialup group and the password. I also need to check if chap still works with this configuration... instantiate { exec ldap files expr } authorize { preprocess auth_log chap mschap suffix eap files pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } eap } And this is the users file line: john.doe@test.com Cleartext-Password := "a", Ldap-Group == "wifi" I also used this one: john.doe@test.com Ldap-Group == "wifi" with EAP-TLS. No way. Both first perform a user-existence check in the ldap_groupcmp() call. Meaning these both work if user exists in the LDAP tree. In the meanwhile I'm looking at the source code for this call... it sounds like this search is hardcoded somewhere. Forgive my suckage. T_T Bye, Inverse On 7/26/07, inverse <inverse@ngi.it> wrote:
users file line: john.doe@test.com Auth-Type := EAP, User-Password == "a", Ldap-Group == "wifi"
Totally wrong. You want:
john.doe@test.com Cleartext-Password := "a", Ldap-Group == "wifi"
Thanks, I owe you one
Bye, Inverse.
-- "In a sea of glass shards, I hear you screaming" --icchan
On Fri, 2007-07-27 at 13:25 +0200, inverse wrote:
Hi,
I tried the suggestion and it didn't work, here are the involved radiusd.conf sections.
Ok. I quick glance at the code shows that the Ldap-Group compare function will do an LDAP search to find the users LDAP DN. You can set it, and it should skip the search - however, the attribute needs to go in the request pairs (grr) so put these lines in "hints" DEFAULT Ldap-UserDn = `cn=%{User-Name},ou=whatever,...` Note that the DN need not be "real"
On 7/27/07, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
DEFAULT Ldap-UserDn = `cn=%{User-Name},ou=whatever,...`
Note that the DN need not be "real"
Hi Phil, lol, I browsed the source too and I was gonna recompile it to exclude the hardcoded uid search. Clearly that would have been useless. Thanks for the hints suggestion. The line above, modified to match the needed suffix and DN did the trick. I also found there was no need to tweak the radiusd.conf file and move ldap to the instantiate section. That's good news. -- "In a sea of glass shards, I hear you screaming" --icchan
participants (2)
-
inverse -
Phil Mayers