Skip to main content

We implemented Password Safe for our dedicated domain admin accounts in May/2024. At the time, we experienced some frequent lockout issues with these accounts, but nothing that couldn’t be explained or resolved by simple process changes for users (i.e. forgetting to sign out of systems before the password release expires). 

In Sept/2024, we saw an uptick in lockout frequency with these accounts that couldn’t be explained. Most of the lockout events occurred on the Windows machines users were in possession of rather than from accessing a remote VM like we saw in the past, (aside from some of our support staff who encountered lockouts from end user machines they had previously worked with and used their credentials to establish a remote support session via Teamviewer). Lockouts occur multiple times a day regardless of a reboot on the problem device. No processes are found running with dedicated admin account on the machine, yet ongoing lockout events on the account continue to register from the device. 

We finally discovered that in most cases, disabling the “Fast Startup” feature in the power options and restarting the device resolves the lockout issue. Something with Fast Startup is hanging on to these credentials and trying to authenticate, eventually locking the account. I can recreate the issue on my machine by turning the Fast Startup feature back on, rebooting, and running Active Directory Users & Computers with my admin account. After about 2 days and a couple of password rotations, I am stuck in the lockout loop. Exiting ADUC after each use or even rebooting the machine after each use makes no difference. Turning off Fast Startup again and rebooting however resolves the issue instantly. 

Has anyone else encountered something similar? If so, have you been able to narrow down the culprit and find a permanent resolution? 

Hey! As you have gathered - Fast Startup is holding onto the credentials. Fast startup uses a cached credential to logon to the Windows system which the credential is cached when the user first logs on to the local machine. and there is no inherent expiry mechanism for the credential to be wiped from the cache. As long as the user object exists in Active Directory, the cache will be used for logon rather than re-authenticating against Active Directory - and this is why it’s persistent regardless if the user is logged in or processes are running at the time of the reset.

Do you have ESA  Logoff on Disconnect setting enabled?  Refer to https://beyondtrustcorp.service-now.com/csm?id=kb_article_view&sysparm_article=KB0016936

 

 

 

Hey! As you have gathered - Fast Startup is holding onto the credentials. Fast startup uses a cached credential to logon to the Windows system which the credential is cached when the user first logs on to the local machine. and there is no inherent expiry mechanism for the credential to be wiped from the cache. As long as the user object exists in Active Directory, the cache will be used for logon rather than re-authenticating against Active Directory - and this is why it’s persistent regardless if the user is logged in or processes are running at the time of the reset.

Just basing on what Eric wrote, what credentials would be cached if the apps they ran with their dedicated admin account were closed. Windows at that point shouldn’t have any authentications being used against the dedicated admin account anymore, right? so if that's the case then nothing should be getting cached. or is my thinking on this completely off base?

Hey! As you have gathered - Fast Startup is holding onto the credentials. Fast startup uses a cached credential to logon to the Windows system which the credential is cached when the user first logs on to the local machine. and there is no inherent expiry mechanism for the credential to be wiped from the cache. As long as the user object exists in Active Directory, the cache will be used for logon rather than re-authenticating against Active Directory - and this is why it’s persistent regardless if the user is logged in or processes are running at the time of the reset.

Thanks for the reply. Yes just to clarify, no logging into Windows on these workstations using the dedicated admin accounts. Machines are being logged into with separate AD accounts (standard user accounts), and then the most common use case is to run Windows Admin Tools (primarily ADUC) with the admin account. So somehow fast startup in caching the secondary account, even if the application running is ended. The lockouts also persist after signing into the application again using valid credentials. Just to note though, we are not only seeing this occur with ADUC, this is just the most frequently used application. Our Service Desk commonly faces the issue of lockouts on end user devices using TeamViewer for remote support with the admin accounts, which then requires them to reach out to the end user and ask them to disable the fast startup feature on their devices to resolve. 

This is interesting as I have 2 UVM appliances that are doing the same thing. does anyone know if the UVM’s have FAST STARTUP?

We faced the same issue, but only with one domain account. The only solution that worked for us was to access all servers and log out the user account through Task Manager. Unfortunately, the ESA Logoff on Disconnect option only disconnects the RDP session and does not log out the user.

Reply


Badge Earners

  • BCSE: Privileged Remote Access
    Kragballehas earned the badge BCSE: Privileged Remote Access
  • BCA: Password Safe
    kgujashas earned the badge BCA: Password Safe
  • BCIE: Password Safe
    kgujashas earned the badge BCIE: Password Safe
  • BCIE: Password Safe
    Vinoth Rajahas earned the badge BCIE: Password Safe
  • BCA: Remote Support
    Pablo Salashas earned the badge BCA: Remote Support
Show all badges
Terms & ConditionsCookie settings