DEFAULT entry in users file and LDAP, again
tnt at kalik.co.yu
tnt at kalik.co.yu
Mon Dec 17 14:11:38 CET 2007
No passworrd for that user was found in Ldap or anywhere else in step 1.
The fact that there is a password in the request is irrelevant. Server
won't go back to Ldap in step 2 - no point, it looked in Ldap and there
was no password.
Kalik Informatika ISP
Dana 17/12/2007, "Martin Pauly" <pauly at hrz.uni-marburg.de> piše:
>On Saturday 15 December 2007 08:38, Alan DeKok wrote:
>> No. The problem is the WARNING message just before that. You haven't
>> told the server what the "known good" password is, so the server has NO
>> WAY to authenticate the user.
>I tested with radtest, as before. All of my real-world access-requests
>currently come to the NASes some sort of PAP: Either traditional PAP in
>PPP or PAP in EAP-TTLS. In either case, the RADIUS request contains a
>password in clear text. The corresponding database is in the LDAP
>server with the passwords stored as salted UNIX crypt (quite traditional).
>With my 1.0.5 freeradius, the sequence is pretty much straightforward:
>1. Search for the user in LDAP using the given basedn and filter
> to obtain authorization information.
>2. If all goes well (i.e. search result is unique and user is authorized),
> try another LDAP login as the newly found user-DN -- using the password
> from the Access-Request packet, of course.
>3. If this succeeds, the password has implicitly been confirmed by the
> LDAP-Server --> send Access-Accept, otherwise --> send Access-Deny
>So step 1 seems o.k., right? What then is missing to trigger step 2?
> Dr. Martin Pauly Fax: 49-6421-28-26994
> HRZ Univ. Marburg Phone: 49-6421-28-23527
> Hans-Meerwein-Str. E-Mail: pauly at HRZ.Uni-Marburg.DE
> D-35032 Marburg
>List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
More information about the Freeradius-Users