Skip to end of metadata
Go to start of metadata

MidPoint can protect specific accounts against any change. Such accounts cannot be modified or deleted from midPoint, they will not appear in searches (imports), they will not be reconciled or otherwise synchronized and midPoint will even not be able to read them.

This feature is used to make sure that midPoint will not destroy vital accounts such as root or administrator. MidPoint is very flexible, using expressions and complex policies for provisioning. It may be easy to make a mistake and e.g. unintentionally disable such accounts. This may happen especially while the policies are constructed during midPoint deployment. Therefore midPoint provides a mechanism that limits possible impact of misconfiguration. This mechanism is called protected accounts.

Protected accounts may be specified per-resource. The definition is part of account definition in the schemaHandling section. Following code provides an example of such definition:

The protected accounts are specified by enumerating the individual identifiers. This definition will protect accounts whose ICF NAME (username) is root and daemon.

You can also use filters to specify the protected accounts:

The above example will protect accounts with carLicense attribute equal to "ignoreme" string.

The final example will protect all accounts under "OU=SUPERSECRET,dc=example,dc=com" subtree.

Protected accounts will be shown in midPoint, but such accounts will be clearly marked as protected. Any operation that attempts to modify or delete them will fail. Protected accounts will be ignored in import, live sync, reconciliation or any other synchronization mechanism.

Why we need shadows for protected accounts?

Protected accounts are fetched into midpoint and there is a shadow for each protected account. MidPoint needs to be aware about protected accounts to know that the identifier belonging to the protected account is already taken. While the protected accounts are currently explicitly enumerated the method of protected account specification may be extended in the future (e.g. specifying a filter). In such a case the midPoint will not be able to handle identifier allocation correctly without having shadows for protected accounts. There are also other reasons e.g. to correctly display account lists in GUI, auditing and overall this is better for visibility into the IDM solution.

  • No labels