jrothstein

Had the same issue so glad I found this. For me the locked file was "azure.core.dll" or "derconverter.dll". Handle.exe showed the scheduler service account had the file locked despite being stopped. Mathieu's solution worked for me.

I would certainly be happy with a mechanism to auto-rotate the provider account, but I don't believe gMSA's are restricted to running app pools, tasks, and services. For instance, Netwrix Auditor, which we use to audit all AD and local machine change activity, supports the use of gMSA accounts. Windows Defender for Identity can use gMSA accounts, specifically for the purpose of disabling domain accounts and resetting passwords when it detects certain malicious activity-- which is pretty much what you're doing. I'm no developer so have no clue what's involved, but if it's any help, here's the Identity config for using gMSA as an action account to reset passwords.

Manage action accounts | Microsoft Docs

Adding support for the use of gMSA accounts for the Windows domain PAM provider would be hugely beneficial from both a security and maintenance standpoint. Currently the provider requires a normal service account using username/pass with delegated rights to perform password reset operations, and domain admin rights if performing this operation on domain admin accounts. In essence, these accounts themselves are "privileged", but represent a "blind spot" because they are actively being used to reset other accounts, and require manual password rotation (and subsequent updating of the PAM credentials).

If support for gMSA accounts was added, there would be no need for ongoing manual maintenance of this account since there effectively is no password, and the possibility of this account being compromised is infinitely smaller than a standard service account.