Secure Active Directory queries using gMSAs instead of password-secured service accounts

[baburajan]

Secure Active Directory queries using gMSAs instead of password-secured service accounts

Since 7.1 the only option for querying active directory domains that require authentication other than the account running BP Server is to provide the details of a service account in the Active Directory Domains configuration section in Sign-on settings

Our security policy requires that password-secured accounts have passwords that expire daily. This is unmanageable in 7.1 as it would require us to update the stored passwords in Blue Prism immediately after the passwords have changed

Ideally, we would be able to secure the Active Directory queries with a gMSA

Also, add an option to create gMSA user.

Currently when we try to add AD user it only list/search the AD accounts, it is not searching the Managed Service account (MSA/gMSA). -- Get-ADSServiceAccount

This will help to run the runtime as gMSA account.

[esearleffsb]

@asilarow,

Please elaborate. Using gMSAs to run Windows services is exactly what they were designed for. They automatically generate long, random passwords and rotate them without administrator intervention. As someone who regularly undergoes federal security audits, I can attest that gMSAs are widely viewed as a more secure approach to managing service accounts than static, manually managed passwords.

I'm not aware of any documented breach where the use of a gMSA itself was identified as the root cause of the compromise. Public examples of gMSA abuse, such as the Golden gMSA attack, are post-compromise techniques that require an attacker to have already obtained highly privileged Active Directory access (for example, the KDS Root Key or equivalent privileges). At that point, the attacker has effectively already compromised the forest and can obtain numerous other credentials as well.

Long-lived, manually managed secrets are a well-recognized security liability. Automating credential rotation reduces both security risk and operational overhead. This is the same security principle driving the industry's move toward shorter-lived, automatically renewed TLS certificates. Public certificates have evolved from multi-year lifetimes to 398 days today, with an approved roadmap that will reduce their maximum lifetime to 47 days. The goal is the same: eliminate long-lived secrets and rely on automated rotation wherever possible.

[asilarow]

You are correct in all that you've said, but what I meant is that the gMSA details would need to be given to your RPA admins, and depending on who runs your RPA practice, this may not necessarily be a person who should have access to those (often times they are not IT staff).

Unless of course the setup would be done by an authorised person, then the risk will be lower.