On Aug 29, 2019, at 9:36 AM, L.P.H. van Belle via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hai Alan,
Thank you for you quick reply. I was already waiting for this responce of you. As i said.. Winbind auth/samba works.. I can do any test from CLI all work.
ntlm_auth --request-nt-key --domain=NTDOM --username=username --password='somepass' NT_STATUS_OK: The operation completed successfully. (0x0) ntlm_auth --mschap --request-nt-key --domain=NTDOM --username=username --password='somepass' NT_STATUS_OK: The operation completed successfully. (0x0)
So you're not reading my message. I did read yours. I am aware that *password* authentication works. My point was that MS-CHAP authentication is not the same as password authentication. You should *test the thing going wrong*. Testing something else is not helpful.
(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)'
That's pretty clear. Samba is rejecting the request. Maybe Samba is still refusing to allow ntlm_auth.
No it is not, see above.
Yes, it is. This isn't rocket science. When ntlm_auth returns FAIL, it means that ntlm_auth is returning FAIL. No amount of denial will change that fact. Other tests you run on the command line are irrelevant. Something is different between the command-line tests, and when ntlm_auth is run from FreeRADIUS. Find out what that difference is, and fix it. That is your ONLY way to fix the problem.
Keep running ntlm_auth with the MS-CHAP strings, and poking Samba until ntlm_auth succeeds. At that point, FreeRADIUS will work, too.
As shown, it does not.
So did you run the tests with the MS-CHAP strings as I suggested? Likely not, otherwise you would have said so. My prediction is that it won't work. Which is why I suggested doing it.
This is why im mailing to the list, yes, i know you get lots of these "failures" But im also a samba dev and i support the samba list and i know my samba setup works as it should.
Then why is ntlm_auth returning "fail" to FreeRADIUS? Hint: we didn't write ntlm_auth, and we don't know how it works.
If my squid proxy uses ntlm_auth it works fine.
Probably because it's using passwords for authentication, and not mschap.
So why not in freeradius.. We are missing something here really.
You're missing my suggestion to run ntlm_auth with ms-chap strings. This reply of "but I tested it with passwords and it works" is just not helpful. The server prints out those MS-CHAP strings *precisely so that you can test them*.
So please, have a better look, or tell me more where to look.
"Have a better look"? That's rude. Especially when you're ignoring my suggestions. This shouldn't be difficult. FreeRADIUS is simply executing another program, using normal system APIs. If that program fails, then the problem isn't FreeRADIUS. The possible problems are: a) the program is run under a different UID, and therefore can't access the resources it needs when run under a different UID b) the parameters passed to the program are different in the situations when it works, and when it doesn't work There really isn't a lot else. There is no magical cross-process memory corruption where ntlm_auth works fine from the command-line, but *exactly the same* command fails when run under FreeRADIUS Test it from the command line *using exactly the same parameters as used by FreeRADIUS*. If it works, then the issue is likely UID related. If it doesn't work, then you should apologize for asking me to "take a better look" instead of following instructions. And then fix something *unrelated to FreeRADIUS* to get ntlm_auth with MS-CHAP to work. FreeRADIUS is using *exactly* the same code to run ntlm_auth on millions of other systems. We can believe that FreeRADIUS is magically broken on your system when running an external program. OR we can believe that there is a local permissions / configuration issue which is preventing ntlm_auth from working. Alan DeKok.