Activity - Service Account Password rotation

[rsantos (randy)]

Which version of Privilege Secure do you have?

Privilege Secure AM

What is a one sentence summary of your feature request?

Ability to manage service accounts via Activities without needing to enable and disable the account.

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

We would like to have Netwrix manage the passwords for select service accounts in Active Directory that synchronize with Google and Microsoft 365, without requiring the service accounts to be enabled and disabled as part of the process.

The reason for this is that Microsoft 365 and GADSYNC synchronize approximately every 45 minutes. If a service account is disabled and then re-enabled, there could be a delay of up to 45 minutes before the account is re-enabled in the cloud environment.

Instead, we would like to explore having Netwrix change the password on the service account when access to the resource is requested. This would allow us to maintain the account’s enabled status while still providing the security benefits of password management and rotation through Netwrix.

We believe this approach would eliminate the synchronization delay while still providing a secure method of managing the credentials for these service accounts. This provides great value-add, since Google’s Workspace page has a show password button that exposes the service account’s password.

How do you currently solve the challenges you have by not having this feature?

We are utilizing TOTP codes to better protect the service accounts.

[Billy (Billy VanCannon)]

Hi Randy,

Thank you for the feedback.

By “service account” I assume we are not referring to accounts that NPS uses for connectivity to AD or machines, rather accounts that it manages and other services use, in which case they can be “managed” in NPS.

When creating sessions, we have two types. 1. Resource based, where the idea is to enable a user to connect via RDP/SSH/webiste to a resource using NPS. We can do all kinds of “activities” during the session like select the login account, promote privilege, etc. 2. Credential release, where we don’t assume a connection, only that a user wants to get access to the password and use the managed account outside NPS.

I think you should try credential release. By default, when a session is started, the account is enabled and the password is rotated. Then when the session is ended, the password is rotated again and the account is disabled. However these can be controlled per account.

In Resources => => Users => => Password Reset Options button and you see this:

You can then select from the above. I assume you would select the last one.

Let me know if this works.

Best Regards,

Billy

[rsantos (randy)]

Thanks for the response Billy, may we are doing it a different way hence the confusion.

Right now we have a recourse website for admin.google.com

We have an AD service account that syncs up to Google with a Google elevated role.

Right now, the Activity we have selected is Login Account Vault: interactive, so that the username and password can auto fill.

Under Resources, I am not seeing that option for websites. Thanks

[Billy (Billy VanCannon)]

OK, I think I understand the use case better now.

Since you are connecting to admin-google.com and using the auto-fill, this is the Resoucrce-based flow, not Credential-based. In this case, we always enable/disable the account. I don’t know why that wasn’t made optional. In any case, that is a feature request. I can look into that but am not sure how long it will take.

The alternative is to setup Credential-based sessions. You can give an NPS user (or users) access to the Google (AD) account password. The downfall is they have to get the password out of the NPS GUI and not get the autofill or the ability to record the session. If that is allowable, do this.

You might already have a connection profile you can use, but if not.

Access Policy => Connection profiles => “+” (middle panel) => Give it a name, description and the defaults work. Make sure the Enable “Show Password” option is checked. Also set a time if desired. Further down, you can set if you want others to approve the credential release or not.

Access Policy => “+” (middle panel) => Give it a name, description, Choose Credential Based, and the above connection profile. Save

Then select Users. Add the NPS user(s) that you want to provide access to the Google password. Activities has no options here. Select Credentials. Here you can select the Google (AD) managed account(s).

Finally, go to Resources => Users => <select your managed Google (AD) account> => Password reset options. Set when you want the pw to rotate. Sounds like at the end of the session at minimum for your use case. Check the Keep Enabled box.

With that setup, the NPS users should be able to login and under MyActivities see the Credential release tile. They can then start a session. If you setup approvers in the conneciton profile, then they will have to approve. The user can select from the managed Google (AD) accounts and start the session.

Once the session starts, they can click the top right and get access

When they stop the session, the pw will rotate but not disable the account.

I hope this helps.

Billy

[rsantos (randy)]

I could’ve gotten away with exposing the password since the account has a rotating TOTP code, but we can’t not record the sessions. We not only use it for training, but also for accountability.

If would be great if we could get the functionality of not disabling the account as an option in the future as that would keep the password hidden plus granting us the ability to rotate. Thanks

[chelsea]

@Billy - OP has a similar structure to how we operate. The credential option works, but our particular issue is that each individual has their own admin account, ie typically called the mortal and admin account separation, where you’d be billystandard and have an admin level account that is a separate sign in as billyadmin. Is there a way to use the filters/variables in a credential rotation based policy? Kicker here is you can put all of the credentials of all people who have admin accounts, but we wouldnt want to see it. Its that or there’s an access policy for each person who has it. in a department of 50+ admin account holders, if I wanted them to have the only credential available for check out to be their own admin account, I’d need 50+ separate access policies or some sort of variable call. Is this a configuration we could fix on our end or a feature request similar to the disable need you mention to Randy?

[Billy (Billy VanCannon)]

Thank you both for the feedback.

For Randy’s request, not disabling the account at the end of the resource-based session is something we can add in the future. Perhaps Q2 2027?

For Chelsea, the variable-based policy is also a feature request. I think you are saying the billyadmin accounts should be setup with credential-release, not disable the account, but rotate the password so they don’t. But instead of 50+ access polices based on it, the access policy is billystandard gets credential access to billyadmin accounts? Is that literally how they are designated? This one will be difficult for a general use case I think.

Billy