problem with radtest and freeradius 3.0.26

[Dean Guenther]

Hi Alan, I appreciate all your help. Its working now.

I turned on debugging on the Samba server and was able to see that the
problem was that Samba was being sent an NTLMv1 request from freeradius,
which by default is not accepted in Samba now. I went back to the
freeradius server and used wbinfo to send the request and sure enough it
worked because wbinfo was sending an NTLMv2 request. Then I saw somewhere
that somebody mentioned to put the following global option in the Samba
smb.conf file on the client, the freeradius server:

             ntlm auth = mschapv2-and-ntlmv2-only

And sure enough, its working. I assume the freeradius server is now sending
NTLMv2 requests and everything is happy.

Again, I really appreciate your help in working through this. - Dean
Guenther

On Wed, Jan 31, 2024 at 4:15 AM Alan DeKok <aland at deployingradius.com>
wrote:

> 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.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>