Logins against AD failing in *most* cases. Can see why, but don't*understand* why.

[Meyers, Dan]

> > It was also my (possibly
> > erroneous) understanding that FreeRADIUS would never get to the
point
> of
> > being able to get the MSCHAPv2 password from the client if the CA
> cert
> > was incorrect, as it would never complete the setup of the EAP
> session
> > inside which the MSCHAPv2 data is contained.
> 
>   Yes.  That's what you're seeing.  The *client* is deciding it
doesn't
> like the certificate, and is stopping.

But even in the failed example I am getting far enough for the server to
receive a username and MSCHAPv2 password from the client, and auth them
using ntlm_auth. Surely by the time the server gets an MSCHAPv2 password
from the client the EAP session should have been set up, server certs
validated etc etc on the client side, otherwise what's the point of the
validation as you've already handed details to a potentially untrusted
server. Or am I misunderstanding something major here?

>   And FreeRADIUS always gets the blame.  It explains why I come across
> as cranky much of the time.

Apologies, I didn't actually mean to blame FreeRADIUS. I was reasonably
certain that my issue was with either Samba or the AD (though it now
seems the wireless controllers are a possibility as well) or a
misconfiguration on my part within FreeRADIUS specifically when dealing
with Windows Server 2008 R2. Or that it would simply be a known case of
"This doesn't work yet for reasons X, Y and Z. Use this workaround"
where the workaround was using some clever data fettling or similar via
rlm_perl and FreeRADIUS. Initially I thought the latter to be most
likely, hence my posting on this list rather than, say, the Samba one.