[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: rlm_cache NT-Password with EAP-PEAP
From:       Arran Cudbard-Bell <a.cudbardb () freeradius ! org>
Date:       2015-02-27 22:57:59
Message-ID: D67428DC-D707-4D20-BB57-A1C2154BA7C0 () freeradius ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> On 27 Feb 2015, at 17:48, Alan DeKok <aland@deployingradius.com> wrote:
> 
> On Feb 27, 2015, at 4:20 PM, Sherker, Donald <Donald.Sherker@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@freeradius.org>
FreeRADIUS development team

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


["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.26
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJU8PZ3AAoJEP+k1YKfttfKg1wP/2AVV7jq77/R0+RPNYgnN/9/
Haia48QhXsHbg5qwF7R5kBQr/ckGrxr/bL21L4VTViz2DY7DBzhNaBON0l9yTn0v
KXJKNQ/8CqqKIhI49tpJsdWn71xbFe+Ig+pYZCGtOoU/Y/d81kqI0nsgyenFh0t4
gYrlhQRRF9MpJ3PvY/ionyAO2qP/kCbCQqJnV1Vsxswjz6gzaJ/ym1CLMRxPM6S2
A61Ehh8Dye6fA0I8fVBIY924HmkpScTVkbcUDo7gepZWnG2KjvX2K6n60VzbIwZ9
h0VY0xb9xf1oMysWeGYbYaf9UaEkEr6UpxS/v+EWr1NTQOZxmV9AXHaAqOJnu15D
ZvXpTgF1OdXi7JcTtNvyeYaxTdQ4RuHKVX/8S1oB3uXX5o6dGQSJetua3j3IgMOy
ZekmKLgEYmy7G05PQNszRpy/M74ebHWUXNxpku/WDmf4hPDQjRtPozJXLN2QKB/c
v73EiA2eDdpUooN7qX/17VQMdpIS5LxdH9EAzz8bzPCdT429hHcrd2EI84bMG4Wz
3ltxvnVpIdAylqBJJeMVoo3vgeWOWVu2e7ZHdFy295e8XRBSgIxSmCwjWj6kvphi
PYrlvl4lu8ZLPSlwO2JZlMoSoY+vONZTbzsMzcywmmJcQ8EHbws0xLgpfbEoX5wO
OWrgvBgMJkIGfaRoAxBM
=keXW
-----END PGP SIGNATURE-----

[Attachment #6 (text/plain)]

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[prev in list] [next in list] [prev in thread] [next in thread]