Navigation Tree

Reconcile the LDAP accounts

Last modified 21 Oct 2025 14:28 +02:00

Table of Contents

Simulate LDAP reconciliation
Mark unmatched accounts to prevent deletion
Check the simulated results using filters in the account list
Reconcile your LDAP accounts
Resolve correlation cases

Simulate LDAP reconciliation

To test your configuration, run a simulated reconciliation task on the development environment.

Use this guide for instructions on creating tasks.

In your LDAP target resource, create a Reconciliation Task.
Switch on the simulation toggle to first preview the changes and prevent any harm to your data.
Name the task, e.g., Reconciliation with LDAP - development simulation.
On the Execution screen, select the preview mode with development configuration.
After you configure and create the simulated reconciliation task, run it and inspect the simulation results to see how your mapping and synchronization rules work.

When reviewing the simulation results in Operational statistics, you should get a result similar to the examples below.

The content of the table depends on the data in your systems as well as your actual configuration and marks applied. When you run the reconciliation for the first time on the resource, the original state is always No record.

The numbers you will see in the table depend on your actual data. In general, you should see most accounts linked at the synchronization end, some of them possibly disputed and unmatched, as below.

Table 1. Synchronization situation transitions
Original state	Synchronization start	Synchronization end	Exclusion reason	Succeeded	Failed	Skipped	Total
No record	Unlinked	Linked		47	0	0	47
No record	Disputed	Disputed		3	0	0	5
No record	Unmatched	Unmatched		5	0	0	7

Should you run the task again without changing anything, the original state will match the synchronization start from the previous reconciliation. This only means that midPoint already knows about the accounts, so their original state is not no record. The numbers stay the same, though.

Table 2. Synchronization situation transitions
Original state	Synchronization start	Synchronization end	Exclusion reason	Succeeded	Failed	Skipped	Total
Unlinked	Unlinked	Linked		47	0	0	47
Disputed	Disputed	Disputed		3	0	0	3
Unmatched	Unmatched	Unmatched		5	0	0	5

The numbers in the above examples say the following:

48 accounts that were found on the resource are unlinked and would be linked.
2 accounts that were found cannot be correlated reliably (the empnum did not match, but the first name, surname, and locality did), so they are disputed and correlation case would be created.
4 accounts that were found would stay unmatched because no focus object was found for them. According to the synchronization rules we set before, these accounts would be deleted from the LDAP resource.

The correlation was simulated so none of the synchronization end situations actually happened.

Mark unmatched accounts to prevent deletion

In case your target LDAP resource contains accounts that cannot be correlated with the focal objects you have in midPoint from the source HR system, you can mark some of them to protect them from being prematurely deleted. This is useful if you are not sure about the exact purpose of some service accounts, for example, or need to further investigate as to why an account can’t be correlated.

Refer to Object Marks and marking object in GUI for details on using object marks.

Here’s the marking strategy you can use:

If you know a certain account is valid and present in HR but cannot be correlated due to some error in data, mark it as Correlate later.
If you need to preserve an account that is not in HR, such as service accounts, protect it using the Protected mark.
If you are not sure why an account unknown to HR exists, mark it as Do not touch so that it does not get deleted and you can investigate and decide their fate later.
If you discover LDAP accounts that should not be there at all, like legacy or obviously malicious accounts, don’t mark them anyhow. They will get deleted as per the synchronization rules.

Be careful if your HR system does not contain or export former employees data your target system has data on. In such situation, you would not have the former employees in midPoint and their AD/LDAP accounts would appear as orphaned.

The point here is that you can move on with your deployment even if there are inconsistencies and unknowns in your data.

Mark these points of data and leave them for later as per the iterative approach. This way you get tangible results soon without having to wait for a solution to every obstacle.

Now, if you run the simulated correlation task again, you’d see a new entry in the operational statistics of the task telling you how many accounts there are with No record and what’s their Exclusion reason (you marked them to avoid their deletion). The one remaining Unmatched account is the hacker account that needs to be deleted as soon as possible.

Table 3. Synchronization situation transitions
Original state	Synchronization start	Synchronization end	Exclusion reason	Succeeded	Failed	Skipped	Total
Unlinked	Unlinked	Linked		47	0	0	47
Disputed	Disputed	Disputed		3	0	0	3
Unmatched	No record	No record	Protected	0	0	4	4
Unmatched	Unmatched	Unmatched		1	0	0	1

Check the simulated results using filters in the account list

Aside viewing the task simulation results, you can use another way to confirm your setup behaves as expect. You can view the LDAP accounts and their Situations. Even when you simulate reconciliation, the situations of the resource accounts reflect the results of the simulation, i.e., midPoint knows which accounts would be matched, disputed, etc., and updates the account situations accordingly.

Under the LDAP resource, go to Accounts.
Use the Situation filter above the account list to see accounts in various states:
- Select Unlinked to see accounts that would be linked, i.e., their respective focal object (owner) can be determined automatically under the current configuration.
- Select Unmatched to see accounts that can’t be matched to their respective focal objects.
  Some of them are marked by you as protected or for later correlation. Unmatched accounts that are not marked will be deleted if you have the synchronization rule for that (action Delete resource object for the Unmatched situation)
- Select Disputed to see accounts that can’t be matched with 100% certainty to their respective focal objects.
  You’ll get a correlation case to resolve these after you run real production correlation task.
  In the sample data used in this guide, the disputed account would be Anna Lopez who has a wrong empnum in HRIS and has to be correlated using givenName, familyName, and locality as such.
Click Basic to confirm the selected search criterion.

In the list, if you see, for example, accounts that are unmatched and not marked but you are not sure whether it’s safe to have them deleted, mark them now. You can investigate later.

Figure 1. List filtered to show only disputed LDAP resource accounts

Reconcile your LDAP accounts

Once you confirm that your LDAP configuration works as expected and no accounts you need to preserve are about to be deleted, you can run the real reconciliation between HRIS and LDAP.

Firstly, switch all the configurations under your LDAP resource to Active with the exception of delete-unmatched-resource-object. Keep that one in Draft until you learn how to disable accounts instead of deleting them.

Use the Check detailed lifecycle button in the top menu within the resource to view a list of individual resource components and their current lifecycle states.

Then, do the one last simulation, this time on production configuration:

Create a new reconciliation task for the LDAP resource.
Switch on the simulation toggle to first preview the changes and prevent any harm to your data.
Name the task, e.g., Reconciliation with LDAP - production simulation.
On the Execution screen, select the preview mode with production configuration.
After you configure and create the simulated reconciliation task, run it and inspect the simulation results to see how your mapping and synchronization rules work.

The operational statistics numbers should be the same as when you ran the task in the simulated development configuration.

At last, if everything in the results shows as expected, create yet another reconciliation task―this time with the simulation toggle switched off―and run the reconciliation for real.

The expected result of running the reconciliation on production is that:

MidPoint creates correlation cases for accounts it cannot reconcile with 100% certainty (e.g., when empnum differs in HRIS and LDAP).
All accounts that match "cleanly" between HRIS and LDAP are linked and their focal objects have two projections now.
The accounts you need to get rid of (e.g., the hacker account in our data) are not yet deleted from the LDAP system because the synchronization rule is in Draft state still.

Resolve correlation cases

If any of the LDAP accounts fail to reconcile with 100% certainty and midPoint falls back to the last-resort-correlation correlation rule, the production correlation task (as per the synchronization rules) creates a correlation case for a human operator to resolve.

A correlation case is the way for you to efficiently find an owner for disputed accounts particularly thanks to the suggested supposed owners you can select from.

You can find all active correlation cases under Cases.

If you use the sample CSV data provided in this guide, you would see this list of correlation cases:

Table 4. List of correlation cases in midPoint. *CSV LDAP simulation* is the LDAP resource simulated by using the CSV file provided in this guide.
Name	Description	Object	Actors	Opened	Closed	Outcome	State	Workitems
Correlation of account 'geena' on CSV LDAP simulation		CSV LDAP simulation	midPoint Administrator (administrator)				open	1
Correlation of account 'bcarpenter' on CSV LDAP simulation		CSV LDAP simulation	midPoint Administrator (administrator)				open	1
Correlation of account 'alopez' on CSV LDAP simulation		CSV LDAP simulation	midPoint Administrator (administrator)				open	1

When you click a case to open it for an inspection:

Basic shows details about the particular case.
Correlation lets you know how closely the resource object shadow and its suggested focal object matches.
Workitems is the workbench to resolve the correlation case.

Check the suggested resource object shadow owners on the Workitems screen. If any of them is the right one, click the the Correlate button in the particular candidate column. In case no suitable owner exists in the database, there is also an option to Create new focal object in midPoint. That’s not, however, recommended for cases with an authoritative 3rd-party system like the HR system herein.

ldap hris correlation case workitem resolution

Figure 2. Workitems screen in the correlation section of midPoint, showing a suggested resource object shadow owner candidate

If you’re using our sample data to follow this guide, you have one correlation case to resolve after the production reconciliation task finishes, and that’s Anna Lopez who has a wrong empnum in the HR system.

Now that you have LDAP data reconciled with your HRIS data, you can move forth to Import usernames from LDAP.

Was this page helpful?

YES NO

Thanks for your feedback