Skip to main content

Hello, just wondering in order to “increase” security to SQL DB of CommServe, following CIS Level 1 hardening, is it a good idea to remove sysadmin permissions from local / windows user from SSMS?

After this action, is there any way to connect to COMMVAULT SQL instance?

Where we can find the credentials for these sql local users?

Please for your feedback!

Hi @Nikos.Kyrm 

Sysadmin is set by default for these Users, so do not remove them.

The sa Account was created when Commserve was installed, so only you or your Team would know the password.

sqladmin_cv and SQLexec_CV we have our passwords encrypted and a tool can be used to decrypt them.

Best Regards,

Sebastien


I understand your general concern about the security hardening.

I agree with your points, but here are the facts about these accounts.

sqladmin_cv  account is our primary SQL account used by the Commvault software and requires a sysadmin role. This level of access is necessary for the proper functioning of the Commvault software. 

The sqlexec_cv user has a public role for all databases and a securable one where the grantee impersonates the sqladmin_cv account. The Commvault software requires these permissions. So, this control cannot be supported. 

At the same time, we can ensure the 'sa' Login account can be disabled and  'sa' Login account can be renamed to meet the CIS standards.

I think SQLmetrics_cv is used by the metrics server for reporting and analysis.

In our case, strictly adhering to strict CIS Level 1 hardening that involves removing sysadmin permissions may not be feasible without impacting the software’s functionality.

 

Regarding the password, SA is created as part of the SQL installation and will be documented by the installation and configuration team. 


As my colleagues have already advised. sqladmin_cv and sqlexec_cv are accounts used by our services to interact with the CSDB. They have an encrypted password randomly configured at deployment. They should not have any of their properties (including their permissions) modified under the risk of operations starting to fail.

In regards of the sa account, its password is configured at deployment by the user, we won’t have it.

In regards to hardening, it would be a better idea to remove any AD credentials from being able to log into SQL, this way a compromised AD admin account won’t be able to gain access to the CSDB and the thread actor will need to also obtain the local SQL accounts in order to cause any harm.

 

Regards,

Javier


Dear @Javier  I agree,

I understand that sa is not necessary for Commvault operations, that’s why is renamed / disabled after CIS Level 1 hardening.

So, in case of disabling also the (default) windows authentication user (and lost the connection to SQL once and for all), will there be any reason to connect to the SAL DB again in the future?

sqladmin_cv and sqlexec_cv are accounts are the only necessary users?


Access shouldn’t be needed for regular day to day operations.

Support or development may need access to the CSDB from time to time to check things, but in that case we could always use the sqladmin_cv account after decrypting the password internally (which requires an AuthCode nowadays to allow the decryption)


Reply