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@deployingradius.com> wrote:
On Jan 30, 2024, at 10:11 PM, Dean Guenther <deanrguenther@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@testdomain", but then instead of sending that to FreeRADIUS, sends a username of "deang". But still sends the MS-CHAP data calculated with "deang@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@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