I observed a rather curious behavior of Windows 7 at some of our office PCs:

  1. User A logs into his account as usual.
  2. User A locks the PC (via Win+L or similar).
  3. User B (doesn't matter who, it just has to be someone with a different user account) then logs into the same PC with his credentials (either directly at the PC or remote).
  4. User B logs off again.
  5. Directly after being presented with the "logging off" screen, User A's session is unlocked, without requiring User A's password.

This exact pattern works as presented on all affected PCs with arbitrary combinations of user accounts. I've heard our admin mention that it even works to unlock admin accounts, should they ever happen to stay logged into the right PC. It doesn't, however, work on a batch of newer PCs we recently got for our team.

Is this "phenomenon" known? I wasn't able to find reports of similar behavior via google so I assume it has to be something specific to our office environment. What flaw in the configuration of Windows 7 could lead to such behavior?

Some background:

  • Our PCs run Windows 7 Professional, 64bit. SP1 is installed. Security updates seem to be applied regularly.
  • All user's accounts are domain accounts.
  • I informed one of our admins about this peculiarity some months ago but since the behavior persists, I'll try to present the issue in a more pressing manner (and make sure to include the one responsible for IT security as well this time).
  • I'm aware this has some implications regarding information security. (This allows impersonation, access to restricted network drives etc...) But at least on my PC, it seriously messes with my window arrangements, so it's not likely someone exploits it without me noticing afterwards. I'm sure the only reason it hasn't already been dealt with is because there hasn't been any (known) case of abuse. Also it requires physical access to the respective PC to be exploitable.
  • I'm just a user without elevated privileges. I'll try to supply whatever information will be needed (if any) but will be likely to hit some restriction sooner or later.
  • Also I'd like to apologize if my terminology regarding system administration is off - I'm no professional. Please let me know if I can improve my wording anywhere.

Autoruns' Logon tab (Microsoft entries are hidden): Autoruns' Logon tab (Microsoft entries are hidden) The blacked-out section is a script that maps network drives depending on who logs in. Autoruns' Winlogon tab (there are only Windows entries): Autoruns' Winlogon tab (there are only Windows entries)

  • I really suspect it's caused by a local modification that your new batch of PCs hasn't suffered yet. (I don't remember any news articles bashing Microsoft for this particular issue...) Mar 13, 2018 at 11:32
  • 1
    This is most definitely caused by a third party program. Does this happen with local user accounts? In Safe Mode? Use Autoruns to disable all non Microsoft startup apps and test for the behavior (be careful with drivers & services, though it's most likely that's what could be causing it). Mar 13, 2018 at 12:08
  • Also, 1) in Autoruns, what's on the Winlogon tab? Please post a screen shot of that tab if possible. 2) After the issue occurs, what's the data of the LastLoggedOnProvider value in the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData\#? (Where # is the session number of which there may be more than one.) Mar 13, 2018 at 13:45
  • @TwistyImpersonator Autoruns seems like I'll want to use that on my private PC as well - pretty nifty! 1) There is a bunch of entries on the logon tab, none of them looking suspicious to me. Will add a screenshot to my question. 2) All keys show the same value for LastLoggedOnProvider, however only the first key shows my username in LoggedOnUsername whereas all others have my colleague's name in them (the one who I was conducting the tests with).
    – Inarion
    Mar 13, 2018 at 15:09
  • @TwistyImpersonator Regarding local accounts: I still need to test that. I can't disable anything beyond the entries in HKCU as I'm lacking the privileges to do that. Will have to get our IT guys to do that.
    – Inarion
    Mar 13, 2018 at 15:11

2 Answers 2


This is has designed.

Refer to Interactive logon: Require Domain Controller authentication to unlock workstation

It is a security setting that essentially if not enabled allows the user to login w/o validating to a domain controller.

In your case User A validated and was cached. User B was validated and when User A came back, it used the cached. If that setting is set, it should require re-authentication back to the domain controller so there's the draw back. If you have a say a laptop and lost your network connection, how do you connect back to the domain controller to unlock. Hence it can be a 'dangerous' setting.

  • Thank you, the link was helpful for my general understanding. However, neither your link nor related Google results indicate that cached credentials would be used to automatically authenticate a user (no need for entering a password). As far as I understand, even locally cached credentials serve only as comparison for what the user enters on logging in. So theoretically there should not exist a scenario where User B can log in as User A, whether or not User A has had his credentials cached. Yet it still happens.
    – Inarion
    Mar 16, 2018 at 7:19
  • Interesting enough your comment sparked a wonder on what is different in the various logon methodologies used by Windows, for Windows 10 it was replaced with Microsoft Windows Credential Provider Integration, doing a deeper dive you'll find CREDENTIAL_PROVIDER_USAGE_SCENARIO enumeration See the remarks section Mar 16, 2018 at 16:51
  • Remarks: Starting in Windows 10, the CPUS_LOGON and CPUS_UNLOCK_WORKSTATION user scenarios have been combined. This enables the system to support multiple users logging into a machine without creating and switching sessions unnecessarily. Any user on the machine can log into it once it has been locked without needing to back out of a current session and create a new one. Because of this, CPUS_LOGON can be used both for logging onto a system or when a workstation is unlocked. Mar 16, 2018 at 16:55
  • This is wrong. The OP is experiencing a case where a previously logged on but locked account becomes unlocked without the user providing their credentials. The GPO setting you reference controls Windows behavior when credentials are provided...but those credentials must still be provided for the logon session to be unlocked. Mar 18, 2018 at 15:25

So it seems our IT guys found the problem. All of our PCs, whether Dell or HP brand, have the HP Remote Graphics Sender installed (Version 6.0.3 in the case of my PC). Disabling the corresponding service immediately stops the offending behavior.

As for why this specific service enabled that kind of unheard-of behavior in Windows: We don't know. We are completely clueless.
We most likely won't allocate any more resources towards this issue, as we don't need the Sender service (only using the Receiver). So I can only speculate that the issue might be caused by some sort of incompatibility between the HP software and our PCs of the Dell brand. (Most of the affected PCs were from Dell, although a couple of - older? - HP computers were misbehaving as well, so that can't be the full story.)

All things considered the whole affair remains unsatisfyingly mysterious, but unfortunately I'm not in a position to further investigate this matter - both from a funding as well as a privileges point of view.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .