gMSA account support for PAM provider
0 vote
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.
All Comments (2)
Hi,
ah, we had thought more in line with performing password rotation on the provider account ourselves (in a future release, we has planned on having a system vault for that type of stuff....)
Since GMSA's are so tightly bound to Service, IIS, or scheduled tasks, I do not see an easy way to use them at the provider level. We will need to look at this further.
Best regards,
Maurice
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