Hi,
Third, you are further limited by the intersection of the EAP methods your client base supports and your password store can authenticate.
See here for more information:
http://deployingradius.com/documents/protocols/compatibility.html http://deployingradius.com/documents/protocols/oracles.html
Looking at your debugging, the problem is that you've put the "ntlm_auth" module into authorize like this:
authorize { ... ntlm_auth ... }
That's not what you want. The (unfortunately named) "ntlm_auth" module checks username/password. As above, wireless clients don't send this - they speak one or more EAP methods. In any event, you don't want to put that module there; it would live in "authenticate" and you'd use an "Auth-Type" directive to direct to it, as described here:
http://deployingradius.com/documents/configuration/active_directory.html
Remove the "ntlm_auth" module from your config. What you actually want is to take the default config and:
1. Edit "modules/mschap". Uncomment and put appropriate values for the "ntlm_auth" option of *that* module 2. Start the server and test
+1 to this answer. this is THE answer to this. you are forcing the RADIUS conversation straight into an ntlm_auth with username/password - the TLS tunnel hasnt even been established yet. your radtest works because its PAP. the username/password gets sent in a single packet. if you want to do testing via command lineyou need to use eg eapol_test (part of wpa_supplicant package) or radeaptest (or various other tools out there). in fact, a DEFAULT install with minimal changes (just edit the ntlm_auth to be correct in the mschap module, then ensure server is using correct certs and has the WCS configured as a client with correct shared secret) will work after you've bound it to the AD alan