Skip to main content
Solved

Sql sysadmin password change often, causes failed.

  • 22 January 2022
  • 4 replies
  • 1087 views

Hello, Everyone.

I am currently in an environment where they use CyberArk to change all service accounts passwords at different intervals.

 

They have their sysadmin sa for sql database backup on cyberark and it changes often. The backup administrator does not know when the password changes because it is automated.

 

This often leads to backup failure due validation of credentials. 

Is there a workflow to update the passwords as they change that?  Or a way commvault can be on on-boarded on cyberark so the passwords updates as they change. Or a different way that the issue can be resolved.

 

Note:Security is paramount to them, they are not looking to change how their passwords are generated.

 

Please, help.

I know customers have used the API integration in cyber ark to facilitate password changes (POST User/AccountManagement API) - but in this instance you might want to take a look at this workflow:

https://documentation.commvault.com/v11/expert/49810_refresh_commserve_database_access_key_workflow.html

Updating the SQL passwords for the CommServe is a bit more complex as there is encryption involved, updates to the ODBC connector etc - this workflow takes care of all of that.

You can use the ‘save as script’ function when executing a workflow to get a command-line executable versions that perhaps you can automate with CyberArk?

 

Starting with FR23 you also have the option of using the CyberArk Commvault plugins to rotate credentials.  One thing to be aware of, credentials need to be reviewed for uniqueness otherwise there might be unintended consequences.  e.g. If CyberArk issues a rotation request for credential “sqlbackupaccount” - ALL instances of that credential are updated.  If the same credential name exists multiple times but with different passwords, this would cause issues.  This would be an issue where local accounts (rather than domain accounts) are in use.  Following best advice, local accounts should use unique names (rather than sharing the same password) to mitigate this issue.  For further information you can review our online documentation or if you have access to CyberArk documentation you can review their Commvault CommCell - Implementation Guide available in their MarketPlace.

 

This from our FR23 release notes:

Integrate the Commvault Software with CyberArk's Privileged Credentials and Session Management Solution

Manage and secure Commvault login credentials, application credentials, and administrative login sessions using CyberArk's Privileged Credentials and Session Management solution. With CyberArk and Commvault integration, organizations can synchronously rotate account passwords across their environment. Commvault receives password rotation requests to update application and local admin account credentials so that backups continue to run seamlessly, without manual intervention. You can also use CyberArk session management to log on to Commvault using one-time use admin credentials. This integration provides secure, centralized credential management to protect against credential theft and abuse.

More Information

 

 

@Mubaraq  Just providing this as an alternate to the already excellent answers provided by Steven and Damian above but could they just use local system for the SQL backups? If they grant NT AUTHORITY\SYSTEM sysadmin role and you set the backup to use local system in CV instead of a specific account, then there is no need to leverage any user accounts or passwords.

 

Thank you to everyone for the contribution……...i will be working with the cyberArk team to work with the suggestions.

Terms & ConditionsCookie settings