Navigation Tree

Secondary identifier

Last modified 16 Mar 2026 17:09 +01:00

Indicates whether the attribute should be considered a secondary identifier.

If set to true, the attribute is assumed and enforced to be unique and is always stored in the repository. For example, ri:sAMAccountName in Active Directory can be promoted to be the secondary identifier using this configuration property.

This configuration property can also be used to block an attribute from being used as a secondary identifier. It is useful in situations when a connector marks an attribute—typically, icfs:name—as a secondary identifier, but the attribute is not really unique. (ConnId contract for this attribute doesn’t mandate its uniqueness.) This is a problem.

MidPoint must be configured to stop using this attribute as a secondary identifier:

Block the icfs:name attribute from being used as a secondary identifier

<attribute>
    <ref>icfs:name</ref>
    <!-- Name is not unique, so we need to disable this as a secondary identifier. -->
    <secondaryIdentifier>false</secondaryIdentifier>
    ... the rest of the attribute config, mappings, etc.
</attribute>

This may work fine, but the result is not guaranteed. Some scenarios may require a secondary identifier.

Prevent duplicating accounts instead of linking

When you have an authoritative source system (e.g., HRIS) and an Active Directory (AD) as a target system, you may face the following situation:

You import users from the source system.
You expect (and have midPoint set up to do so) to have the imported accounts provisioned to AD.
The AD provisioning fails with AlreadyExistsException because some of the imported accounts already exist there but midPoint was unable to link them.

What happens is that midPoint, being unaware of the target resource accounts existence, tries to create a duplicate of them but that is prohibited by the AD target system. Instead of gracefully handling the exception, discovering the pre-existing accounts, and linking them with the corresponding focal objects, midPoint ends up with an unhandled exception, unable to proceed. This may be because your primary identifier is a DN and the existing target accounts have a DN that is different from what midPoint computed for the imported accounts.

To fix the situation, set another unique attribute as a secondary identifier to help midPoint link the accounts. For instance, the userPrincipalName attribute: it is typically unique across the AD "forest" and is not position-dependent the way DN is. Adding it as a secondary identifier allows the discovery mechanism to find the existing accounts regardless of their organization units (OU).

In the schemaHandling section of your target resource, add <secondaryIdentifier>true</secondaryIdentifier> to the userPrincipalName attribute definition:

Set the userPrincipalName attribute as a secondary identifier

<resource>
    ...
    <schemaHandling>
        <objectType>
            <attribute>
                <ref>ri:userPrincipalName</ref>
                <secondaryIdentifier>true</secondaryIdentifier>
                ...
                <outbound>
                    ...
                </outbound>
            </attribute>
            ...
        </objectType>
    </schemaHandling>
</resource>

Secondary identifier

Prevent duplicating accounts instead of linking

See also