Define Active Directory rules for mapping, synchronization, and correlation

Table of Contents

Create rules to enable midPoint find accounts in the target Active Directory application and match them with accounts it already knows from HRIS.

What awaits you in this module

You are about to create mapping, synchronization, and correlation rules to ensure midPoint can match the accounts it finds in the Active Directory with the accounts it already knows from HRIS. The process is similar to what you have done in link but since the AD is a target application, you need to tailor the settings accordingly; most notably, you will learn to create inbound mapping rules limited only to correlation.

1. Define synchronization rules

Define the synchronization rules for the AD resource. You can safely use the Active lifecycle state even during testing as long as the whole AD resource is proposed.

Follow this guide: Resource wizard: Object type synchronization

Name Situation Reaction Lifecycle state Comments

link-unlinked

Unlinked

Link

Active

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

synchronize-linked

Linked

Synchronize

Active

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

synchronize-deleted

Deleted

Synchronize

Active

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. This is potentially destructive in case of misconfiguration.
Keep in Draft (effectively disabled) for now.

create-correlation-case-for-disputed

Disputed

Create correlation case

Active

In case a candidate owner is not found with 100% certainty, create a correlation case to let a human operator resolve the situation. You will learn more about cases in a bit.

Refer to MidPoint Synchronization Introduction for more details on the topic.

2. Create inbound mappings for correlation

With inbound ("target") resources like the one for the Active Directory application we have here, you face a new challenge when you need to correlate accounts. To successfully correlate accounts, you need inbound mappings for the AD resource, i.e., from the resource to midPoint. But the "regular" inbound mappings are not the best fit because you do not want to actually write the data from the resource to midPoint.

That is why you are going to define a new kind of mappings: inbound mappings limited to correlation purposes. MidPoint will use these mapping rules only to know which resource attribute to correlate with which internal (focus) user attribute.

Follow these guides:

Use inbound mappings and set them to be used for correlation only.

Define these mapping rules:

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.
Correlation-only inbound mappings for the AD resource
Figure 1. Correlation-only inbound mappings for AD. Note the yellow icons left of the rule names signifying the Use for limitation.

3. Define correlation rules

Correlation in midPoint is a mechanism used to identify the owner of a resource object, such as an account. It involves finding the right focal object for 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 this guide, we use the employee numbers as the common identifier. If an AD server entry has the same employee number as a user in midPoint, they are surely a match.

For the cases when this bullet-proof matching fails due to erroneous data, you can set up a fallback correlation rule using an attribute combination, such as first name + surname + locality.

Fallback rules should not have as high confidence because there may be cases when two people of the same name are in the same place, for instance. Lower-confidence correlation rules can be set to create produce correlation cases, meaning they can only suggest which focus should be bound to which shadow, but a human operator needs to confirm the match.

In the suggested setup below, the fallback rule using names and locality has the confidence of only 0.5. That means that even if all the three attributes agree, the match would be only 50% sure and a correlation case would be created.

Follow this guide: Resource wizard: Object type correlation

Define these correlation rules:

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

personalNumber-correlation

Correlation using personalNumber. Does not require human intervention.

1

True

personalNumber : Exact match

last-resort-correlation

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

Next steps

Having all the essential rules in place, you can now continue to reconcile the AD application accounts with what you already have in midPoint.

link

Was this page helpful?
YES NO
Thanks for your feedback