rlm_ldap behavior: authorize v.s. authenticate

[Brian A. Seklecki]

I ask because I set:

              password_header = "{clear}"
              password_attribute = cfAppPassword

...and make my users choose a "weak" or "secondary" password for all 
services that authenticate off of LDAP-via-FreeRADIUS (802.11x, VPN, etc.)

However, this permits for "Authentication", but the "Authorization" step 
is broken due to the the "Bind-as-the-user" logic.

So for the Cisco 1200 AP with EAP/PEAP (Windows XP), I have to setup one 
instance of FreeRADIUS with:

authenticate {
         Auth-Type LDAP {
                 eap
         }
}

And for Cisco VPN3000 with non-EAP:

authenticate {
         Auth-Type LDAP {
                 pap
         }
}

I then backup the cleartext-stored LDAP password by requiring client SSL 
certificates.

It would just be nice if the behavior was a flag.  More than likely I 
don't understand how the protocol is supposed to work with regard to 
Authorization v.s. Authentication

~BAS

On Fri, 9 Dec 2005, Alan DeKok wrote:

> "Brian A. Seklecki" <lavalamp at spiritual-machines.org> wrote:
>> If on the authorization stage, the module can read (and cache) the entire
>> DN's attribute set (actually, any DN in the LDAP), why does it need to use
>> a "re-connect as the user" method for authentication?
>
>  Because some LDAP servers don't supply the password.
>
>  Also, some administrators use LDAP only for authentication.
>
>> If the password in cleartext, comparison is easy.  If it's in
>> SSHA/SHA/MD5/blowfish/crypt, then the comparison can happen against
>> those algorithms.
>
>  Which is the default behavior of the server.
>
>  Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>

l8*
 	-lava

x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8