my colleagues and I are facing a concrete problem with a user on a business trip. I try to describe it as generic as possible to comply with superuser's policies. Unfortunately I couldn't find my scenario documented in any form on the after googling 1 hour in both English and German.

Scenario is as follows:

  • A user (person) is on a business trip (outside of the company) and locked his AD user account on his notebook by entering wrong credentials three times in a row. The user only uses the AD account on his notebook. He doesn't have another local account.
  • The user (person) knows the correct, current password, that was set with said notebook when he was on site. The password can successfully be used for other services.
  • Our AD controllers are available locally via LAN only
  • The user (person) hasn't got any means of VPN to connect "home" into the office.
  • The user now cannot log into his notebook at all.

Technical information:

  • AD is Win 2008 R2 based
  • Notebook is Win7 Enterprise
  • User profiles are stored locally, yet they are still AD profiles, not local users.

The possible solutions we thought about all lead to road blocks of some sort:

  • Giving out the local admin password: Would allow him to access the PC but not his account with Mail etc., he also wouldn't be able to unlock his profile via the admin logon, since AD accounts aren't managable via lusrmgr.msc.
  • Setting up a VPN for him is not possible, because this requires a physical Token he doesn't have
  • we could give out the admin password and instruct him to set up a remote solution, like TeamViewer, but what would we do on the machine?

For the future we will change our PW policies (which are decades old) to a more up to date best-practice approach (raising the wrong input treshold to 50 minutes, etc.) to avoid situations like this but the above scenario is still real and I would like to solve it somehow.

Thank you for your input in advance, really appreciated.

  • If his Notebook is not connected, he can't log in with the last working password? If his user is also a local user, he can log in as admin an unlock his local user account.
    – edumgui
    Apr 27, 2016 at 8:41
  • Thanks for your comment. Correct, the user mistyped his password three times. He cannot logon with the password he completely remembers and succesfully uses for other services. Unfortunately he doesnt have an additional local user account on his device. I updated my question to incoporate your feedback.
    – modmatt
    Apr 27, 2016 at 9:28
  • I'm sorry but there is something I can't not understand... How could he lock out the account if there was no connection to your AD??
    – edumgui
    Apr 27, 2016 at 9:49
  • what @Santeador said just now is what im thinking. I have never tried to reset a password with the net user method through admin cmd would it be possible since he is not connected to the .AD anyways? I May setup a VM when I get home and play with this. Apr 27, 2016 at 9:50
  • The exact message from Windows to the user is "the account is locked out"?
    – edumgui
    Apr 27, 2016 at 9:57

2 Answers 2


in my company, we faced the same scenario and what we did is our system team unlocked the account from AD https://blogs.technet.microsoft.com/askds/2013/10/01/locked-or-not-demystifying-the-ui-behavior-for-account-lockouts/

and the user loged in using local admin and accessed OWA for the emails

  • Thank you for your response. This is what we resorted to as well. The user accesses the notebook via local admin now and can access the data on the hard drive. One thing I like about your answer is the link provied. Although I know how to unlock users and how to read the UI, I never came accross the Active Directory Management Center. Just tried it and I love it. Thanks!
    – modmatt
    Apr 28, 2016 at 6:14

I felt the post necromancy here was worth it to share the recent experience and knowledge I have obtained. The Q from @modmatt, the comments and A from @Kareem were useful insights in my search for solutions to a very similar problem. Of all my trawling of the web looking for answers, this post is one of the closest that fits the problem I had. Maybe the share helps others in the future.

What was the scenario that caused the problem to occur?

The user, in this case was actually me, had reached the AD enforced 90 day password age limit. The corp uses local AD servers and some kind of bi-directional sync to O365 too. Under normal conditions, changing the password on the corp.local AD OR O365 triggered an update of the other.

So the user had changed their password, in this instance on the corp.local domain via the corps bespoke IDM tool for user and role mgmt. This should of triggered workflows to update the credentials globally.

There are two key differences in my scenario compared to @modmatt original question:

  1. The user was a remote user with VPN access (only available post login).
  2. The user was locked on the AD corp.local but the local cached credentials (with the previous password) were unlocked, when the device was not connected to the VPN the user could login/unlock their "local cached" account.

The "account lock" loop that kept happening for the user was as follows:

  1. boot device.
  2. login with local/cached credentials.
  3. connect to the VPN (Cisco AnyConnect).
  4. expectation: cached credentials to be updated with latest password via AD.
  5. actual: the account was locked. The unlock screen message was "The referenced account is currently locked out and may not be logged on to."
  6. At this point the only way to gain access to the user again was to reboot and start at step 1, but the loop kept happening.

Helpdesk had been working with the user on live chat, monitoring the AD status of the user and kept performing unlocks of the account. It appeared that as soon as the VPN connection was established the user was being locked out by policy, leading to the conclusion that something cached on the account was causing the lock out before the AD could sync the latest credentials.

The solution

Helpdesk had informed the user to ensure the account unlock process had been triggered by using office.com password reset process. This process was followed and the user had a working O365 account and fresh credentials. The established bi-directional sync processes should of then been syncing this with the corp.local AD.

The user had previously requested via automated process a time limited grant of "Local Admin" which appeared to of not yet expired. i.e. the user still had local admin rights.

  1. The user created a "LocalAdmin" account and assigned local admin rights to the account. (the rights assignment was not actually needed for the solution). This could of been a standard account.
  2. The user confirmed the account worked and then rebooted the device.
  3. Helpdesk confirmed the AD account had been unlocked.
  4. The user logged in with the new LocalAdmin account.
  5. The user connected to the VPN (Cisco AnyConnect).
  6. The user located cmd prompt within an explorer window, then SHIFT+right clicking and "run as a different user"
  7. corp\<username> + the fresh password from the office.com password reset process.
  8. the cmd window was launched as the domain user and triggered the relevant local cached to be refreshed.
  9. Helpdesk confirmed the AD account remained unlocked.

The user was then able to sign out of the local account (side effect: VPN disconnected) and use their normal domain account to sign in. Thereafter the user connected to the VPN and was able to run net user <username> /domain and see their account was active and then perform a gpupdate and continue on with their business as usual.

other solutions that were non-viable at the time

  • take the device to an office location that was on corp.local domain, and let the domain admins fix the situation. This wasn't immediately viable as there was a ~1000 km commute required. A round trip of DE to DK.


  • provide the user with the local user CorpAdmin credentials to run the steps above. At the time providing those credentials wasn't an approved process for helpdesk. I assume it was a shared password.

hindsight: in writing this up, I realised the user (me) may of changed their credentials off the VPN via a Citrix VDI session (using its own SSL VPN) and this may of caused a race condition when the user later connected to the VPN with older cached credentials on the end user device, causing immediate AD lock out and loop mentioned above?

conclusion: always ensure the end user device is on the VPN when changing password so that AD and local cached credentials cannot get out of sync and cause the loop documented above.

Its probably also always worth having a local standard account as a backup that can act as a rescue account in such a situation. It doesn't seem like a very big InfoSec risk / attack vector?

footnotes: As of 2022-Feb The advice from helpdesk in this particular org was use the O365 password change flow and not the CTRL+ALT+DEL "change a password" flow and also not the corp.local IDM flow. This was counter-intuitive but I make the note for the record. What seems to be missing from this advice is to ensure that end user devices are connected to the VPN when performing password changes. This may seem obvious but the fact its possible to perform the flow via office.com or Citrix VDI with the end user device disconnected from the VPN can (in some cases?) lead to the issues documented above.

other links that were insightful were here, and the accepted solution here.

You must log in to answer this question.

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