Dual authorization

Using dual authorization means that each change that is made by one administrator to configuration data becomes active only after it is approved by another administrator. This increases security by prohibiting a single administrator from changing the configuration. Dual authorization is enabled by default, but can be switched off by a configuration administrator; however, this must be approved by a second configuration administrator.

If dual authorization is:

Enabled: All changes must be approved by a second person with the requisite authority and from the same OU. Approval activates the changes; rejection rolls back the changes. If a change is rejected, the lock is removed and further changes by the first administrator (or any other administrator) are allowed.
Disabled: For changes to security-related objects (roles, role groups, role assignments, and role group assignments), the same security administrator who made the changes can approve them. For changes to configuration-related objects (CTs, COs, COSs, and OUs), the approval step is optional.

For more information about how to set up and use single or dual authorization, see Life-cycle stages and their states.

Changes to this data are recorded in user audit records, so that you can track such changes.

Dual authorization affects only the approval stage of the configuration process. When you enable dual authorization, a user ID different from the one that made and committed the initial changes must approve them. If you do not enable dual authorization, you or any user who has the access rights can immediately activate the change.

Figure 1 shows how the configuration process flow differs when you have dual authorization enabled and when you do not.

Figure showing configuration process flow with and without dual authorization enabled. — Figure 1. Comparison of configuration process flow when dual authorization is enabled and when it is disabled

When dual authorization is enabled, the entity must pass through the approval stage. After this, if you do not agree with the approval of the change, you can reject it. This action moves the entity from the "Approved" state to the "Committed" state. You issue the app (approve) and ra (reject approval) commands only if dual authorization is enabled.

When dual authorization is disabled, you skip the approval stage. You commit your modified entity. Then you or any user who has the access rights can activate the changes. Another person does not need to approve the changes.