Yet another PEAP/LDAP Question
Jon P. Giza
jon at xbytenetworks.com
Wed Jan 25 18:06:59 CET 2006
Phil:
I have made the suggested changes, and new debug's below:
rlm_ldap: looking for check items in directory...
rlm_ldap: Adding userPassword as NT-Password, value ( & op=21
rlm_ldap: looking for reply items in directory...
...
modcall: entering group MS-CHAP for request 5
rlm_mschap: No User-Password configured. Cannot create LM-Password.
rlm_mschap: Invalid NT-Password
rlm_mschap: Told to do MS-CHAPv2 for jon.giza with NT-Password
rlm_mschap: FAILED: No NT/LM-Password. Cannot perform authentication.
rlm_mschap: FAILED: MS-CHAP2-Response is incorrect
modcall[authenticate]: module "mschap" returns reject for request 5
I tried the same update with LM-Password, with the same results.
Is the response saying that the supplied password is invalid, or the ldap
stored password?
Thanks
JPG
> -----Original Message-----
> From: freeradius-users-bounces+jon=xbytenetworks.com at lists.freeradius.org
> [mailto:freeradius-users-
> bounces+jon=xbytenetworks.com at lists.freeradius.org] On Behalf Of Phil
> Mayers
> Sent: Wednesday, January 25, 2006 10:39 AM
> To: FreeRadius users mailing list
> Subject: Re: Yet another PEAP/LDAP Question
>
> Jon P. Giza wrote:
> > Hello all:
> >
> > I am trying to setup a 802.1x WiFi authentication system using
> freeradius.
> > My setup is as follows:
> >
> > Windows XP SP2 as the supplicant using PEAP/MSCHAPv2
> > Cisco Aironet 1231
> > Freeradius 1.1.0
> > IBM Lotus Domino LDAP
> >
> > The process is mostly working - Freeradius binds to LDAP properly, the
> User
> > gets authorized, Freeradius pulls the correct password hash from the
> Domino
> > LDAP server.. But, then the MSCHAP portion fails. Portion of the log is
> > shown below which I believe shows the problem.
> >
> > I am thinking that the problem is that I am not telling Freeradius how
> to
> > hash the supplied password correctly to match the Domino password. The
> > aggravating part is that we are using the exact same Domino LDAP server
> to
> > authenticate our VPN users.
>
> That's only relevant if the VPN is using MS-CHAP to authenticate, and
> even then only if it's doing it by extracting the hash as opposed to
> "some other" method.
>
> >
> > Full (sanatized) copy of the debug output is here:
> > http://www.xbytenetworks.com/debug-log.txt
> > Copy of Radiusd.conf is here: http://www.xbytenetworks.com/radiusd.conf
> >
> > Thanks in advance for any help you can offer.
> >
> > Jon
> >
> >
> > rlm_ldap: - authorize
> > rlm_ldap: performing user authorization for jon.giza
> > radius_xlat: '(uid=jon.giza)'
> > radius_xlat: 'OU=Waukesha,OU=NA,O=MyCo'
> > rlm_ldap: ldap_get_conn: Checking Id: 0
> > rlm_ldap: ldap_get_conn: Got Id: 0
> > rlm_ldap: performing search in OU=Waukesha,OU=NA,O=MyCo, with filter
> > (uid=jon.giza)
> > rlm_ldap: Added password (6BDC5527858B28XXXXXXXXXEFAF2323F) in check
> items
>
> That looks like the right format to be an NT hash. However, the default
> radiusd.conf (and yours) says:
>
> # NOTICE: The password_header directive is NOT case insensitive
> #
> # password_header = "{clear}"
> #
> # Set:
> # password_attribute = nspmPassword
> #
> # to get the user's password from a Novell eDirectory
> # backend. This will work *only if* freeRADIUS is
> # configured to build with --with-edir option.
> #
> #
> # The server can usually figure this out on its own, and pull
> # the correct User-Password or NT-Password from the database.
> #
> # Note that NT-Passwords MUST be stored as a 32-digit hex
> # string, and MUST start off with "0x", such as:
> #
> # 0x000102030405060708090a0b0c0d0e0f
> #
> # Without the leading "0x", NT-Passwords will not work.
> # This goes for NT-Passwords stored in SQL, too.
>
> Having said that, I don't see any evidence of this so-called "figuring
> out" in the rlm_ldap source code - it looks to me like it does this:
>
> if password_attribute:
> val = ldap_result_attr(password_attribute)
> if password_header:
> if val.startswith(password_header):
> val = val.remove(password_header)
> else:
> error("no password header found")
> check_items.add("Password", val)
>
> i.e. a straight copy to User-Password with optional removal of a {type}
> header
>
> What you want to do is get the NT hash into the "NT-Password" attribute,
> which you normally do in the ldap.attrmap section. By default this is
> setup to do this:
>
> checkItem LM-Password lmPassword
> checkItem NT-Password ntPassword
>
> ...but from the looks of it your LDAP has the NT hash unadorned in the
> "userPassword" attribute. So, comment out "password_attribute" in the
> LDAP module, and set this in the ldap.attrmap file:
>
> checkItem NT-Password userPassword
>
>
>
>
> > rlm_ldap: looking for check items in directory...
> > rlm_ldap: looking for reply items in directory...
> > rlm_ldap: user jon.giza authorized to use remote access
> > rlm_ldap: ldap_release_conn: Release Id: 0
> > modcall[authorize]: module "ldap" returns ok for request 5
> > modcall: leaving group authorize (returns updated) for request 5
> > rad_check_password: Found Auth-Type EAP
> > auth: type "EAP"
> > Processing the authenticate section of radiusd.conf
> > modcall: entering group authenticate for request 5
> > rlm_eap: Request found, released from the list
> > rlm_eap: EAP/mschapv2
> > rlm_eap: processing type mschapv2
> > Processing the authenticate section of radiusd.conf
> > modcall: entering group MS-CHAP for request 5
> > rlm_mschap: Told to do MS-CHAPv2 for jon.giza with NT-Password
> > rlm_mschap: FAILED: MS-CHAP2-Response is incorrect
> > modcall[authenticate]: module "mschap" returns reject for request 5
> > modcall: leaving group MS-CHAP (returns reject) for request 5
> > rlm_eap: Freeing handler
> > modcall[authenticate]: module "eap" returns reject for request 5
> > modcall: leaving group authenticate (returns reject) for request 5
> > auth: Failed to validate the user.
> > Login incorrect: [jon.giza/<no User-Password attribute>] (from client
> > wifi.myco.com port 0)
> > PEAP: Tunneled authentication was rejected.
> > rlm_eap_peap: FAILURE
> > modcall[authenticate]: module "eap" returns handled for request 5
> > modcall: leaving group authenticate (returns handled) for request 5
> > Sending Access-Challenge of id 152 to 10.100.224.235 port 1645
> > EAP-Message =
> >
> 0x010800261900170301001b1bb3ec40925325e30990ce3b14a78af7abc1f7222d06716740
> d2
> > ff
> > Message-Authenticator = 0x00000000000000000000000000000000
> > State = 0x132496908cd3121e6967d7ddafcdd795
> > Finished request 5
> >
> > -
> > List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
More information about the Freeradius-Users
mailing list