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

[Phil Mayers]

Meyers, Dan wrote:
>>> Secondly, my colleague's machine actually responds to the
>>> Access-Challenge sent at the end of the packet where the ntlm_auth
> is
>>> done, whereas my machine does not. This is the crucial point I
> think.
>>> Without this final response the Access-Accept is never sent back. My
>>> colleague is using Windows XP with the Intel Pro/Set Wireless
> drivers
>>> and supplicant. If he changes to using the XP inbuilt supplicant,
>>> everything stops working. I am on Windows 7 using the inbuilt
>>> supplicant. As best we can tell, this is the problematic difference.
>> The
>>> Intel supplicant is presumably getting and responding to the
>>> Access-Challenge where the windows inbuilt supplicant is not, but I
>>> don't know why or what could be causing it. My machine also doesn't
>>> respond to the Access-Challenge under Ubuntu 9.10, using the Gnome
>>> inbuilt supplicant.
>> This is most likely a CA cert problem. The comments in the default
>> "eap.conf" give a very specific warning about this (access-challenge
>> which is never replied to) and explain the issue.
> 
> This being the case, why does my machine successfully respond to all the
> other Access-Challenges before the MSCHAPv2 password is dealt with? The
> trace I gave was for an Access-Challenge id 107. Ids 100 (my initial

Ok, good point. It wasn't readily apparent to me what in the "wall of 
text" (as you put it!) was the failing session and what was the 
succeeding one. Sorry for the noise.

As per Ivan's suggestion, it must be Samba mis-calculating the MSCHAP 
response in that case.