On 05/19/2011 08:04 PM, John Douglass wrote:
Now, the actual ntlm_auth command within the $RADIUS/modules/mschap does read:
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}"
So it's not doing necessarily the same kind of authentication command as I was doing above but I have no idea how to simulate a challege request on command line to verify :)
You can just run FreeRADIUS in debug mode and capture any ntlm_auth command line - they're re-usable, the "response" value is the same every time for a given challenge, username and password. Security revolves around the challenge being random and not re-used. (I have some utilities for generating the response that I keep meaning to stick in an AppEngine page at some point)
Login incorrect (mschap: External script says Logon failure (0xc000006d)): [asdf/<via Auth-Type = EAP>] (from client LAWN-WiSM port 29 cli 00-25-00-f5-a3-2b via TLS tunnel)
However, "Logon failure" is nebulous when it could be either "bad password", "account disabled", or "no such user" that comes out of the "ntlm_auth" command (at least when I run it by hand).
Is this the fault of the results of ntlm_auth being vague or is something else at play?
The former. As you noted above, you were testing with username/password auth as opposed to challenge/response auth. The latter gives a much smaller, less interesting (but arguably more secure) set of error codes. About all you get other than "Login failure" is "Password expired" (which the recent MS-CHAP password change patch I wrote looks for and acts on) This is for boring reasons to do with the way Samba makes the RPC call against the domain, and gradual changes in Windows about what error codes it leaks (if you think about it, leaking the difference between "invalid user" and "invalid password" makes user/pass dictionary attacks easier)