radtest -t mschap valid-user@domain invalid_password 127.0.0.1 0 radius_secret replied with MS-CHAP-Error = "\000E=691 R=1 C=ad8367a70f809d72 V=2" My reading of the MS-CHAP-V2 RFC2759 and PPP CHAP RFC1994 is that this should have been MS-CHAP-Error = "E=691 R=1 C=ad8367a70f809d72 V=2"
Alan wrote:
RFC 1994 Section 4 states that the packet format contains a one-octet identifier. In this case, the leading "\000". RFC 2433 and 2759 say that the Failure packet is identical in formation to the normal CHAP message format. i.e. with the identifier. Further, FreeRADIUS interoperates with all MS-CHAP implementations, which add the 1-octet identifier, and which look for it.
Thanks. My confusion was that I was reading the PPP CHAP/MSCHAP RFCs, but I needed to read RFC 2548, Microsoft Vendor-specific RADIUS Attributes. PPP and RADIUS store the fields differently for MS-CHAP-Error. PPP MSCHAP packet contains a code, identifier, length, message. RADIUS MSCHAP VSA contains vsa_attribute, length, identifier, message. Radtest is showing everthing after the length, which in this case is identifier+message. Arran wote:
Add NT-Password to the session-state: list. Only call the rest module if session-state:NT-Password isn't set, otherwise copy session-state:NT-Password to the control list.
I did something similar, which is now working. I added outer.session-state:NT-Password, because this was restored, while the session-state:NT-Password was not. Since the real password is in control:NT-Password, we don't need the real password in session-state. The inner-tunnel authorize config is now: if (!ok && !updated && !outer.session-state:NT-Password) { rest if (control:NT-Password) { # Store "NT-Password" in the outer session state, so we know not to call REST API again update outer.session-state { &NT-Password = "Yes" } } } Regards, Russell Lang -----Original Message----- From: Freeradius-Users <freeradius-users-bounces+russell.lang=team.telstra.com@lists.freeradius.org> On Behalf Of Alan DeKok Sent: Thursday, 23 January 2020 11:13 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: rlm_rest learnings - PAP and PEAP/MSCHAPv2 [External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments. On Jan 19, 2020, at 9:29 PM, Lang, Russell <Russell.Lang@team.telstra.com> wrote:
Using My reading of the MS-CHAP-V2 RFC2759 and PPP CHAP RFC1994 is that this should have been MS-CHAP-Error = "E=691 R=1 C=ad8367a70f809d72 V=2"
RFC 1994 Section 4 states that the packet format contains a one-octet identifier. In this case, the leading "\000". RFC 2433 and 2579 say that the Failure packet is identical in formation to the normal CHAP message format. i.e. with the identifier. Further, FreeRADIUS interoperates with all MS-CHAP implementations, which add the 1-octet identifier, and which look for it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html