changing password_attribute

[Brian A. Seklecki]

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