On Nov 15, 2018, at 9:01 AM, Christian Salway via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I dont understand what is failing here...
when i run `radtest -t mschap christian.salway pa$$word 10.0.0.247 0 testing123`
the response is
It's typically good to look at *ALL* of the debug output. You can't just look at a tiny piece of the output and expect to understand the whole thing.
(3) authenticate { (3) mschap: Client is using MS-CHAPv1 with NT-Password ... (3) mschap: ERROR: MS-CHAP2-Response is required to calculate MS-CHAPv1 challenge
That seems to be clear enough. The server isn't receiving an MS-CHAP2-Response attribute.
and if i try it with MS-CHAPv2
(7) authenticate { (7) mschap: Creating challenge hash with username: christian.salway (7) mschap: Client is using MS-CHAPv2 (7) mschap: Executing: /usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}: (7) mschap: EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (7) mschap: --> --username=christian.salway (7) mschap: Creating challenge hash with username: christian.salway (7) mschap: EXPAND --challenge=%{%{mschap:Challenge}:-00} (7) mschap: --> --challenge=87096cbcc288f585 (7) mschap: EXPAND --nt-response=%{%{mschap:NT-Response}:-00} (7) mschap: --> --nt-response=69ebf16ddad737fbaa5315235a9316fe9ccb5fcbc06c07e2 (7) mschap: ERROR: Program returned code (1) and output 'Logon failure (0xc000006d)'
AD its rejecting the user. This unfortunately is out of the control of FreeRADIUS.
whats going on?!
AD is rejecting the user. Ask AD what the users password is. And, why it's rejecting the user. The MS-CHAP calculations have been known, and known to work, for about 20 years. If AD is rejecting this with "Logon failure", then: a) the users password in AD is not what the user entered on their system b) the users account is locked out, or doesn't exist, or has another administrative setting that says "reject them" There really are no other options here. Try *simplifying* the problem. Instead of going to AD, configure a local password for the user. One that you can't get wrong. Then, try it with AWS. If that fails, then my guess is that AWS is broken. And post the *full* debug output here. ALL of it. Alan DeKok.