Multi-admin verification overview

Contributors

PDFs

Beginning with ONTAP 9.11.1, you can use multi-admin verification (MAV) to ensure that certain operations, such as deleting volumes or Snapshot copies, can be executed only after approvals from designated administrators. This prevents compromised, malicious, or inexperienced administrators from making undesirable changes or deleting data.

Configuring multi-admin verification consists of:

After initial configuration, these elements can be modified only by administrators in a MAV approval group (MAV administrators).

When multi-admin verification is enabled, the completion of every protected operation requires these steps:

When a user initiates the operation, a request is generated.
Before it can be executed, at least one MAV administrator must approve.
Upon approval, the user completes the operation.

If you need to disable multi-admin verification functionality without MAV administrator approval, contact NetApp Support and mention the following Knowledge Base article: How to disable Multi-Admin Verification if MAV admin is unavailable.

Multi-admin verification is not intended for use with volumes or workflows that involve heavy automation, because each automated task would require approval before the operation could be completed. If you want to use automation and MAV together, it's recommended to use queries for specific MAV operations. For example, you could apply volume delete MAV rules only to volumes where automation is not involved, and you could designate those volumes with a particular naming scheme.

Multi-admin verification is not available with Cloud Volumes ONTAP.

How multi-admin verification works

Multi-admin verification consists of:

A group of one or more administrators with approval and veto powers.
A set of protected operations or commands in a rules table.
A rules engine to identify and control execution of protected operations.

MAV rules are evaluated after role-based access control (RBAC) rules. Therefore, administrators who execute or approve protected operations must already possess the minimum RBAC privileges for those operations. Learn more about RBAC.

System-defined rules

When multi-admin verification is enabled, system-defined rules (also known as guard-rail rules) establish a set of MAV operations to contain the risk of circumventing the MAV process itself. These operations cannot be removed from the rules table. Once MAV is enabled, operations designated by an asterisk ( * ) require approval by one or more administrators before execution, except for show commands.

security multi-admin-verify modify operation *

Controls the configuration of multi-admin verification functionality.
security multi-admin-verify approval-group operations *

Control membership in the set of administrators with multi-admin verification credentials.
security multi-admin-verify rule operations *

Control the set of commands requiring multi-admin verification.
security multi-admin-verify request operations

Control the approval process.

Rule-protected commands

In addition to system-defined operations, the following commands are protected by default when multi-admin verification is enabled, but you can modify the rules to remove protection for these commands.

security login password
security login unlock
set

Each ONTAP version provides more commands you can choose to protect with multi-admin verification rules. Choose your ONTAP release for the full list of commands available for protection.

9.15.1

cluster date modify ³
cluster log-forwarding create ³
cluster log-forwarding delete ³
cluster log-forwarding modify ³
cluster peer delete
cluster time-service ntp server create ³
cluster time-service ntp server delete ³
cluster time-service ntp server key create ³
cluster time-service ntp server key delete ³
cluster time-service ntp server key modify ³
cluster time-service ntp server modify ³
event config modify
lun delete ³
security anti-ransomware volume attack clear-suspect ¹
security anti-ransomware volume disable ¹
security anti-ransomware volume pause ¹
security audit modify ³
security ipsec config modify ³
security ipsec policy create ³
security ipsec policy delete ³
security ipsec policy modify ³
security login create
security login delete
security login modify
security saml-sp create ³
security saml-sp delete ³
security saml-sp modify ³
snaplock legal-hold end ³
storage aggregate delete ³
storage encryption disk destroy ³
storage encryption disk modify ³
storage encryption disk revert-to-original-state ³
storage encryption disk sanitize ³
system bridge run-cli ³
system controller flash-cache secure-erase run ³
system controller service-event delete ³
system health alert delete ³
system health alert modify ³
system health policy definition modify ³
system node autosupport modify ³
system node autosupport trigger modify ³
system node coredump delete ³
system node coredump delete-all ³
system node hardware nvram-encryption modify ³
system node run
system node systemshell
system script delete ³
system service-processor ssh add-allowed-addresses ³
system service-processor ssh remove-allowed-addresses ³
system smtape restore ³
system switch ethernet log disable-collection ³
system switch ethernet log modify ³
timezone ³
volume create ³
volume delete
volume encryption conversion start ³
volume encryption rekey start ³
volume file privileged-delete ³
volume flexcache delete
volume modify ³
volume recovery-queue modify ²
volume recovery-queue purge ²
volume recovery-queue purge-all ²
volume snaplock modify ¹
volume snapshot autodelete modify
volume snapshot create ³
volume snapshot delete
volume snapshot modify ³
volume snapshot policy add-schedule
volume snapshot policy create
volume snapshot policy delete
volume snapshot policy modify
volume snapshot policy modify-schedule
volume snapshot policy remove-schedule
volume snapshot rename ³
volume snapshot restore
vserver audit create ³
vserver audit delete ³
vserver audit disable ³
vserver audit modify ³
vserver audit rotate-log ³
vserver delete ³
vserver modify ²
vserver object-store-server audit create ³
vserver object-store-server audit delete ³
vserver object-store-server audit disable ³
vserver object-store-server audit modify ³
vserver object-store-server audit rotate-log ³
vserver options ³
vserver peer delete
vserver security file-directory apply ³
vserver security file-directory remove-slag ³
vserver vscan disable ³
vserver vscan on-access-policy create ³
vserver vscan on-access-policy delete ³
vserver vscan on-access-policy disable ³
vserver vscan on-access-policy modify ³
vserver vscan scanner-pool create ³
vserver vscan scanner-pool delete ³
vserver vscan scanner-pool modify ³

