Gah!
Of course this isn't explained or documented anywhere and it's complete
guess-work, but authorize {} should be module LDAP (and presumably it
caches the LDIF for the user, including whtever the heck
password_attribute your arbitrate).
Then set authenticate {} to eap.
Auth-Type LDAP {
eap
}
I'll explain later, my mind turns to mush whenever I try to troubleshoot
this.
~BAS
On Tue, 15 Nov 2005, Brian A. Seklecki wrote:
Cisco AP1200 + OpenLDAP + MS-CHAPv2 + EAP configuration (WPA2, basically,
right?)
So obviously, everyone's userPassword attribute cannot be maintained in
cleartext in the LDAP database. If I modify my schema and create a
"weakPassword" attribute using the following template:
#attributetype ( 2.5.4.35 NAME 'userPassword'
# DESC 'RFC2256/2307: password of user'
# EQUALITY octetStringMatch
# SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
Populate it with a {clear} prefix ...and then change the password_attribute
in radiusd.conf(5).
When the user associates to the AP, authorize works but authenticate fails
because the LDAP module is then attempting to bind to the LDAP server as the
user.
Why does it do this? It can pull all of the LDIF info for the user when it
first connects.
rlm_ldap: - authorize
rlm_ldap: performing user authorization for bkaplan
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: attempting LDAP reconnection
rlm_ldap: (re)connect to blah:389, authentication 0
rlm_ldap: setting TLS CACert File to /blah
rlm_ldap: starting TLS
rlm_ldap: bind as cn=RADIUS,foo... to foo.com:11
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind was successful
rlm_ldap: performing search in dc=blah
rlm_ldap: Added password {CLEAR}secret in check items
rlm_ldap: looking for check items in directory...
rlm_ldap: Adding radiusAuthType as Auth-Type, value wifi & op=21
rlm_ldap: looking for reply items in directory...
rlm_ldap: user bkaplan authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
modcall[authorize]: module "ldap" returns ok for request 0
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type LDAP
auth: type "LDAP"
*********** But then: *****
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
rlm_ldap: - authenticate
rlm_ldap: login attempt by "bkaplan" with password "WRONG"
rlm_ldap: user DN: blah...
rlm_ldap: (re)connect to foo:389, authentication 1
rlm_ldap: setting TLS CACert File to /blah
rlm_ldap: starting TLS
rlm_ldap: bind as cn=blah=foo,blahfoo,blah blah
rlm_ldap: waiting for bind result ...
rlm_ldap: Bind failed with invalid credentials
modcall[authenticate]: module "ldap" returns reject for request 0
modcall: group authenticate returns reject for request 0
auth: Failed to validate the user.
Login incorrect (rlm_ldap: Bind as user failed): [bkaplan/WRONG] (from client
blah port 1812)
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
Why in the world is it using different logic to authorize v.s. authenticate?
Head -> Wall
Head -> Wall
~BAS
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
l8*
-lava
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
