Martin Pauly wrote:
> 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). 

  There's no reason why that won't work.

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

  Nothing.  It should work using the default configuration file in
1.1.7, and minor edits to get LDAP to work.

  Post the debugging output.

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

Reply via email to