Alan DeKok wrote:

Christophe Gravier <christophe.gravier@univ-st-etienne.fr> 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.htm... : 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

Christophe Gravier <christophe.gravier@univ-st-etienne.fr>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 work.

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

Alan DeKok wrote:

<christophe.gravier@univ-st-etienne.fr> 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 ...)

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

Alan DeKok wrote:

<christophe.gravier@univ-st-etienne.fr> 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.... 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.

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: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] 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:

...

<christophe.gravier@univ-st-etienne.fr> 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

Argggg. 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

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.xxxxxxxxxx" # 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: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] 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: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] 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:

...

<christophe.gravier@univ-st-etienne.fr> 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

Argggg. 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

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.xxxxxxxxxx" # 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: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] 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: freeradius-users-bounces@lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] 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:

...

<christophe.gravier@univ-st-etienne.fr> 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

Argggg. 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

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.

Haaaa 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

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" 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

-- 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

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