You may have noticed that SSO mechanism have some shortcomings. One of them is that it will work even when user account is disabled.
As far as I know this happens because SSO occurs before Windows brings up network connection with DC.
In effect user is logged as it would be off-line, but if fact he is connected to network and cannot use AD resources because of wrong credentials. This is confusing for ordinary user, because Windows behaves strange displaying different errors, sometimes not related to wrong credentials from first point of view.
Moreover the same situations happens when user password is resetted in AD.
In my opinion SSO should be improved (like many other things).
The only way to solve this one is to delay login until we can determine whether the network is there or not.
Wait - I think there's a GPO setting for that ;-)
Seriously though, If windows accepts the credentials, then who are we to argue about it? The only thing we can do is wait around for a bit and delay the users login - SSO does not do anything that someone who types fast can't do themselves after all.
Microsoft introduced this in XP etc to speed up the user experience, so the desktop appears long before all the drivers have finished loading etc - that's why the performance is so poor initially - Windows is effectively still booting up.
As I say, I believe there's a GPO setting to slow Windows down (don't ask me what it is - I can't remember), but it does make things slower for users.
Right, in 6.0.1 solution was to disable "Fast logon" functionality, but now in 6.0.2 it is solved (if believing release notes) by McAfee, so it was possible to solve this issue...