it's deliberate, it's a very odd environment.
think about it - you turned your machine on, authenticated, then Windows booted to a previous point in time (the resume). This is not the same as a normal boot, which progresses nicely in time order.
the resumed position is the state the machine was in when the memory dump was written, which is in fact the same mode as a locked machine (screen saver), NOT an initial login - you hibernated from the point of already being logged in, not from the point of about-to-log-in.
So, in the same way we don't SSO through screen savers (what would be the point), we don't SSO on a resume.
You can turn off login on resume if you like through the normal windows panel?
That might be something worth looking at, thanks for the tip happy
that strangley is harder than it sounds, as hibernate starts with a suspend request (to power down everything possible etc). It's pretty hard to tell at the low level between the two (so my people tell me anyway).
what you're asking for is, in the case of resume from suspend, throw up a login box, but in the case of resume from hibernate, do SSO.
the interesting question is, what if a different user logged in preboot than the user who hibernated?
it would be nice for sso to with hibernation. don't see why it would be hard to tell the difference either, pre boot shouldn't kick in on a resume from standby?
if a different user did log into preboot in the hibernate scenario the sso would simple fail as the os is locked to a different account or in the case of the sso user having admin privelidges they would be asked if they really wanted to log off the logged on user?