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.
Ivan Kalik Kalik Informatika ISP Dana 17/12/2007, "Martin Pauly" <[EMAIL PROTECTED]> 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? > >Thanks, Martin > >-- > Dr. Martin Pauly Fax: 49-6421-28-26994 > HRZ Univ. Marburg Phone: 49-6421-28-23527 > Hans-Meerwein-Str. E-Mail: [EMAIL PROTECTED] > D-35032 Marburg >- >List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html