MSCHAPV2 for PP2P VPN

[Alan DeKok]

On Jan 10, 2024, at 9:12 PM, Leo Giusti <leo.j.b.giusti at gmail.com> wrote:
> I am providing the full output from a new test login with a different user
> but am getting the exact same result. I have added a realm definition in
> proxy.conf before doing this test.

  There aren't many choices here.

a) the user doesn't exist in the DB

b) the password the user entered isn't the same as the password in the DB

c) something is mangling the MS-CHAP data so it's incorrect

  What usually goes wrong is that the user name is changed.  Since you have access to both the AD server and debug output, you can check this manually.

> (0) Received Access-Request Id 18 from 192.168.1.1:59973 to
> 192.168.1.124:1812 length 161
> (0)   Service-Type = Framed-User
> (0)   Framed-Protocol = PPP
> (0)   User-Name = "leo.giusti at home.win"

  The user identity is either this, or "leo.giusti".

> (0) mschap: Executing: /usr/bin/ntlm_auth --request-nt-key --allow-mschapv2
> --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}}
> --challenge=%{%{mschap:Challenge}:-00}
> --nt-response=%{%{mschap:NT-Response}:-00}:

  That's the basis for the ntlm_auth common you want to run,

> (0) mschap: EXPAND
> --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}}
> (0) mschap:    --> --username=leo.giusti
> (0) mschap: Creating challenge hash with username: leo.giusti at home.win
> (0) mschap: EXPAND --challenge=%{%{mschap:Challenge}:-00}
> (0) mschap:    --> --challenge=4b2160a676fadd0d
> (0) mschap: EXPAND --nt-response=%{%{mschap:NT-Response}:-00}
> (0) mschap:    -->
> --nt-response=e3c7a7ea97d694435f1feb61dbfba7ebde420e596281a1a1

  This shows the magic MS-CHAP data required to run a particular authentication test for ntlm_auth.  You can put the two together to get:

/usr/bin/ntlm_auth --request-nt-key --allow-mschapv2 -username=leo.giusti --challenge=4b2160a676fadd0d --nt-response=e3c7a7ea97d694435f1feb61dbfba7ebde420e596281a1a1

  Running that from the command line should get you the same result:

> (0) mschap: ERROR: Program returned code (1) and output 'The attempted
> logon is invalid. This is either due to a bad username or authentication
> information. (0xc000006d)'

  Since that fails, the only real option is that the user name is wrong.  The only other option you can try is the full username.  So:

/usr/bin/ntlm_auth --request-nt-key --allow-mschapv2 -username=leo.giusti at home.win --challenge=4b2160a676fadd0d --nt-response=e3c7a7ea97d694435f1feb61dbfba7ebde420e596281a1a1

  If that works, then you know that AD needs the full user name.

  If that doesn't work, then there's nothing more we can do.  Either the user isn't in AD, or the password they entered is not the same as the password in AD.  We don't know which one it is, because we don't have access to AD.  You do.

  You can also test ntlm_auth with the same user name (both versions) and the users correct password.  The point is to try all possible variations to see which one (if any) fails.  If a basic username / password check fails, then the user / password isn't in AD, or is wrong.

  If the username / password checks pass, but the MS-CHAP check fails, then you know something is wrong with the MS-CHAP data.

  But the key take-away here is that FreeRADIUS doesn't create the MS-CHAP data.  It gets it in an Access-Request from the user.  So if FreeRADIUS is getting the wrong data, then FreeRADIUS is being given the wrong data.  And no amount of poking FreeRADIUS will make the user send the correct MS-CHAP data.

  Alan DeKok.