Re: Wrong behaviour of rlm_ldap module + users file

2007-07-30 Thread inverse 
On 7/27/07, Phil Mayers [EMAIL PROTECTED] 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
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Wrong behaviour of rlm_ldap module + users file

2007-07-27 Thread Phil Mayers 
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



- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Wrong behaviour of rlm_ldap module + users file

2007-07-27 Thread inverse 
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:

[EMAIL PROTECTED] Cleartext-Password := a, Ldap-Group == wifi

I also used this one:

[EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote:
  
   users file line:
   [EMAIL PROTECTED] Auth-Type := EAP, User-Password == a,  Ldap-Group == 
   wifi
 
  Totally wrong. You want:
 
  [EMAIL PROTECTED] Cleartext-Password := a, Ldap-Group == wifi
 

 Thanks, I owe you one


 Bye,
 Inverse.



-- 
In a sea of glass shards, I hear you screaming
--icchan
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Wrong behaviour of rlm_ldap module + users file

2007-07-26 Thread inverse 
Hi,

this problem is simple (everything not shown here is v1.1.6
out-f-the-box radiusd configuration):

users file line:
[EMAIL PROTECTED] Auth-Type := EAP, User-Password == a,  Ldap-Group == wifi

this is a test line, [EMAIL PROTECTED] 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 = [EMAIL PROTECTED]
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 =
0x021f0170616f6c6f2e676169617264656c6c6940756e696d69622e6974
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 = [EMAIL PROTECTED]
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:  '([EMAIL PROTECTED])'
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
([EMAIL PROTECTED])
rlm_ldap: ldap_release_conn: Release Id: 0
radius_xlat:  '((objectClass=GroupOfNames)([EMAIL PROTECTED]))'

This is where the problem arises. I don't want to check if
[EMAIL PROTECTED] esists.
rlm_ldap wants to, but that's not what I told him to do. I never told
rlm_ldap to verify if [EMAIL PROTECTED] 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)([EMAIL PROTECTED])))
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] at line 32


Bye,
Inverse.
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Wrong behaviour of rlm_ldap module + users file

2007-07-26 Thread inverse 
 
  users file line:
  [EMAIL PROTECTED] Auth-Type := EAP, User-Password == a,  Ldap-Group == 
  wifi

 Totally wrong. You want:

 [EMAIL PROTECTED] Cleartext-Password := a, Ldap-Group == wifi


Thanks, I owe you one


Bye,
Inverse.
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Wrong behaviour of rlm_ldap module + users file

2007-07-26 Thread Phil Mayers 
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:
 [EMAIL PROTECTED] Auth-Type := EAP, User-Password == a,  Ldap-Group == 
 wifi

Totally wrong. You want:

[EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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 = [EMAIL PROTECTED]
 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 =
 0x021f0170616f6c6f2e676169617264656c6c6940756e696d69622e6974
 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 = [EMAIL PROTECTED]
 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:  '([EMAIL PROTECTED])'
 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
 ([EMAIL PROTECTED])
 rlm_ldap: ldap_release_conn: Release Id: 0
 radius_xlat:  '((objectClass=GroupOfNames)([EMAIL PROTECTED]))'
 
 This is where the problem arises. I don't want to check if
 [EMAIL PROTECTED] esists.
 rlm_ldap wants to, but that's not what I told him to do. I never told
 rlm_ldap to verify if [EMAIL PROTECTED] 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)([EMAIL PROTECTED])))
 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 [EMAIL PROTECTED] 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


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html