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.