Protected Accounts

Last modified 01 Jul 2024 15:29 +02:00
Protected accounts feature
This page is an introduction to Protected accounts midPoint feature. Please see the feature page for more details.

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:

<resource>
    ...
    <schemaHandling>
    ...
        <objectType>
            ...
            <protected>
                <filter>
                    <q:text>attributes/carLicense =[stringIgnoreCase] "ignoreme"</q:text>
               </filter>
            </protected>
            ...
        </objectType>
    </schemaHandling>
</resource>

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

This example also shows the current limitation of this mechanism: When it refers to attributes that are not stored in the repository, the shadow is marked as protected only if these attributes are fetched. This is the case in traditional synchronization tasks (import, live sync, reconciliation), but may not be case e.g. when browsing the resource objects. Please see MID-7671. This restriction is going to be lifted by caching the flag, see MID-7917. 
<resource>
    ...
    <schemaHandling>
    ...
        <objectType>
            ...
            <protected>
                <filter>
                    <q:text>attributes/name endsWith[stringIgnoreCase] "ou=SUPERSECRET,dc=example,dc=com"</q:text>
               </filter>
            </protected>
            ...
        </objectType>
    </schemaHandling>
</resource>

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.

Historical Notes

Prior to midPoint 4.0 the following notation was possible:

<resource>
    ...
    <schemaHandling>
    ...
        <objectType>
            ...
            <protected>
                <icfs:name>root</icfs:name>
            </protected>
            <protected>
                <icfs:name>daemon</icfs:name>
            </protected>
            ...
        </objectType>
    </schemaHandling>
</resource>

Support for this notation was removed in midPoint 4.0.

See Also

Compliance

This feature is related to the following compliance frameworks:

Was this page helpful?
YES NO
Thanks for your feedback