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