Re: Freeradius and LDAP : to be continued
Phil Mayers wrote:
Christophe Gravier wrote:
My password are not stored in LDAP in clear text but hashed using SHA
algorythm, so this won't work ;-(
Ok, let's take a breath. First things first:
If your passwords are in SHA (which they are) your Radius server will
ONLY be able to answer PAP requests.
The very first log you sent in this thread indicates you have
ChilliSpot set to use CHAP:
rlm_ldap: - authenticate
rlm_ldap: Attribute User-Password is required for authentication.
Cannot use CHAP-Password.
modcall[authenticate]: module ldap returns invalid for request 0
modcall: group Auth-Type returns invalid for request 0
auth: Failed to validate the user.
'''Cannot use CHAP-Password''' - indicates the request (from
ChilliSpot) came in with CHAP credentials.
First, fix that. See here:
http://archives.free.net.ph/message/20051025.180818.4d829f18.en.html
Next, since you have SHA passwords and can only answer PAP, you have
two choices:
1. Extract the SHA password and add it to the config items, then
configure the Radius servers PAP module to check it:
modules {
pap {
encryption_scheme = sha1
}
ldap {
# settings go here
}
}
authorize {
preprocess
ldap
}
authenticate {
Auth-Type PAP {
pap
}
}
HOWEVER - this may not work. The SHA that your LDAP server uses may
be slightly different (salting, keying) than the SHA FreeRadius uses.
Much more likely to trip you up though, is when ldap matches in
authorize, it will set Auth-Type = LDAP, so you either need to disable
that or otherwise make it work and there are about 6 different ways
of doing that. The most obvious would be to replace the above with:
modules { as before }
authorize { as before }
authenticate {
Auth-Type LDAP {
pap
}
}
I want to make set Auth-Type = LDAP working by making this Auth-Type
use the pap configuration. (correct me If I'm wrong).
I followed what you advises:
- configure chilli uamsecret and uampassword)
- put pap configuration in module section
- check ldap configration in module
- put ldap in authorize
- put Auth-Type LDAP { pap } in authentificate.
Now things got through pap indeed, but I'm told:
rlm_pap: No password (or empty password) to check against for for user
gravier.christophe
I think I totally misunderstand your sentence: Extract the SHA password
and add it to the config items. I thought it means to add the mapping
checkItem User-Password userPassword in ldap.attrmap (where
userPassword is my attribute for SHA password). As it didn't work I used
the password_attribute conf entry in ldap configuration (module
section), but as I expected it has the same consequence.
Could you please, be more precise about the extraction of SHA password ?
Is there an additional conf entry for pap in module section ?
Here is the complete trace:
rlm_ldap: attempting LDAP reconnection
rlm_ldap: (re)connect to ist-guizay.univ-st-etienne.fr:389, authentication 0
rlm_ldap: bind as / to ist-guizay.univ-st-etienne.fr:389
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in ou=person,o=istase,c=fr, with filter
(uid=gravier.christophe)
rlm_ldap: checking if remote access for gravier.christophe is allowed by uid
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: user gravier.christophe authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module ldap 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: No '@' in User-Name = gravier.christophe, looking up
realm NULL
rlm_realm: No such realm NULL
modcall[authorize]: module suffix returns noop for request 0
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module eap returns noop for request 0
users: Matched entry DEFAULT at line 158
modcall[authorize]: module files returns ok for request 0
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
auth: type LDAP
Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 0
rlm_pap: login attempt by gravier.christophe with password here the
trace prints my password in plain text, normal ?
rlm_pap: No password (or empty password) to check against for for user
gravier.christophe
modcall[authenticate]: module pap returns invalid for request 0
modcall: group Auth-Type returns invalid for request 0
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
But it might not work. Alternatively and probably simpler (but less
formally correct) is the 2nd method:
2. Configure the LDAP module to find the user, set Auth-Type==LDAP
then authenticate the user via simple bind:
authorize {
preprocess
ldap
}
authenticate {
Auth-Type LDAP {
ldap
}
}
...and assuming the ldap
Re: Freeradius and LDAP : to be continued
Christophe Gravier wrote:
Phil Mayers wrote:
Christophe Gravier wrote:
My password are not stored in LDAP in clear text but hashed using
SHA algorythm, so this won't work ;-(
Ok, let's take a breath. First things first:
If your passwords are in SHA (which they are) your Radius server will
ONLY be able to answer PAP requests.
The very first log you sent in this thread indicates you have
ChilliSpot set to use CHAP:
rlm_ldap: - authenticate
rlm_ldap: Attribute User-Password is required for authentication.
Cannot use CHAP-Password.
modcall[authenticate]: module ldap returns invalid for request 0
modcall: group Auth-Type returns invalid for request 0
auth: Failed to validate the user.
'''Cannot use CHAP-Password''' - indicates the request (from
ChilliSpot) came in with CHAP credentials.
First, fix that. See here:
http://archives.free.net.ph/message/20051025.180818.4d829f18.en.html
Next, since you have SHA passwords and can only answer PAP, you have
two choices:
1. Extract the SHA password and add it to the config items, then
configure the Radius servers PAP module to check it:
modules {
pap {
encryption_scheme = sha1
}
ldap {
# settings go here
}
}
authorize {
preprocess
ldap
}
authenticate {
Auth-Type PAP {
pap
}
}
HOWEVER - this may not work. The SHA that your LDAP server uses may
be slightly different (salting, keying) than the SHA FreeRadius uses.
Much more likely to trip you up though, is when ldap matches in
authorize, it will set Auth-Type = LDAP, so you either need to
disable that or otherwise make it work and there are about 6
different ways of doing that. The most obvious would be to replace
the above with:
modules { as before }
authorize { as before }
authenticate {
Auth-Type LDAP {
pap
}
}
I want to make set Auth-Type = LDAP working by making this Auth-Type
use the pap configuration. (correct me If I'm wrong).
I followed what you advises:
- configure chilli uamsecret and uampassword)
- put pap configuration in module section
- check ldap configration in module
- put ldap in authorize
- put Auth-Type LDAP { pap } in authentificate.
Now things got through pap indeed, but I'm told:
rlm_pap: No password (or empty password) to check against for for user
gravier.christophe
I think I totally misunderstand your sentence: Extract the SHA
password and add it to the config items. I thought it means to add
the mapping checkItem User-Password userPassword in ldap.attrmap
(where userPassword is my attribute for SHA password). As it didn't
work I used the password_attribute conf entry in ldap configuration
(module section), but as I expected it has the same consequence.
Could you please, be more precise about the extraction of SHA password
? Is there an additional conf entry for pap in module section ?
Here is the complete trace:
rlm_ldap: attempting LDAP reconnection
rlm_ldap: (re)connect to ist-guizay.univ-st-etienne.fr:389,
authentication 0
rlm_ldap: bind as / to ist-guizay.univ-st-etienne.fr:389
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in ou=person,o=istase,c=fr, with filter
(uid=gravier.christophe)
rlm_ldap: checking if remote access for gravier.christophe is allowed
by uid
rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: user gravier.christophe authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module ldap 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: No '@' in User-Name = gravier.christophe, looking up
realm NULL
rlm_realm: No such realm NULL
modcall[authorize]: module suffix returns noop for request 0
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module eap returns noop for request 0
users: Matched entry DEFAULT at line 158
modcall[authorize]: module files returns ok for request 0
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
auth: type LDAP
Processing the authenticate section of radiusd.conf
modcall: entering group Auth-Type for request 0
rlm_pap: login attempt by gravier.christophe with password here
the trace prints my password in plain text, normal ?
rlm_pap: No password (or empty password) to check against for for user
gravier.christophe
modcall[authenticate]: module pap returns invalid for request 0
modcall: group Auth-Type returns invalid for request 0
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
But it might not work. Alternatively and probably simpler (but less
formally correct) is the 2nd method:
2. Configure the LDAP module to find the user, set Auth-Type==LDAP
then authenticate the user via simple bind:
authorize {
preprocess
ldap
}
authenticate {
Auth-Type LDAP {
ldap
}
Re: Freeradius and LDAP : to be continued
Christophe Gravier wrote:
Alan DeKok wrote:
[EMAIL PROTECTED] wrote:
rlm_ldap: Adding userPassword as User-Password, value { op=11
That's better.
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
Yuck.
My quick answer is to edit rlm_ldap.c to have it *never* set
Auth-Type to LDAP. That would solve a lot of problems.
Indeed, I have no rlm-ldap.so ;-(
(I did apt-get install freeradius-ldap on my debian box ...)
Whaou, I was so kind of tired (or in a hurry).
I of course mean :
I have no rlm_ldap.c ...
Alan DeKok.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
--
Christophe Gravier
Laboratoire DIOM, groupe SATIn - Doctorant
ISTASE - Ingénieur d'études
Perso: http://perso.univ-st-etienne.fr/gravchri/
SATIn: http://www.istase.com/satin
Tel : 04 7748 5034
A mediter: http://www.fsffrance.org/news/article2005-11-25.fr.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Alan DeKok wrote:
[EMAIL PROTECTED] wrote:
rlm_ldap: Adding userPassword as User-Password, value { op=11
That's better.
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
Yuck.
My quick answer is to edit rlm_ldap.c to have it *never* set
Auth-Type to LDAP. That would solve a lot of problems.
Interesting. I mentioned this to another querier the other day:
http://lists.freeradius.org/pipermail/freeradius-users/2005-December/049221.html
What then would the authenticate section look like to use LDAP?
Presumably something like:
authenticate {
Auth-Type PAP {
ldap
}
}
...but of course then you get into what happens if you want 2 different
services in the same server, such as:
authenticate {
Auth-Type PAP-service1 {
ldap1
}
Auth-Type PAP-service2 {
ldap2
}
Auth-Type MSCHAP-service1 {
mschap1
}
Auth-Type MSCHAP-service2 {
mschap2
}
}
...etc. - nasty. Is it possible to do:
authenticate {
Huntgroup Service1 {
Auth-Type PAP {
ldap1
}
Auth-Type MSCHAP {
mschap1
}
}
Huntgroup Service2 {
Auth-Type PAP {
ldap2
}
Auth-Type MSCHAP {
mschap2
}
}
}
...although Realm might make more sense than Huntgroup in
understanding what I mean.
There's also the possibility of wanting to use fallback:
authenticate {
Auth-Type PAP {
ldap
pap
}
}
...although I'm pretty sure you can do that with configurable failover
and the above syntax is wrong.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Phil Mayers wrote:
Alan DeKok wrote:
[EMAIL PROTECTED] wrote:
rlm_ldap: Adding userPassword as User-Password, value { op=11
That's better.
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
Yuck.
My quick answer is to edit rlm_ldap.c to have it *never* set
Auth-Type to LDAP. That would solve a lot of problems.
Interesting. I mentioned this to another querier the other day:
http://lists.freeradius.org/pipermail/freeradius-users/2005-December/049221.html
Ar. You lost me.
Still not working.
I can't imagine I'm unable to make freeradius uses LDAP password without
hacking it :-/
What then would the authenticate section look like to use LDAP?
Presumably something like:
authenticate {
Auth-Type PAP {
ldap
}
}
...but of course then you get into what happens if you want 2
different services in the same server, such as:
authenticate {
Auth-Type PAP-service1 {
ldap1
}
Auth-Type PAP-service2 {
ldap2
}
Auth-Type MSCHAP-service1 {
mschap1
}
Auth-Type MSCHAP-service2 {
mschap2
}
}
...etc. - nasty. Is it possible to do:
authenticate {
Huntgroup Service1 {
Auth-Type PAP {
ldap1
}
Auth-Type MSCHAP {
mschap1
}
}
Huntgroup Service2 {
Auth-Type PAP {
ldap2
}
Auth-Type MSCHAP {
mschap2
}
}
}
...although Realm might make more sense than Huntgroup in
understanding what I mean.
There's also the possibility of wanting to use fallback:
authenticate {
Auth-Type PAP {
ldap
pap
}
}
...although I'm pretty sure you can do that with configurable failover
and the above syntax is wrong.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
--
Christophe Gravier
Laboratoire DIOM, groupe SATIn - Doctorant
ISTASE - Ingénieur d'études
Perso: http://perso.univ-st-etienne.fr/gravchri/
SATIn: http://www.istase.com/satin
Tel : 04 7748 5034
A mediter: http://www.fsffrance.org/news/article2005-11-25.fr.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Freeradius and LDAP : to be continued
Hello,
I must admit, I have been reading this thread, but I still do not understand
what Christophe is trying to accomplish. As far as I understand - you have
your passwords in LDAP, and you only ( kind of ) need to authorize but NOT
authenticate users that are in your LDAP directory..
Please correct me...
Regards,
Edvin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christophe Gravier
Sent: Donnerstag, 15. Dezember 2005 16:05
To: FreeRadius users mailing list
Subject: Re: Freeradius and LDAP : to be continued
Phil Mayers wrote:
Alan DeKok wrote:
[EMAIL PROTECTED] wrote:
rlm_ldap: Adding userPassword as User-Password, value { op=11
That's better.
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
Yuck.
My quick answer is to edit rlm_ldap.c to have it *never* set
Auth-Type to LDAP. That would solve a lot of problems.
Interesting. I mentioned this to another querier the other day:
http://lists.freeradius.org/pipermail/freeradius-users/2005-December/049221.
html
Ar. You lost me.
Still not working.
I can't imagine I'm unable to make freeradius uses LDAP password without
hacking it :-/
What then would the authenticate section look like to use LDAP?
Presumably something like:
authenticate {
Auth-Type PAP {
ldap
}
}
...but of course then you get into what happens if you want 2
different services in the same server, such as:
authenticate {
Auth-Type PAP-service1 {
ldap1
}
Auth-Type PAP-service2 {
ldap2
}
Auth-Type MSCHAP-service1 {
mschap1
}
Auth-Type MSCHAP-service2 {
mschap2
}
}
...etc. - nasty. Is it possible to do:
authenticate {
Huntgroup Service1 {
Auth-Type PAP {
ldap1
}
Auth-Type MSCHAP {
mschap1
}
}
Huntgroup Service2 {
Auth-Type PAP {
ldap2
}
Auth-Type MSCHAP {
mschap2
}
}
}
...although Realm might make more sense than Huntgroup in
understanding what I mean.
There's also the possibility of wanting to use fallback:
authenticate {
Auth-Type PAP {
ldap
pap
}
}
...although I'm pretty sure you can do that with configurable failover
and the above syntax is wrong.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
--
Christophe Gravier
Laboratoire DIOM, groupe SATIn - Doctorant
ISTASE - Ingénieur d'études
Perso: http://perso.univ-st-etienne.fr/gravchri/
SATIn: http://www.istase.com/satin
Tel : 04 7748 5034
A mediter: http://www.fsffrance.org/news/article2005-11-25.fr.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
Re: Freeradius and LDAP : to be continued
Hello Edvin,
First, I received my email posted to the list several times in my mail
client.
I higly hope this is not the case for all you ! (if it is, thunderbird
didn't like to switch from the testing wireless network back to cable
and vice versa, since they're all dated to the same hour)
If you received only one mail, it is OK, just forget what I told ;-)
For what I am trying to do:
I have an existing LDAP directory with all users being able to connect
to the wireless area.
The hotspot architecture is :
client - chillispot (login page served with apache2 + ssl) -
freeradius - ldap.
I just want my ldap users being able to connect to the hotspot.
So, *at first*, I edited the conf file to let users be authenticate via
LDAP.
This way, radtest way just OK but not ChilliSpot. When I report it to
the list, asking how radtest is different to chillispot login, Alan
explained me:
You're using LDAP as an authentication server. Don't do that. Use LDAP
to store passwords.
i.e. remove the ldap entry from the authenticate section. Get
radtest to work. Once that works, Chillispot will work, too.
So I remove ldap from authentificate (I let it in authorize section
thgouh).
But it still doesn't solve the problem.
In the end, Alan proposed to hack rlm_ldap.c to have it *never* set
Auth-Type to LDAP. That would solve a lot of problems.
I just find it dirty to hack the radius then recompile to get ldap
support :-(
If you're using LDAP for your users accessing the hotspot, would you
please tell me how you achieve this ?
Best Regards,
Seferovic Edvin wrote:
Hello,
I must admit, I have been reading this thread, but I still do not understand
what Christophe is trying to accomplish. As far as I understand - you have
your passwords in LDAP, and you only ( kind of ) need to authorize but NOT
authenticate users that are in your LDAP directory..
Please correct me...
Regards,
Edvin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christophe Gravier
Sent: Donnerstag, 15. Dezember 2005 16:05
To: FreeRadius users mailing list
Subject: Re: Freeradius and LDAP : to be continued
Phil Mayers wrote:
Alan DeKok wrote:
[EMAIL PROTECTED] wrote:
rlm_ldap: Adding userPassword as User-Password, value { op=11
That's better.
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
Yuck.
My quick answer is to edit rlm_ldap.c to have it *never* set
Auth-Type to LDAP. That would solve a lot of problems.
Interesting. I mentioned this to another querier the other day:
http://lists.freeradius.org/pipermail/freeradius-users/2005-December/049221.
html
Ar. You lost me.
Still not working.
I can't imagine I'm unable to make freeradius uses LDAP password without
hacking it :-/
What then would the authenticate section look like to use LDAP?
Presumably something like:
authenticate {
Auth-Type PAP {
ldap
}
}
...but of course then you get into what happens if you want 2
different services in the same server, such as:
authenticate {
Auth-Type PAP-service1 {
ldap1
}
Auth-Type PAP-service2 {
ldap2
}
Auth-Type MSCHAP-service1 {
mschap1
}
Auth-Type MSCHAP-service2 {
mschap2
}
}
...etc. - nasty. Is it possible to do:
authenticate {
Huntgroup Service1 {
Auth-Type PAP {
ldap1
}
Auth-Type MSCHAP {
mschap1
}
}
Huntgroup Service2 {
Auth-Type PAP {
ldap2
}
Auth-Type MSCHAP {
mschap2
}
}
}
...although Realm might make more sense than Huntgroup in
understanding what I mean.
There's also the possibility of wanting to use fallback:
authenticate {
Auth-Type PAP {
ldap
pap
}
}
...although I'm pretty sure you can do that with configurable failover
and the above syntax is wrong.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
--
Christophe Gravier
Laboratoire DIOM, groupe SATIn - Doctorant
ISTASE - Ingénieur d'études
Perso: http://perso.univ-st-etienne.fr/gravchri/
SATIn: http://www.istase.com/satin
Tel : 04 7748 5034
A mediter: http://www.fsffrance.org/news/article2005-11-25.fr.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Freeradius and LDAP : to be continued
Hi,
rather confusing. I have to admit, I have never used chillispot, but I've
just visited their website and in FAQ I found Why should I use
CHAP-Challenge and CHAP-Password? so this makes me think that Chillispot
uses CHAP authorization. And when you use CHAP, you do NOT need LDAP as
authorisation, but as a password storage. Okay - great.. what now?
When you look at your radiusd.conf file there is a part where you can define
your LDAP server etc..
ldap ldap_users {
server = 81.xx
# identity = cn=admin,o=My Org,c=UA
# password = mypass
basedn = ou=People,dc=xxx,dc=xx
filter = ((objectClass=posixAccount)(uid=%u))
start_tls = no
..
# Mapping of RADIUS dictionary attributes to LDAP
# directory attributes.
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 10
# password_header = {clear}
password_attribute = userPassword
timeout = 4
timelimit = 3
net_timeout = 1
# compare_check_items = yes
# access_attr_used_for_allow = yes
}
I hope you have that right ( this is only a part of my working config ).
Next, what Alan said is to change the authorisation part. As I said -
chillispot aparently wants CHAP, so in following section use CHAP
authorize {
# The chap module will set 'Auth-Type := CHAP' if we are
# handling a CHAP request and Auth-Type has not already been set
Chap
# here you can also have
ldap_users
# for radtest to work ( IMHO it should be like this )
}
And in
authenticate {
# Most people want CHAP authentication
# A back-end database listed in the 'authorize' section
# MUST supply a CLEAR TEXT password. Encrypted passwords
# won't work.
Auth-Type CHAP {
chap
ldap_users
}
}
As it says in authenticate section - passwords in LDAP should be in clear
text...
Try this out. I cannot promise you that it will work, but it is the same way
I have set up my POPTOP server with MS-CHAP, and it works.. I would also
appreciate some guru to take a look at this and publish his opinion about
this on this list ;)
Kind regards,
Edvin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christophe Gravier
Sent: Donnerstag, 15. Dezember 2005 16:41
To: FreeRadius users mailing list
Subject: Re: Freeradius and LDAP : to be continued
Hello Edvin,
First, I received my email posted to the list several times in my mail
client.
I higly hope this is not the case for all you ! (if it is, thunderbird
didn't like to switch from the testing wireless network back to cable
and vice versa, since they're all dated to the same hour)
If you received only one mail, it is OK, just forget what I told ;-)
For what I am trying to do:
I have an existing LDAP directory with all users being able to connect
to the wireless area.
The hotspot architecture is :
client - chillispot (login page served with apache2 + ssl) -
freeradius - ldap.
I just want my ldap users being able to connect to the hotspot.
So, *at first*, I edited the conf file to let users be authenticate via
LDAP.
This way, radtest way just OK but not ChilliSpot. When I report it to
the list, asking how radtest is different to chillispot login, Alan
explained me:
You're using LDAP as an authentication server. Don't do that. Use LDAP
to store passwords.
i.e. remove the ldap entry from the authenticate section. Get
radtest to work. Once that works, Chillispot will work, too.
So I remove ldap from authentificate (I let it in authorize section
thgouh).
But it still doesn't solve the problem.
In the end, Alan proposed to hack rlm_ldap.c to have it *never* set
Auth-Type to LDAP. That would solve a lot of problems.
I just find it dirty to hack the radius then recompile to get ldap
support :-(
If you're using LDAP for your users accessing the hotspot, would you
please tell me how you achieve this ?
Best Regards,
Seferovic Edvin wrote:
Hello,
I must admit, I have been reading this thread, but I still do not
understand
what Christophe is trying to accomplish. As far as I understand - you have
your passwords in LDAP, and you only ( kind of ) need to authorize but NOT
authenticate users that are in your LDAP directory..
Please correct me...
Regards,
Edvin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christophe Gravier
Sent: Donnerstag, 15. Dezember 2005 16:05
To: FreeRadius users mailing list
Subject: Re: Freeradius and LDAP : to be continued
Phil Mayers wrote:
Alan DeKok wrote:
[EMAIL PROTECTED] wrote:
rlm_ldap: Adding userPassword as User-Password, value { op
Re: Freeradius and LDAP : to be continued
rather confusing. I have to admit, I have never used chillispot, but I've just visited their website and in FAQ I found Why should I use CHAP-Challenge and CHAP-Password? so this makes me think that Chillispot uses CHAP authorization. And when you use CHAP, you do NOT need LDAP as authorisation, but as a password storage. Okay - great.. what now? You can setup chillispot to use PAP too. see the documentation about uamsecret. -- damjan | дамјан This is my jabber ID -- [EMAIL PROTECTED] -- not my mail address!!! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Seferovic Edvin wrote:
Hi,
rather confusing. I have to admit, I have never used chillispot, but I've
just visited their website and in FAQ I found Why should I use
CHAP-Challenge and CHAP-Password? so this makes me think that Chillispot
uses CHAP authorization. And when you use CHAP, you do NOT need LDAP as
authorisation, but as a password storage. Okay - great.. what now?
This is really good summary of the situation ;-)
When you look at your radiusd.conf file there is a part where you can define
your LDAP server etc..
ldap ldap_users {
server = 81.xx
# identity = cn=admin,o=My Org,c=UA
# password = mypass
basedn = ou=People,dc=xxx,dc=xx
filter = ((objectClass=posixAccount)(uid=%u))
start_tls = no
..
# Mapping of RADIUS dictionary attributes to LDAP
# directory attributes.
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 10
# password_header = {clear}
password_attribute = userPassword
timeout = 4
timelimit = 3
net_timeout = 1
# compare_check_items = yes
# access_attr_used_for_allow = yes
}
I hope you have that right ( this is only a part of my working config ).
I have :
ldap {
server = my.server.name.here
basedn = ou=person,o=istase,c=fr
filter = (uid=%{Stripped-User-Name:-%{User-Name}})
start_tls = no
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
}
I think this shall be rather good since I can see it searching in ldap
log if I launch slapd in debug mode. (nentries = 1 : OK, it founds my
userPassword using this filter -my filter seems different from yours).
Also, the User-Password-userPassword mapping is done in ldap.attrmap in
my case.
Next, what Alan said is to change the authorisation part. As I said -
chillispot aparently wants CHAP, so in following section use CHAP
authorize {
# The chap module will set 'Auth-Type := CHAP' if we are
# handling a CHAP request and Auth-Type has not already been set
Chap
# here you can also have
ldap_users
# for radtest to work ( IMHO it should be like this )
}
And in
authenticate {
# Most people want CHAP authentication
# A back-end database listed in the 'authorize' section
# MUST supply a CLEAR TEXT password. Encrypted passwords
# won't work.
Auth-Type CHAP {
chap
ldap_users
}
}
As it says in authenticate section - passwords in LDAP should be in clear
text...
My password are not stored in LDAP in clear text but hashed using SHA
algorythm, so this won't work ;-(
Try this out. I cannot promise you that it will work, but it is the same way
I have set up my POPTOP server with MS-CHAP, and it works.. I would also
appreciate some guru to take a look at this and publish his opinion about
this on this list ;)
Kind regards,
Edvin
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christophe Gravier
Sent: Donnerstag, 15. Dezember 2005 16:41
To: FreeRadius users mailing list
Subject: Re: Freeradius and LDAP : to be continued
Hello Edvin,
First, I received my email posted to the list several times in my mail
client.
I higly hope this is not the case for all you ! (if it is, thunderbird
didn't like to switch from the testing wireless network back to cable
and vice versa, since they're all dated to the same hour)
If you received only one mail, it is OK, just forget what I told ;-)
For what I am trying to do:
I have an existing LDAP directory with all users being able to connect
to the wireless area.
The hotspot architecture is :
client - chillispot (login page served with apache2 + ssl) -
freeradius - ldap.
I just want my ldap users being able to connect to the hotspot.
So, *at first*, I edited the conf file to let users be authenticate via
LDAP.
This way, radtest way just OK but not ChilliSpot. When I report it to
the list, asking how radtest is different to chillispot login, Alan
explained me:
You're using LDAP as an authentication server. Don't do that. Use LDAP
to store passwords.
i.e. remove the ldap entry from the authenticate section. Get
radtest to work. Once that works, Chillispot will work, too.
So I remove ldap from authentificate (I let it in authorize section
thgouh).
But it still doesn't solve the problem.
In the end, Alan proposed to hack rlm_ldap.c to have it *never* set
Auth-Type to LDAP. That would solve a lot of problems.
I just find it dirty to hack the radius then recompile to get
Re: Freeradius and LDAP : to be continued
Hello
I have a chillispot that works with OpenLDAP
on a Debian box
here are the modifications in radiusd.conf I wrote
# Lightweight Directory Access Protocol (LDAP)
#
# This module definition allows you to use LDAP for
# authorization and authentication (Auth-Type := LDAP)
#
# See doc/rlm_ldap for description of configuration options
# and sample authorize{} and authenticate{} blocks
ldap {
server = your.ldap.server
basedn = ou=Person,dc=domain,dc=
#filter = (posixAccount)(uid=%u))
filter = (uid=%{Stripped-User-Name:-%{User-Name}})
# base_filter = (objectclass=radiusprofile)
access_attr = uid
# Mapping of RADIUS dictionary attributes to LDAP
# directory attributes.
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
hope this helps
--
Cordialement
Frank Bonnet
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Frank Bonnet wrote:
Hello
I have a chillispot that works with OpenLDAP
on a Debian box
Strictly the same thing I want to achieve indeed ! ;-)
How are your password in your LDAP ? (clear ? hash form ?)
Moreover, except this configuration of the ldap remote server, what did
you put in authorize and authentificate section ?
What did you put in the ldap.attrmap, only the mapping of the user
password ?
I must admit I am loosing my common sense here :-)
here are the modifications in radiusd.conf I wrote
# Lightweight Directory Access Protocol (LDAP)
#
# This module definition allows you to use LDAP for
# authorization and authentication (Auth-Type := LDAP)
#
# See doc/rlm_ldap for description of configuration options
# and sample authorize{} and authenticate{} blocks
ldap {
server = your.ldap.server
basedn = ou=Person,dc=domain,dc=
#filter = (posixAccount)(uid=%u))
filter = (uid=%{Stripped-User-Name:-%{User-Name}})
# base_filter = (objectclass=radiusprofile)
access_attr = uid
# Mapping of RADIUS dictionary attributes to LDAP
# directory attributes.
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5
hope this helps
--
Christophe Gravier
Laboratoire DIOM, groupe SATIn - Doctorant
ISTASE - Ingénieur d'études
Perso: http://perso.univ-st-etienne.fr/gravchri/
SATIn: http://www.istase.com/satin
Tel : 04 7748 5034
A mediter: http://www.fsffrance.org/news/article2005-11-25.fr.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Christophe Gravier wrote:
My password are not stored in LDAP in clear text but hashed using SHA
algorythm, so this won't work ;-(
Ok, let's take a breath. First things first:
If your passwords are in SHA (which they are) your Radius server will
ONLY be able to answer PAP requests.
The very first log you sent in this thread indicates you have ChilliSpot
set to use CHAP:
rlm_ldap: - authenticate
rlm_ldap: Attribute User-Password is required for authentication.
Cannot use CHAP-Password.
modcall[authenticate]: module ldap returns invalid for request 0
modcall: group Auth-Type returns invalid for request 0
auth: Failed to validate the user.
'''Cannot use CHAP-Password''' - indicates the request (from
ChilliSpot) came in with CHAP credentials.
First, fix that. See here:
http://archives.free.net.ph/message/20051025.180818.4d829f18.en.html
Next, since you have SHA passwords and can only answer PAP, you have two
choices:
1. Extract the SHA password and add it to the config items, then
configure the Radius servers PAP module to check it:
modules {
pap {
encryption_scheme = sha1
}
ldap {
# settings go here
}
}
authorize {
preprocess
ldap
}
authenticate {
Auth-Type PAP {
pap
}
}
HOWEVER - this may not work. The SHA that your LDAP server uses may be
slightly different (salting, keying) than the SHA FreeRadius uses.
Much more likely to trip you up though, is when ldap matches in
authorize, it will set Auth-Type = LDAP, so you either need to disable
that or otherwise make it work and there are about 6 different ways of
doing that. The most obvious would be to replace the above with:
modules { as before }
authorize { as before }
authenticate {
Auth-Type LDAP {
pap
}
}
But it might not work. Alternatively and probably simpler (but less
formally correct) is the 2nd method:
2. Configure the LDAP module to find the user, set Auth-Type==LDAP
then authenticate the user via simple bind:
authorize {
preprocess
ldap
}
authenticate {
Auth-Type LDAP {
ldap
}
}
...and assuming the ldap modules is setup correctly, what will happen is:
A. authorize called
1. preprocess called
2. suffix realm called - no-op probably
3. files called - no-op probably but DO NOT SET Auth-Type
4. ldap called - search succeeds, and Ldap-UserDN is set, and
Auth-Type set to LDAP
B. authenticate called
1. Auth-Type == LDAP, so ldap called and simple bind performed
And it WILL WORK.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Christophe Gravier wrote:
My password are not stored in LDAP in clear text but hashed using SHA
algorythm, so this won't work ;-(
Ok, let's take a breath.
Yes, I agree, that's why I quit for today ;-)
First things first:
If your passwords are in SHA (which they are) your Radius server will
ONLY be able to answer PAP requests.
H that's explain why I'll never make it with CHAP.
I thought it would be able to get the plain text password, then use SHA to
match it against ldap... But it seems PAP is required to do that
(regarding your method 1.)
The very first log you sent in this thread indicates you have
ChilliSpot set to use CHAP:
rlm_ldap: - authenticate
rlm_ldap: Attribute User-Password is required for authentication.
Cannot use CHAP-Password.
modcall[authenticate]: module ldap returns invalid for request 0
modcall: group Auth-Type returns invalid for request 0
auth: Failed to validate the user.
'''Cannot use CHAP-Password''' - indicates the request (from
ChilliSpot) came in with CHAP credentials.
First, fix that. See here:
http://archives.free.net.ph/message/20051025.180818.4d829f18.en.html
First thing I'll do back to work.
Next, since you have SHA passwords and can only answer PAP, you have
two choices:
1. Extract the SHA password and add it to the config items, then
configure the Radius servers PAP module to check it:
modules {
pap {
encryption_scheme = sha1
}
ldap {
# settings go here
}
}
authorize {
preprocess
ldap
}
authenticate {
Auth-Type PAP {
pap
}
}
HOWEVER - this may not work. The SHA that your LDAP server uses may
be slightly different (salting, keying) than the SHA FreeRadius uses.
Much more likely to trip you up though, is when ldap matches in
authorize, it will set Auth-Type = LDAP, so you either need to disable
that or otherwise make it work and there are about 6 different ways
of doing that. The most obvious would be to replace the above with:
modules { as before }
authorize { as before }
authenticate {
Auth-Type LDAP {
pap
}
}
But it might not work. Alternatively and probably simpler (but less
formally correct) is the 2nd method:
2. Configure the LDAP module to find the user, set Auth-Type==LDAP
then authenticate the user via simple bind:
authorize {
preprocess
ldap
}
authenticate {
Auth-Type LDAP {
ldap
}
}
...and assuming the ldap modules is setup correctly, what will happen
is:
A. authorize called
1. preprocess called
2. suffix realm called - no-op probably
3. files called - no-op probably but DO NOT SET Auth-Type
4. ldap called - search succeeds, and Ldap-UserDN is set, and
Auth-Type set to LDAP
B. authenticate called
1. Auth-Type == LDAP, so ldap called and simple bind performed
And it WILL WORK.
Thank you a lot, things getting a little more clearer now.
I will try these settings tomorrow morning, from method 1 and then method 2.
I am really thankfull to the quality of your answer and the time you spent
to write it down.
Cheers,
Christophe.
-
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: Freeradius and LDAP : to be continued
Phil Mayers [EMAIL PROTECTED] wrote: Ok, let's take a breath. First things first: ... Could this be a Wiki page? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Freeradius and LDAP : to be continued
Hello, From the last things settled today about ldap support for freeradius on the list, I succeeded in configuring the ldap backend for freeradius. At least, radtest provides me an Accept response ! Nevertheless, with the front chillispot, I can't login, freeradius tells: rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ist-guizay.univ-st-etienne.fr:389, authentication 0 rlm_ldap: bind as / to ist-guizay.univ-st-etienne.fr:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=person,o=istase,c=fr, with filter (uid=gravier.christophe) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user gravier.christophe authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type LDAP auth: type LDAP Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: Attribute User-Password is required for authentication. Cannot use CHAP-Password. modcall[authenticate]: module ldap returns invalid for request 0 modcall: group Auth-Type returns invalid for request 0 auth: Failed to validate the user. That's pretty strange since it does work with radtest (But I see a plain text password being sent to openldap :s). Anyway, the problem comes from : rlm_ldap: Attribute User-Password is required for authentication. Cannot use CHAP-Password. But I DO have told: password_attribute = userPassword for my ldap server in /etc/freeradius/radiusd.conf I mean, there's no configuration in chillispot expect the radius server IP to match users against. What's the difference between a radtest and a authentification via chillispot ? Apart from this chilli-freeradius problem (towards radtest), how can I make freeradius sent a hash as password ? (my userPassword is hash using SHA). There is a porposal here : http://lists.cistron.nl/pipermail/freeradius-users/2002-October/012169.html, but I don't want to use CHAP since my userPassword in SHA encrypted. I tried to comment in authorize section the chap and mschap part (I'll never use it). (same error). (I must say I followed http://www.linuxhomenetworking.com/linux-adv/ldap.htm#_Toc92561284 howto for configuring ldap for freeradius). Please, feel free to point me some directions to search. Best regards, Christophe. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Christophe Gravier [EMAIL PROTECTED] wrote: auth: type LDAP Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: Attribute User-Password is required for authentication. Cannot use CHAP-Password. You're using LDAP as an authentication server. Don't do that. Use LDAP to store passwords. i.e. remove the ldap entry from the authenticate section. Get radtest to work. Once that works, Chillispot will work, too. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Alan DeKok wrote: Christophe Gravier [EMAIL PROTECTED] wrote: auth: type LDAP Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 0 rlm_ldap: - authenticate rlm_ldap: Attribute User-Password is required for authentication. Cannot use CHAP-Password. You're using LDAP as an authentication server. Don't do that. Use LDAP to store passwords. i.e. remove the ldap entry from the authenticate section. Get radtest to work. Once that works, Chillispot will work, too. Alan DeKok. That makes sense indeed. Removing the ldap entry, radtest no longer works of course. But as you already said there : http://lists.cistron.nl/pipermail/freeradius-users/2004-October/037625.html and there: http://lists.cistron.nl/pipermail/freeradius-users/2004-September/036629.html : List ldap in the authorize section. It's already there, just un-comment it. And DON'T set Aut-Type := LDAP. So I did # The ldap module will set Auth-Type to LDAP if it has not # already been set ldap and comment set Aut-Type := LDAP But it's just not working ! The trace interesting: [...] rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to ist-guizay.univ-st-etienne.fr:389, authentication 0 rlm_ldap: bind as / to ist-guizay.univ-st-etienne.fr:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=person,o=istase,c=fr, with filter (uid=gravier.christophe) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user gravier.christophe authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap 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: No '@' in User-Name = gravier.christophe, looking up realm NULL rlm_realm: No such realm NULL modcall[authorize]: module suffix returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module eap returns noop for request 0 users: Matched entry DEFAULT at line 153 users: Matched entry DEFAULT at line 157 modcall[authorize]: module files returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for gravier.christophe radius_xlat: '(uid=gravier.christophe)' radius_xlat: 'ou=person,o=istase,c=fr' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=person,o=istase,c=fr, with filter (uid=gravier.christophe) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user gravier.christophe authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module ldap returns ok for request 0 modcall: group authorize returns ok for request 0 rad_check_password: Found Auth-Type LDAP auth: type LDAP ERROR: Unknown value specified for Auth-Type. Cannot perform requested action. auth: Failed to validate the user. Delaying request 0 for 1 seconds Finished request 0 [...] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Christophe Gravier Laboratoire DIOM, groupe SATIn - Doctorant ISTASE - Ingénieur d'études Perso: http://perso.univ-st-etienne.fr/gravchri/ SATIn: http://www.istase.com/satin Tel : 04 7748 5034 A mediter: http://www.fsffrance.org/news/article2005-11-25.fr.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Christophe Gravier [EMAIL PROTECTED]wrote: Removing the ldap entry, radtest no longer works of course. Did you put ldap in the authorize section? That would allow radtest to work, as I said. rlm_ldap: looking for check items in directory... Can you say which LDAP server you're using? It is NOT returning the User-Password attribute. My previous message said that the goal was for the ldap module to return the password in the authorize section. Make that work. radtest will work, and then everything else will work. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Freeradius and LDAP : to be continued
Christophe Gravier [EMAIL PROTECTED]wrote:
Removing the ldap entry, radtest no longer works of course.
Did you put ldap in the authorize section? That would allow
radtest to work, as I said.
Yes, I did like we said:
- did put ldap (it was already indeed) in authorize section.
- did remove ldap from authenticate (since ldap will only be a password
storage).
rlm_ldap: looking for check items in directory...
Can you say which LDAP server you're using?
ist-guizay:/root# /usr/sbin/slapd -V
@(#) $OpenLDAP: slapd 2.2.26 (Oct 31 2005 09:10:53) $
This is slapd package on current debian testing tree. This is a v3
openldap server, if I am right.
If I make slapd log things and then observe I've got on a freeradius request:
Dec 14 21:48:03 ist-guizay slapd[31741]: conn=2 fd=10 ACCEPT from
IP=161.3.50.125:1490 (IP=0.0.0.0:389)Dec 14 21:48:03 ist-guizay slapd[31741]:
conn=2 op=0 BIND dn= method=128
Dec 14 21:48:03 ist-guizay slapd[31741]: conn=2 op=0 RESULT tag=97 err=0
text=Dec 14 21:48:03 ist-guizay slapd[31741]: conn=2 op=1 SRCH
base=ou=person,o=istase,c=fr scope=2 deref=0
filter=(uid=gravier.christophe)Dec 14 21:48:03 ist-guizay slapd[31741]:
conn=2 op=1 SRCH
attr=radiusExpiration acctFlags ntPassword lmPassword
radiusCallingStationId radiusCalledStationId radiusSimultaneousUse eap
userPassword radiusCheckItem radiusLoginLATPort radiusPortLimit
radiusFramedAppleTalkZone radiusFramedAppleTalkNetwork
radiusFramedAppleTalkLink radiusLoginLATGroup radiusLoginLATNode
radiusLoginLATService radiusTerminationAction radiusIdleTimeout
radiusSessionTimeout radiusClass radiusFramedIPXNetwork radiusCallbackId
radiusCallbackNumber radiusLoginTCPPort radiusLoginService
radiusLoginIPHost radiusFramedCompression radiusFramedMTU radiusFilterId
radiusFramedRouting radiusFramedRoute radiusFramedIPNetmask
radiusFramedIPAddress radiusFramedProtocol radiusServiceType
radiusReplyItem userPasswordDec 14 21:50:47 ist-guizay slapd[31741]: =
bdb_equality_candidates: (uid)
index_param failed (18)Dec 14 21:50:47 ist-guizay slapd[31741]: conn=2 op=2
SEARCH RESULT tag=101
err=0 nentries=1 text=
Whaou .. person doesn't have all those attributes on my schema.
(note that this search got a result: nentries = 1 !)
I edited /etc/freeradius/ldap.attr, so that now the trace is a little more
correct:
Dec 14 21:55:27 ist-guizay slapd[31741]: conn=76 op=2 SRCH
base=ou=person,o=istase,c=fr scope=2 deref=0
filter=(uid=gravier.christophe)Dec 14 21:55:27 ist-guizay slapd[31741]:
conn=76 op=2 SRCH attr=userPassword
Dec 14 21:55:27 ist-guizay slapd[31741]: = bdb_equality_candidates: (uid)
index_param failed (18)Dec 14 21:55:27 ist-guizay slapd[31741]: conn=76 op=2
SEARCH RESULT
tag=101 err=0 nentries=1 text=
(please ignore the bdb_equality_candidates).
I thought this has to do with the policy regarding access to userPassword
field, so I gave full rights for a test via slapd.access.con: still not
good. (that sounds ok since if it was a read/write/search/auth problem, I
would had seen it in the slapd logging).
I think it is OK with ldap because nentries = 1 for the search (it
finnds me). The problem should be for freeradius to use that password to
match it against the one given by the user.
For autorize and authenticate I have:
authorize {
preprocess
chap
mschap
suffix
files
ldap
}
authenticate {
Auth-Type PAP {
pap
}
unix
eap
}
As I said, I think this is freeradius related since openldap log that it
finds the userPassword for the given user and scope.
But I can't set freeradius in a more verbose mode to understand the problem.
I still receive:
(...)
rlm_ldap: - authorize
rlm_ldap: performing user authorization for gravier.christophe
radius_xlat: '(uid=gravier.christophe)'
radius_xlat: 'ou=person,o=istase,c=fr'
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 ist-guizay.univ-st-etienne.fr:389, authentication 0
rlm_ldap: bind as / to ist-guizay.univ-st-etienne.fr:389
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in ou=person,o=istase,c=fr, with filter
(uid=gravier.christophe)rlm_ldap: looking for check items in directory...
rlm_ldap: looking for reply items in directory...
rlm_ldap: Adding userPassword as User-Password, value { op=11
rlm_ldap: user gravier.christophe authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module ldap returns ok for request 0
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
auth: type LDAP
ERROR: Unknown value specified for Auth-Type. Cannot perform requested
action.auth: Failed to validate the user.
When running /usr/sbin/freeradius -X -f
It is NOT returning the User-Password attribute. My previous
message said that the goal was for the ldap module to return the
password in the authorize section.
Make that work. radtest will work, and then everything else will
