Define rules for LDAP mapping, synchronization, and correlation

Last modified 21 Oct 2025 14:28 +02:00
Table of Contents

Define synchronization rules

Define the synchronization rules for the LDAP resource. Use the Proposed lifecycle state to prevent any damage to real data before you validate the configuration.

Name Situation Reaction Lifecycle state Comments

link-unlinked

Unlinked

Link

Proposed

There’s a focus for the account but it’s not linked to the shadow of the account yet, let’s link it. This isn’t used during the first import, but it’s necessary for later when the account shadows are in midPoint already.

synchronize-linked

Linked

Synchronize

Proposed

Synchronize the data between the remote account and the focus based on mappings.

synchronize-deleted

Deleted

Synchronize

Proposed

Restore "illegally" deleted accounts on the resource using the shadow in midPoint.

delete-unmatched-resource-object

Unmatched

Delete resource object

Draft

Delete orphaned ("illegal") resource objects, i.e., those not present in HRIS and thus not having shadow in midPoint. Potentially destructive in case of misconfiguration.
Keep in Draft (effectively disabled) until you learn later in the guide about options other than hard delete.

create-correlation-case-for-disputed

Disputed

Create correlation case

Proposed

In case a candidate owner isn’t found with 100% certainty, create a correlation case to let a human operator resolve the situation. You’ll learn more a bit later.

See Synchronization to learn about the topic in more depth.

Create inbound mappings for correlation

As the LDAP resource is currently strictly an inbound resource, meaning that it can’t push any data to midPoint, you’re going to define a new kind of mappings. The thing is, to successfully correlate accounts on the LDAP server with the users in midPoint, you need inbound mappings for the LDAP resource, i.e., from LDAP to midPoint. However, as you don’t want any data coming from LDAP to midPoint, the regular inbound mappings aren’t the best fit.

That’s why you’re going to define inbound mappings strictly for correlation purposes. MidPoint will use these mapping rules only to know which resource attribute to correlate with which internal (focus) user attribute.

These are the mappings to use:

Name Source Expression Target Lifecycle state Comments

inbound-employeeNumber-for-correlation

employeenumber

As is

personalNumber

Active

Used for correlating employee number in the resource with the personal number in midPoint.

inbound-surname-for-correlation

sn

As is

familyName

Active

Used for the second correlation rule when the default employee number correlation fails.

inbound-givenName-for-correlation

givenname

As is

givenName

Active

Used for the second correlation.

inbound-locality-for-correlation

l

As is

locality

Active

Used for the second correlation.

Refer to this guide on how to define mappings: Resource Wizard: Object Type Mappings. Use inbound mappings and set them to be used for correlation only:

  1. Click  Edit on the far-right on each mapping row.

  2. In Use for, select Correlation.

  3. Click  Exit wizard.

Define LDAP correlation rules

Now is the time to define correlation rules for the LDAP resource accounts.

Correlation in midPoint is a mechanism used to identify the owner of a resource object, such as an account. It involves finding the corresponding focus object associated with a particular resource object. This process essentially binds the shadows of the resource objects to their appropriate midPoint focal objects.

Refer to Correlation for more details on the topic.

In general, to correlate objects from various resources, you need to find a common identifier. In the case of the showcase data this guide uses, the common identifier are the employee numbers. If an LDAP server entry has the same employee number as a user in midPoint, they’re surely a match.

For the cases when this bullet-proof matching fails due to erroneous data, for instance, you can set up a fall-back correlation rule using a set of other attributes, such as first name + surname + locality. Such rule doesn’t have as high confidence because there may be cases when two people of the same name are in the same place. For this lower confidence, this rule is set to create a correlation case, meaning it can only suggest which focus object should be bound to which resource shadow, but a human operator needs to confirm the match.

In the suggested setup below, the fall-back rule that uses names+locality has the confidence of only 0.5. That means that even if all the three attributes match, the match would be only 50% sure and, thus, a correlation case would be created by midPoint.

Refer to this guide on setting up correlation: Resource wizard: Object type correlation.

Here are the correlation rules to use.

Rule name Description Weight Tier Enabled Correlators (Item : Search method)

personalNumber-correlation

Correlation using personalNumber. Doesn’t require human intervention.

1

True

personalNumber : Exact match

last-resort-correlation[1]

Correlation using givenName, familyName and locality. Trusted only by 50%, human intervention is needed.

0.5

10

False

givenName : Exact match
familyName : Exact match
locality: Exact match

The attributes used in the correlation rules are acquired by the correlation-only inbound mappings.
1. The last-resort-correlation rule is disabled now but you will use it later.
Was this page helpful?
YES NO
Thanks for your feedback