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

[Alan DeKok]

Meyers, Dan wrote:
> 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?

  MS-CHAPv2 includes client validation of the server.  If the client
doesn't like the servers response... it stops talking to the server.

  AFTER the whole SSL session has been set up.

  And with NO information to the end user about what went wrong, or why.

>>   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.

  Well... everyone does.  I expect it, and there's a certain logic in
blaming the *one* piece of the network that you can control, and is
giving you useful information.

> 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. 

  Given the number of pieces involved... it's hard to tell what's going
wrong.

  Given *my* background: I tend to blame everything *other* than
FreeRADIUS.  If there's a bug, it gets fixed pretty quickly.  That's
more than you can say for Microsoft.

  Alan DeKok.