Conflict resolution

The pwdconflicts program is scheduled to run nightly and saves the list of conflicts it finds in the product database. You can view the results of the last pwdconflicts run at Manage the system > Privileged access > Conflicting passwords . On this page, you can click Discover conflicts to run pwdconflicts and refresh the results at any time.

The password conflicts page shows a list of accounts in conflict on the system, their managed system policy, and the reason why the account failed automatic resolution . If automatic resolution has not yet completed, the accounts will be shown but resolution actions will be disabled until automatic resolution finishes.

When the Privileged Access Manager Service (idarch) detects an account in conflict, it connects to each node and retrieves that node’s copy of the account’s randomization tree. It searches for any missing entries or inconsistencies such as differing statuses that might indicate the conflict will be resolved by allowing replication to complete. If any are found, it will wait for replication to flush, up to a configurable maximum set by the system variable VERIFICATION_WAIT_FOR_NODE_TIMEOUT. If the timeout is reached without the nodes reaching consistency, manual resolution is required.

Conflict resolution will only be performed by the idarch service running on the managing node for an account.

The tree of randomizations is searched for passwords whose statuses are either confirmed or uncertain, and which have no confirmed children (these are called candidate passwords). For example, if a single node attempts a randomization and the agent stops responding, the password it attempted (whose status is U) is a candidate as well as the root password (whose status is C) because its child is not confirmed. Candidate passwords are passed to the appropriate connector which attempts to authenticate against the target system with each one using the adminverify operation. The connector is not invoked for accounts that have been used as target administrator credentials, and will only be invoked for pull-mode systems if the ALLOW_AGENT_VERIFICATION_OF_LWS system variable is enabled.

The adminverify operation does not lock out accounts.

The account’s randomization tree is only modified if exactly one candidate password successfully authenticates. Some systems allow old passwords to continue to work for a short period after a change; this case is treated as though all passwords were rejected. When exactly one candidate password authenticates successfully, the passwords tested by the connector are removed from the tree according to the following rules:

Use options available in the Manage the system > Privileged access > Options > Managed system policies menu to:

If automatic resolution cannot resolve the password for any reason, an administrator must manually correct the issue.

Basic manual resolution

From the Conflicting passwords page , you can attempt generalized conflict resolution by selecting the accounts you want to resolve and clicking either Force randomization or Automatically resolve.

Alternatively you can display a current list of conflicts and resolve them with the pwdconflicts program from the command line. See pwdconflicts usage details .

If you are resolving more than a handful of conflicts at a time, you should use the pwdconflicts program.

Automatically resolve

Clicking Automatically resolve will simply re-issue a request to the Privileged Access Manager Service (idarch) to attempt automatic resolution again. This is appropriate for cases such as a Microsoft Active Directory server configured to allow old passwords to work for a short time after a randomization.

This must be done on the same node as the Privileged Access Manager Service (idarch) that is managing the managed system policy that includes the account.

Force randomization

In most cases, Force randomization is the simplest solution to password conflicts requiring manual resolution. Forcing randomization does not make any attempt to determine the correct password, and thus is not suitable for use with accounts where unscheduled randomizations are unacceptable such as target administrators or other sensitive accounts. Instead, the password conflict is cleared as follows:

Generally, if you do not care about the outcome of password resolution, you should choose forced randomization.

Forced randomization will not occur if password randomization is disabled on the managed system policy to which the managed account is bound. See Disabling password randomization for more information.

Blanking

There is one more generalized resolution strategy that is intended to be used as a last resort, but it is not available from the web interface. The -blank option of the pwdconflicts program allows you to erase all ancestry linkages in an account’s randomization tree and start from scratch. This resolution strategy follows the same basic steps as forced randomization with the following exceptions:

Blanking the password is designed to be a failsafe and should work reliably (to the extent that replication is working properly) for all cases. It can be successfully used even if some replicas are permanently or semipermanently offline, unlike forced randomization and automatic resolution retries which require a direct connection to all nodes. To reduce the risk of error, blanking may not be applied to more than one account at a time, and can only be invoked through pwdconflicts .

Because it is a failsafe, blanking performs no validation whatsoever. You should not use password blanking on an account that is being operated on by automatic resolution or by another user using the web interface unless it is unavoidable in an emergency.

Advanced manual resolution

You can click on accounts from the conflicting passwords page to see more details about the conflict. There is an example of this page in Incomplete randomization conflicts . Every password in wstnpwd_working on each node is displayed here with various metadata like its status, sigkey, the node that created it, and the node that created its parent. If you have sufficient access, a disclosure plugin is rendered with the actual value of the password.

You must have the "Pre-approved check-out of managed accounts" permission on the account’s managed system policy to view passwords on this screen. Being a superuser is neither sufficient nor necessary.

Incomplete randomization conflicts

Figure 1. Incomplete randomization resolution

Details of the randomization tree for a specific account for a conflict caused by an incomplete randomization.

The screenshot above shows a scenario in which the connector attempted to randomize a password but stopped responding. Bravura Privilege marked the password it was supposed to set as uncertain and generated a conflict. Both nodes agree completely about this randomization tree, but neither knows whether the password passed to the connector was successfully put in place.

On this page, the displayed status string Multiple passwords have been set on this account, but it is unknown which is valid means the password has status U. In the context of an overall account, that string can indicate either a tree conflict or an incomplete randomization conflict. In the context of a single password, as in this case, that string always marks an incomplete randomization.

To resolve an incomplete randomization conflict, you must decide for each uncertain password whether it was successfully set on the target system. You may need to engage the owners of this target system to check its logs in order to decide which randomizations were successfully applied. You may also wish to manually test passwords to determine which is correct if you have access to them. Since lockouts are a concern, it would be a good idea to start with the password with the latest timestamp for this approach. Also, you should keep in mind that some systems such as Active Directory may allow old passwords to work for a short time after randomization.

When you have decided whether a password was successfully set, select the radio button for that password and click either Confirm selected password or Reject selected password to set its status to C or F, respectively. Clicking either button will cause the tree to be rechecked for conflicts. Repeat the process for each uncertain sigkey.

Although the page will display radio buttons for all uncertain passwords (one per node), you only need to perform this operation once for each distinct sigkey. Bravura Privilege will automatically correct all matching passwords on all nodes.

Tree conflicts

Figure 2. Tree conflicts

Details of the randomization tree for a specific account for a tree conflict.

If there are both tree and incomplete randomization conflicts, you must resolve the incomplete randomization conflicts before you can resolve the tree conflicts.

The screenshot above shows a very common scenario where two nodes randomized the same account at the same time. Each node has the same set of passwords, but disagrees about which is current. One node, claytonv-2k8-4_conflicts created E6AB2BA4387DFBCD4C75772BB173C9BC at 5/4/2018 4:27 PM and then attempted to set it. The other node, claytonv-2k8-r2.2k3-domain.claytonv_conflicts created 4EAE01004E15B09591825A322972FF7E at 5/4/2018 4:29 PM and attempted to set it. Both nodes successfully set their passwords. There was a slight replication backlog between 4:27 PM and 4:29 PM which caused these two randomizations to occur with the same parent.

When there are tree conflicts, as in this case, manual resolution entails choosing a single candidate password and making it the new root on all nodes by clicking Set as current password. Once again, you may need to engage the owners of this target system to check its logs, or manually test passwords, in order to decide which password is correct. For example, if the target system shows the latest password change as having come from claytonv-2k8-4 , then E6AB2BA4387DFBCD4C75772BB173C9BC should be set as the current password.