Joseph Silverman wrote:
in order to allow plain-text passwords to correctly work from a wifi client
The debug log you posted shows the clients doing PEAP. There are NO plaintext passwords in PEAP. The server MUST have access to either the plaintext password, or the NT hash form, for PEAP to work.
Till the upgrade, I had to include the already encrypted password (with leading {crypt} or {ssha}) as the password on the client. Meaning, for one, that whenever a user changed their password through some means or another, they have to get ahold of the "encrypted" version of their password from the LDAP database and use that for their wireless connections. Unpleasant.
And the only way to get PEAP to work. See: http://deployingradius.com/documents/protocols/compatibility.html
I read about auto_header and it implied that by upgrading, I could get the whole thing to use unecrypted passwords (which would be generally simpler for our users) instead. This failed to work. Something mis-configured, or possibly not doable?!
It's impossible. See the above web page.
Sending Access-Challenge of id 39 to 192.168.43.106 port 1645 EAP-Message = 0x010600061900 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x7c82b915bfc84d169d053dc47c2c3aa6 Finished request 4 Going to the next request Waking up in 5 seconds...
And this is in the FAQ: PEAP doesn't work. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog