FreeRADIUS not receiving password from WLC

[A.L.M.Buxey at lboro.ac.uk]

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