DEFAULT entry in users file and LDAP, again

[tnt at kalik.co.yu]

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" <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?
>
>Thanks, Martin     
>
>-- 
>  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
>
>