rlm_ldap behavior: authorize v.s. authenticate
From reading debug logs, am I correct in concluding that rlm_ldap's behavior:
- when processing authorize{ } is to bind to the LDAP as the provided administrative DN and search for the DN of the user in the Access-Request packet - when processing authenticate{ } is to, if successful during authorize, then re-bind to the LDAP using the provided username and password and return Access-Accept only if the bind-as-the-user succeeds? Correct, as the default behavior? ~BAS
From reading debug logs, am I correct in concluding that rlm_ldap's behavior:
- when processing authorize{ } is to bind to the LDAP as the provided administrative DN and search for the DN of the user in the Access-Request packet
- when processing authenticate{ } is to, if successful during authorize, then re-bind to the LDAP using the provided username and password and return Access-Accept only if the bind-as-the-user succeeds?
Correct, as the default behavior?
Sounds right to me.
On Fri, 9 Dec 2005, Dusty Doris wrote:
From reading debug logs, am I correct in concluding that rlm_ldap's
Correct, as the default behavior?
Sounds right to me.
I have to ask then: 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? 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. ~BAS
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
"Brian A. Seklecki" <lavalamp@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.
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@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
participants (3)
-
Alan DeKok -
Brian A. Seklecki -
Dusty Doris