9.14.1

cluster peer delete
event config modify
security anti-ransomware volume attack clear-suspect ¹
security anti-ransomware volume disable ¹
security anti-ransomware volume pause ¹
security login create
security login delete
security login modify
system node run
system node systemshell
volume delete
volume flexcache delete
volume recovery-queue modify ²
volume recovery-queue purge ²
volume recovery-queue purge-all ²
volume snaplock modify ¹
volume snapshot autodelete modify
volume snapshot delete
volume snapshot policy add-schedule
volume snapshot policy create
volume snapshot policy delete *
volume snapshot policy modify
volume snapshot policy modify-schedule
volume snapshot policy remove-schedule
volume snapshot restore
vserver modify ²
vserver peer delete

9.13.1

cluster peer delete
event config modify
security anti-ransomware volume attack clear-suspect ¹
security anti-ransomware volume disable ¹
security anti-ransomware volume pause ¹
security login create
security login delete
security login modify
system node run
system node systemshell
volume delete
volume flexcache delete
volume snaplock modify ¹
volume snapshot autodelete modify
volume snapshot delete
volume snapshot policy add-schedule
volume snapshot policy create
volume snapshot policy delete *
volume snapshot policy modify
volume snapshot policy modify-schedule
volume snapshot policy remove-schedule
volume snapshot restore
vserver peer delete

9.12.1/9.11.1

cluster peer delete
event config modify
security login create
security login delete
security login modify
system node run
system node systemshell
volume delete
volume flexcache delete
volume snapshot autodelete modify
volume snapshot delete
volume snapshot policy add-schedule
volume snapshot policy create
volume snapshot policy delete *
volume snapshot policy modify
volume snapshot policy modify-schedule
volume snapshot policy remove-schedule
volume snapshot restore
vserver peer delete

New rule-protected command for 9.13.1
New rule-protected command for 9.14.1
New rule-protected command for 9.15.1

*This command is only available with CLI and is unavailable for System Manager.

How multi-admin approval works

Any time a protected operation is entered on a MAV-protected cluster, an operation execution request is sent to the designated MAV administrator group.

You can configure:

The names, contact information, and number of administrators in the MAV group.

A MAV administrator should have an RBAC role with cluster administrator privileges.
The number of MAV administrator groups.
- A MAV group is assigned for each protected operation rule.
- For multiple MAV groups, you can configure which MAV group approves a given rule.
The number of MAV approvals required to execute a protected operation.
An approval expiry period within which a MAV administrator must respond to an approval request.
An execution expiry period within which the requesting administrator must complete the operation.

Once these parameters are configured, MAV approval is required to modify them.

MAV administrators cannot approve their own requests to execute protected operations. Therefore:

MAV should not be enabled on clusters with only one administrator.
If there is only one person in the MAV group, that MAV administrator cannot initiate protected operations; regular administrators must initiate protected operations, and the MAV administrator can only approve.
If you want MAV administrators to be able to execute protected operations, the number of MAV administrators must be one greater than the number of approvals required. For example, if two approvals are required for a protected operation, and you want MAV administrators to execute them, there must be three people in the MAV administrators group.

MAV administrators can receive approval requests in email alerts (using EMS) or they can query the request queue. When they receive a request, they can take one of three actions:

Approve
Reject (veto)
Ignore (no action)

Email notifications are sent to all approvers associated with a MAV rule when:

A request is created.
A request is approved or vetoed.
An approved request is executed.

If the requestor is in the same approval group for the operation, they will receive an email when their request is approved.

A requestor can't approve their own requests even if they are in the approval group. They can get email notifications. Requestors who are not in approval groups (that is, who are not MAV administrators) don't receive email notifications.

How protected operation execution works

If execution is approved for a protected operation, the requesting user continues with the operation when prompted. If the operation is vetoed, the requesting user must delete the request before proceeding.

MAV rules are evaluated after RBAC permissions. As a result, a user without sufficient RBAC permissions for operation execution cannot initiate the MAV request process.