problem with radtest and freeradius 3.0.26

[Alan DeKok]

On Jan 30, 2024, at 10:11 PM, Dean Guenther <deanrguenther at gmail.com> wrote:
> I've followed your suggestion on debugging. I still am unable to get a
> successful authentication. I can see "what" is failing, (the
> autentication). But I don't see the "why".

  The "why" is buried somewhere in a log file in Active Directory.  Pretty much the only thing it's returning to FreeRADIUS is "failed".

> 4) I also ran
>          ntlm_auth --username=deang --password=******* --domain=TESTDOMAIN
>    and that works. I also did
>          ntlm_auth --username=deang --password=*******
>    without the --domain and that also works.
>    NOTE: per your explanation I now understand that this execution does
> not actually call mschap

  Yes.

  You can *also* run radtest, and tell it to send MS-CHAP data to the server.  i.e. you give radtest a clear-text password, and it does the MS-CHAP calculations for you.

  That should work.  If it doesn't, then something weird is going on.

  If it does work, then you know that the other device creating the MS-CHAP data is doing it wrong.  And so the only way to fix it is to fix the other device.

> 5) My endgame is I want to authenticate a wireless access point through
> this freeradius server. But when I couldn't get that to initially work is
> when I
>    decided to try radtest. So now my most recent test is going through the
> access point which uses WPA2 Enterprise.
> 6) It asks for the name and password.
> 7) In the freeradius log (attached) it shows that it successfully passes
> the username "deang" to mschap.
> 8) But then it says it
>          (7) 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)'

  Because Active Directory doesn't like "something" about the MS-CHAP data.

  What doesn't it like?  No idea.  That information is buried in the Active Directory logs.

> 9) In your new mschap documentation it mentioned trying ntlm_auth from the
> command line using the mschap:Challenge and mschap:NT-Response.
>     I couldn't get that to work. Not sure what I entered wrong here:
>            # ntlm_auth --request-nt-key --allow-mschapv2 --username=deang
> --challenge=878e648b0127ef34
> 
> --nt-response=cea5231c4fe1a9d111433e9473010416e8ca426578904d35
> --domain=TESTDOMAIN
>             The attempted logon is invalid. This is either due to a bad
> username or authentication information. (0xc000006d)

  The challenge is a random field.  The nt-response is calculated from a hash of the username and challenge.  So the point is to test small variations of the username to see what works.

  i.e. the other device may be doing the MS-CHAP calculations with username "deang at testdomain", but then instead of sending that to FreeRADIUS, sends a username of "deang".  But still sends the MS-CHAP data calculated with "deang at testdomain".

  So it will *never* work.

  The purpose of running ntlm_auth from the command line is to see if the device sent you one format for the username, but secretly calculated the MS-CHAP data with a different username,  So try different variations of the username, and maybe one will work.

> 10) in the mschap documentation it says another option is to comment out
> ntlm_auth and uncomment "winbind_username" and
>      "winbind_domain" in mschap. I tried this but it still failed. I did
> not include a log of that attempt.

  That won't work if the MS-CHAP data sent by the device is wrong.

> One more question, so I can learn more about this process. The password is
> never shown in the mschap debug log. Is the password when entered on the
> wireless access point somehow hashed into a combination of the challenge
> and nt-response? Just trying to understand how they fit together.

  Yes.

  My $0.02 is to try radtest:

$ radtest -t mschap deang my-password localhost

  And then also different variations of the username...

$ radtest -t mschap deang at testdomain.com my-password localhost

  My guess is that one of them will work.  If not, then something in your local changes are mangling the username and/or the MS-CHAP data.

  Most people get this working pretty quickly.  So either the device is broken, or your local RADIUS configuration is broken.  There isn't much else which can go wrong.

  If this is still a mystery after a few more tests, then it's time to start over.  Wipe the entire configuration, and start with the default configuration.

  Then, follow my Active Directory guide:  http://deployingradius.com/documents/configuration/active_directory.html

  It has a step-by-step approach.  It works.

  Alan DeKok.