Commvault Two Factor Authentication
You set up commvault two factor authentication by enabling login checks for user groups. Users then enter a password and a temporary code from a phone app. Teams often turn this feature on for all backup admins right away. Still, a login check does not shrink broad role permissions after login. An admin with full rights can still delete backups or read secret files. How commvault two factor authentication works in practice The backup platform manages login rules at the domain or user group le
Multi-Factor Authentication (MFA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up commvault two factor authentication by enabling login checks for user groups. Users then enter a password and a temporary code from a phone app. Teams often turn this feature on for all backup admins right away. Still, a login check does not shrink broad role permissions after login. An admin with full rights can still delete backups or read secret files.
How commvault two factor authentication works in practice
The backup platform manages login rules at the domain or user group level. You can turn on the extra login check for the whole system. You can also apply the rule to specific admin groups only. When a user logs in, the server checks their password first. Next, the server asks for a one-time code to finish the login.
Users get this code in a few standard ways. Many teams use a phone app that makes a new code every thirty seconds. When a user logs in for the first time, they scan a barcode. This step links their phone app to their backup user account. Other teams send the one-time code to the user by email. Some setups also connect to an outside login service using standard web rules. In that case, the outside login service handles the second check.
Backup jobs and scripts also need to run on a schedule. If a script uses a normal user account, the code prompt stops it. Teams fix this by using special system accounts or token keys for scripts. Human admins use accounts that require the two-step login check.
What login checks solve and what they miss
Stolen passwords cause many major data breaches. A two-step login stops attackers who only have a stolen password. Even if an attacker guesses a password, they lack the phone code. This protects your web console and command line tools from basic attacks. It also helps your team meet basic security audit rules.
Still, a login check only guards the front door. Once an admin logs in, the system trusts every action they take. Backup tools hold copies of every database, file server, and mail box. A logged-in user with broad rights can restore a database to any machine. They can then read customer emails, phone numbers, card numbers, or national IDs.
Multi-Factor Authentication (MFA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native backup roles are often too wide for daily fix tasks. An engineer might need to check one failed backup job. Yet their group role lets them change retention rules or wipe old snapshots. Login checks cannot inspect individual commands or block a dangerous restore in flight. They also cannot rewrite sensitive fields when someone views raw backup data.
Keeping admin roles and script keys safe
To reduce risk, teams split daily users from full system admins. Engineers get read-only roles to check job logs and alerts. Only a small group gets the right to delete backups or change storage. Teams also review group rules every month to catch old accounts. If someone leaves the team, admins remove their login right away.
Teams must also watch the command line interface and web API. Attackers often target script keys because those keys skip the phone code prompt. You should rotate script keys often and limit where scripts can run. Good security pairs strong login checks with tight limits on every single session.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Can we turn on two-step login for specific user groups only?
Yes, admins can apply the rule to chosen user groups or domains. This lets you test the setup with a small group before a full rollout.
How does a user fix a lost phone or broken code app?
A system admin can reset the secret key for that user account. The user then scans a new barcode on their next login to pair again.
Does two-step login break automated backup scripts?
It can break scripts that log in with a normal human account. Teams use dedicated token keys or exclude service accounts so scheduled jobs run.