rlm_cache NT-Password with EAP-PEAP

[Arran Cudbard-Bell]

> On 27 Feb 2015, at 17:48, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Feb 27, 2015, at 4:20 PM, Sherker, Donald <Donald.Sherker at mybrighthouse.com> wrote:
>> I have made this change and the server is able to cache the hashes for both EAP-PEAP and EAP-TTLS now.  I am now seeing a problem where after MSCHAPv2 finishes it's status is "updated" the first time the user tries to authenticate and then EAP fails.
> 
>  A careful reading of the debug log is helpful here:
> 
> (7) eap_mschapv2:   Auth-Type MS-CHAP {
> (7) mschap: Found Cleartext-Password, hashing to create NT-Password
> (7) mschap: Found Cleartext-Password, hashing to create LM-Password
> (7) mschap: Creating challenge hash with username: qaresdon
> (7) mschap: Client is using MS-CHAPv2
> (7) mschap: Adding MS-CHAPv2 MPPE keys
> (7)     [mschap] = ok
> (7) cache: EXPAND %{User-Name}%{outer.request:Calling-Station-Id}
> (7) cache:    --> qaresdone899c47233d8
> (7) cache: No cache entry found for "qaresdone899c47233d8"
> (7) cache: Creating new cache entry
> (7) cache: EXPAND %{control:NT-Password}
> (7) cache:    --> 0x5835048ce94ad0564e29a924a03510ef
> (7) cache:   control:NT-Password := 0x5835048ce94ad0564e29a924a03510ef
> (7) cache: EXPAND %{control:LM-Password}
> (7) cache:    --> 0xe52cac67419a9a2238f10713b629b565
> (7) cache:   control:LM-Password := 0xe52cac67419a9a2238f10713b629b565
> (7) cache: Merging cache entry into request
> (7) cache:   &control:NT-Password := 0x5835048ce94ad0564e29a924a03510ef
> (7) cache:   &control:LM-Password := 0xe52cac67419a9a2238f10713b629b565
> (7) cache: Commited entry, TTL 86400 seconds
> (7)     [cache.authorize] = updated
> (7)   } # Auth-Type MS-CHAP = updated
> (7) eap: Freeing handler
> (7)       [eap] = reject
> (7)     } # authenticate = reject
> 
>  i.e. the *cache* module returns “updated”.  That can be fixed.  Just add “ok” after “cache.authorize”:

Sure, that's a workaround, but this is a bug in the server. A module returning updated in the authentication
section should not cause authentication to fail.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150227/8faf4872/attachment.sig>