Navigation Tree

Connect the Source and Target Systems

Last modified 20 Oct 2025 14:30 +02:00

Table of Contents

Provision Accounts to Target Systems
Automate the processes
- Generate Usernames in MidPoint
The old original content follows

Provision Accounts to Target Systems

Create outbound mappings for the target system (module 7, 7:30) i .. simulate first
Activation - veci jako deactivate instead of delete a delayed delete
Credentials - poskytuje hesla do LDAP

At this point, you have the identities in your systems mostly correlated. Up until now, when your HR created, updated, or deactivated a user in the HR information system (HRIS), someone also had to go and do the same to that user in the target LDAP system.

The logical next step now is to automate the process. That means to automatically:

Create account in LDAP based on the data in HRIS.
- Create the first password for the new user in LDAP.
Update accounts in LDAP according to changes that happen in HRIS.
Suspend and possibly delete accounts for users suspended in or deleted from HRIS.

There are several tools in midPoint you are going to use for these tasks: outbound activation, outbound credentials, and outbound mappings. When you are done with this setup, it is no longer necessary to manually update user accounts in the target system: you do the change once in the authoritative HR system and midPoint propagates it automatically to all configured target systems.

Create outbound mapping rules for LDAP

Firstly, to enable provisioning to the LDAP target system, you need outbound mapping rules. Outbound mapping rules work the same as inbound mappings, they merely map the data the other way round: from midPoint to the target system.

Refer to this guide on creating mapping rules: Resource Wizard: Object Type Mappings
Use outbound mappings because you’re pushing attributes to the resource from midPoint.
The list of rules below is for illustration purposes. The actual attributes you need to map depend on your target system.

Table 1. LDAP outbound mapping rules
Name	Source	Expression	Target	Lifecycle state	Comments
name-fullName-to-dn	`name`, `fullName`	Script	`dn`	Proposed	Create a distinguished name out of name and full name using a script. Find the script to use beneath the table.
name-fullName-to-cn-weak	`name`, `fullName`	Script	`cn`	Proposed	Create LDAP common name out of name and full name. Use a weak mapping strength to avoid overwriting existing values. See how to set a mapping strength. Find the script to use beneath the table.
fullName-to-displayName	`fullName`	As is	`displayName`	Proposed
givenName-to-givenName	`givenName`	As is	`givenName`	Proposed
familyName-to-sn	`familyName`	As is	`sn`	Proposed	Copy family name to surname.
name-to-uid	`name`	As is	`uid`	Proposed	User identifier based on `name`.
locality-to-l	`locality`	As is	`l`	Proposed
personalNumber-to-employeeNubmber	`personalNumber`	As is	`employeeNumber`	Proposed

name-fullName-to-dn script

def cn
if (iteration == 0) {
    cn = fullName
} else {
    cn = fullName + ' (' + name + ')'
}
return basic.composeDnWithSuffix('cn', cn,
    'ou=users,' + basic.getResourceIcfConfigurationPropertyValue(resource, 'baseContext')
)

name-fullName-to-cn-weak script

def cn
if (iteration == 0) {
    cn = fullName
} else {
    cn = fullName + ' (' + name + ')'
}
return cn

If you are "faking" the LDAP resource using a CSV file loaded via the CSV connector, you need to use the following script for the DN construction instead. This is because the built-in getResourceIcfConfigurationPropertyValue method works for LDAP resources, but not for CSV resources.

name-fullName-to-dn script (CSV version)

def cn
def fn
if (iteration == 0) {
    fn = fullName
} else {
    fn = fullName + ' (' + name + ')'
}
cn = 'cn=' + fn + ',ou=users,dc=example,dc=com'
return cn

Activate users in the target system

Activation in midPoint is the state of an object, such as user, account, or entitlement. Activation is based on several properties, namely administrative status, valid from, valid to, and lifecycle status. Based on the values of these object attributes, midPoint computes an effective status.

We can use effective status in outbound activation mapping to activate or deactivate accounts on resources, such as an LDAP system.

Refer to Activation for the full documentation activation.

Refer to instructions on working with activation in the midPoint GUI.

In total, create three activation outbound mappings:

Administrative status
- Lifecycle state: Proposed
- Name: account-status-based-on-mp-user, for example.
- Strength: Strong
- You can leave Source empty because midPoint already knows the default source for this mapping (effective status).
- The activation mapping controls the account status in the target system based on the effective status of the respective focal object in midPoint.
Disable instead of delete
- Lifecycle state: Proposed
- This ensures that illegal accounts don’t get deleted but rather disabled. It’s best to use this in conjunction with the Delayed delete configuration.
Delayed delete
- Lifecycle state: Proposed
- Set Delete after to a value appropriate to your use case.
- Accounts marked for deletion will deleted no sooner than after the grace period set here elapses.
  - For testing, sensible values are in minutes.
  - For production, sensible values are likely weeks or months.

Outbound activation mappings for a target resource

activation explanation: explanatory video, module 7, 5:30

Create initial passwords in the target system

When you provision accounts to target systems, you need to take care of users' initial passwords. There may be at least two reasons:

Some systems refuse to create a user with a blank password.
Without a password, the new user would either be unable to log in at all, or the system would let them in without a password. Neither of which is likely a behavior you want.

That means midPoint needs to supply an initial password for new accounts. It’s up to the app using the target system to require a password change upon the first login.

Moreover, you may let your users change their password directly in midPoint. In such a case, you need to tell midPoint to propagate the changed password to the target system.

Refer to instructions on working with credentials in the midPoint GUI.

For the purposes of the setup we’re building in this guide, you are going to use two outbound mappings for credentials:

Generate an initial password for new accounts.
- Lifecycle state: Proposed
- Name: initial-passwd-generate, for example.
- Stregth: Weak
- Expression: Generate
- This mapping needs to be weak so that it doesn’t overwrite any existing password.
  Weak mapping is used only when the target attribute has no value.
Copy password from midPoint to the resource in case a user changes the password in midPoint.
- Lifecycle state: Proposed
- Name: passwd-change, for example.
- Stregth: Normal
- Expression: As is
- If your users are not expected to ever use midPoint to change their passwords, you don’t need this mapping.

Refer to these resources for more information on credentials:

explanation: explanatory video, module 7, 10:47

Simulate provisioning

As always, before you put the new settings to production, simulate first to see if you get expected results. If you followed this Methodology from the start, you already have a task for a simulated reconciliation ready. If not, create it according to the linked guidance.

After you run the simulated reconciliation, check the simulation results. You may see some accounts are renamed on either side as midPoint is trying to fix the data and make them consistent.

If some results are not as expected, adjust the resource configurations as needed. You can run the simulation over and over again safely, it doesn’t touch your data.

Put the LDAP Provisioning into Production

Having inspected and verified the results of the simulation, it is turn them into reality.

For that to happen, you need to move all the mappings (the "regular" ones, as well as those for activation, and credentials) from the Proposed lifecycle state to Active.

After that, run the production reconciliation task in the LDAP resource.

You have turned on configuration for provisioning to the target LDAP resource for all attributes, as well as activation and passwords. You don’t have yet set up an automatic synchronization between the source and target resources, that is, the HR and LDAP. However, your configuration is almost ready for that and we’ll get to that very soon.

explanation in explanatory video, module 7: 18:16

Automate the processes

After the steps you’ve done up to now, your LDAP and HR data can be considered reasonably clean and in sync. With that, you can move on to automating the setup so that it works autonomously:

Periodically check the HR system and import new accounts, if any.
Regularly check the LDAP system and clean up (delete) any illicit accounts.
Provision LDAP accounts for new employees imported from HR.
Create passwords for new HR accounts when provisioned to LDAP.

Generate Usernames in MidPoint

Up until now, we’ve used the employee number from the HR system and the UID attribute from the LDAP system for user names.

Now, it’s time to configure midPoint to let it create usernames on its own so that it can provide LDAP accounts to new users created in in the HR system. That’s because if a new person joins the organization, they don’t have an LDAP account, meaning there’s nowhere to take their username from.

For midPoint to be an authoritative source of new usernames, you need to take a couple of steps:

Disable the HR inbound mapping empnum-to-name which takes the empnum attribute and uses it for the focus name attribute.
Disable the LDAP inbound mapping inbound-uid-username-to-name which takes the uid attribute and uses it for the focus name attribute.
Activate the Person object template that can generate usernames based on the focal object name and surname.

Disable the obsolete inbound mappings for name

For the HR resource:
1. In the HR resource, go to mapping configuration.
2. In Inbound mappings, set the empnum-to-name mapping to the Archived lifecycle state
3. Save the configuration.
For the LDAP resource:
1. In the LDAP resource, go to mapping configuration.
2. In Inbound mappings, set the inbound-uid-username-to-name mapping to the Archived lifecycle state
3. Save the configuration.

Activate the Person object template mapping for usernames

enable mapping in object template
object template in MP is an object that allows running mappings whenever a focal object based on the template is created (e.g., user)
can be either global (for specific focus type, e.g., user), or archetype-specific (e.g., for Person)
there’s a built-in object template for the Person archetype in MP - contains 2 default mappings - generate-fullname and generate-name-jsmith-8-2 (with iterator)
this Person object template is tied to the Person archetype which is used for everybody we import from the HR system.
various users can have various archetypes which can induce different behavior
the username generator jsmith is weak so it only generates the value when the attribute is empty and doesn’t change it when the person changes their name (e.g., when married)
object template mappings work only with focal objects, they have focal object attributes on both sides
if you want to enforce the values, make the mappings strong (e.g., full name)
disable HR inbound mapping for name
disable LDAP inbound mapping for name - LDAP is no more the source system for us
to automate sync with HR, we need a reconciliation task that is set to run repeatedly in given intervals (minutes, hours, … can also be cron-ed); otherwise the task is the same
to automate LDAP account creation, we need to make MP create them
important to understand concepts of assignment and inducements:
assignment is a policy, a decision that an object (e.g., user) should have something (e.g., a role)
inducement is an indirect assignment - object (inducement) assigned to a user causes the user to have something (e.g. a role or account)
rule of thumb: users have assignments (roles, orgs, services, accounts, archetypes, ..); roles, orgs, services, accounts, archetypes have inducements - they cause something to happen to users who have them assigned (access rights, accounts, …)
archetype can be considered a birth right and we’ll add LDAP provisioning to the Person archetype - resource account construction inducement in the Person archetype
video: module 8: 22:45
video 25:10 - mappings in the archetype which we won’t use, but may be worth mentioning?
Entitlements and associations
accounts are resource objects representing resource accounts
entitlement - resource object representing resource privelage, e.g., AD group
entitlements can be associated with accounts =⇒ membership
provisioning manages entitlements, i.e., provisioning translates association into account—entitlement relation
entitlements are resource objects like accounts with their own kind and intent
associations are configured in resource account object type (can be predefined in object template)
two possible ways for associations (28:58):
roles are pointing to users (objectToSubject)
users pointing to roles (subjectToObject)
midPoint doesn’t store role memberships, it fetches the info on demand - searches all the groups for a user DN, for example.
Q: does that apply to 4.9+ as well? (with all the caching and such)
lifecycle states:
long-term leaves - account is suspended in MP → disabled in LDAP
former employees - account is archived in MP → deleted in LDAP — but with disabled instead of delete + delayed delete

how delayed delete works - MP creates a trigger when the account is supposed to be deleted, is stored in account shadow - MP recalculates the account and deletes - trigger scanner scans timestamps and triggers the actions (usually runs in 5 minutes intervals ??? - what if the delay is only 2 minutes?)

assignments and inducements enforce policies - if an object (e.g., user) should have something, e.g., a role, MP ensures that; creates the resource account and populates it with the right data, manages attributes of groups etc.
strong mappings ensure that MP enforces the correct values even if someone changes them in the target system - MP is authoritative
during the migration to MP, MP can be set to tolerate group membership changes by external (legacy) systems; after the migration is done, MP can be set as intolerant
when you turn on the automatic provisioning to AD via MP, don’t forget to turn off provisioning to LDAP via legacy systems
validity check scanner - runs each 15 minutes and checks validFrom and validTo to compute effective state (not used in this training)
shadow refresh task (basically simplified reconciliation) - if MP has some changes cached in shadow objects which it couldn’t have pushed previously to resource because it was down, for example, shadow refresh task triggers maintenance operations to push these changes to resource; also cleans up dead shadows after their retention period (by default 7 days)
dead shadow: when account is deleted on target system but shadow exists in MP. All the associations still exist, account can be recreated based on the dead shadow.

username generator logic explained in module 8 training video on 0:10:00

The old original content follows

Goal

Asses the real data quality, determine practical next steps. At this point we know what we really have, what we can build on, what needs to be improved. We can identify the most severe security risks, such as orphaned accounts. Now we can improve our plan, adding more details based on the real data.

You have some kind of HR data now. In theory, you should use the HR data to create and manage accounts in target system, such as your Active Directory. However, in practice, this is not entirely straightforward.

Firstly, it is almost certain that there are errors and inaccuracies in the HR data. The data were maintained manually for a long time, with no way for automatic validation. Mistakes in the data might be buried deep, surviving undetected for decades. Having nothing to compare the data with, there is no telling how good or bad the data are.

Secondly, the data in your target systems (especially Active Directory) certainly leave a lot to be desired. These were managed manually for years, with no automatic way to make sure they’re correct. There will be account belonging to people that left your organizations years ago. There will be accounts using maiden names of women that are married now. There will be strange accounts and identifiers that originated ages ago when your organization was still small and system administration was fun. There may be all kinds of weirdness and historical baggage frozen in time because nobody remembers what it does and everybody is scared to touch it.

In general, when deploying identity management system to an existing environment, we need to take extra care of the following:

usernames: midPoint usernames should be the same as for the principal authentication system. In this methodology, we assume that company’s Active Directory or LDAP which will be connected as the first target system is used as the source of usernames.
accounts: we shouldn’t harm any existing accounts in an unexpected way
passwords: we shouldn’t alter (e.g. re-generate) any existing account password

Taking HR data and simply forcing them to Active Directory will never work. We need much smarter approach.

This is what you have to do:

Connect HR System

Connect HR data source to midPoint. Set up your HR identity resource in midPoint, using CSV or DatabaseTable connector.

Please refer to the following documentation:

Resource Wizards

You can see this step in action in the First Steps Methodology webinar video:

Step 2: Connect Source System (HR)

Deal with just the very basic data items for now:

Names (given name, family name)
Employee number, student number or similar identifier
Status (active, former employee, alumni, etc.) and/or validity date/time (based on contract etc.)

You can ignore other fields for now. We can get back to them later.

The resource is created in Proposed lifecycle status by default. Keep it that way at this stage.

We recommend to use resource capabilities to disable Create, Update and Delete operations on the resource.

Create a new object type for HR accounts to allow creation of users in midPoint with Person archetype assigned.

Please refer to the following documentation:

Resource wizard - part Object type configuration

Make sure you select the proper archetype before importing the users. Change of archetype is not supposed to be a straightforward process as archetypes are expected to work as object classes in the future.

Preview your HR records which will be imported to see if you want to import all of them, or you want to import only a subset of them using a classification filter (e.g. if you want to ignore non-IT personnel). While the resource is in Proposed lifecycle state, you can redefine classification filters and reclassify your HR accounts as many times as you wish.

Import Users From HR To MidPoint

Import users to midPoint, using HR data. For simplicity, use HR person identifier (e.g. employee number) as the midPoint username. We will import the usernames from AD/LDAP later.

Please refer to the following documentation:

Resource wizard - part Wizard for task creation

You can see this step in action in the First Steps Methodology webinar video:

Step 3: Import from HR

Start with importing a single HR account with preview option to see how the user would be created in midPoint. Then you can simulate the import of all HR accounts using a simulated import task running with Development configuration to see how all the users would be created in midPoint.

You can continually improve your imported data by adding more attribute mappings.

When finished, switch the HR resource to Active lifecycle state.

Please refer to the following documentation:

Resource wizard - part How to use lifecycle state

Make sure you’ve selected the proper archetype for users before importing them. Change of archetype is not supposed to be a straightforward process as archetypes are expected to work as object classes in the future.

Now you can import the HR data, creating user objects in midPoint. As we’re working with simple data for now, the import should go well.

User lifecycle

This is where user lifecycle management starts.

We need at least some basic framework for user lifecycle management at this point.

If we can identify inactive (former) HR persons, we can utilize this information when checking for accounts in target systems that shouldn’t be there (if we don’t import inactive users from HR, we will see their accounts in target systems as simply orphaned).

Instead of setting user’s administrativeStatus, we recommend to set midPoint user’s lifecycleState property based on HR data as either:

active
suspended (e.g. temporarily inactive employees - parental leave, long-term sickness etc.)
archived (e.g. former employees)

If you have imported users with incorrect archetype

If you’ve managed to import users from source system with an incorrect archetype, please do the following:

Delete all imported users from midPoint (make sure you don’t delete administrator user)
1. midPoint will attempt to delete the source accounts in HR as well, if you have disabled Create, Update and Delete operations in resource capabilities, errors will be displayed (this is expected)
Re-configure HR resource to use a correct archetype for user creation.
Re-run the import task from HR resource.

Connect Active Directory

Set up your Active Directory (or LDAP) identity resource in midPoint and keep it in Proposed lifecycle state. Create Object type definition for AD accounts and keep it in Proposed lifecycle state as well.

Please refer to the following documentation:

Resource Wizards

You can see this step in action in Step 4: Connect Target System in the First Steps Methodology Webinar video.

You can see this step in action in the First Steps Methodology webinar video:

Step 4: Connect Target System

Set up outbound mappings for the small data set that you’ve (given name, username and so on) and keep them in Draft lifecycle state (effectively disabled).

Configure correlation rules for AD accounts.

Configure synchronization configuration in Proposed lifecycle state.

We don’t want to change any data in Active Directory yet.

Please refer to the following documentation:

Resource templates

Resource templates can be prepared in advance.

Creating a new resource based on resource template instead of creating it from scratch can save your time as the basic configuration would be pre-defined, and you can enable/update it as necessary.

Please refer to our Active Directory resource sample for more information. This sample was tested with our First Steps Methodology.

Correlate Active Directory Accounts

Correlate Active Directory accounts with midPoint users. If you have employee numbers (or similar unique attributes from HR) stored in your Active Directory, then use that for correlation. As an alternative if no such data can be used or if data is unreliable, you may want to use several attributes for approximate correlation such as names, locality, department etc. Manual confirmation using midPoint correlation cases can be used to specify midPoint user who should own the Active Directory account if the match is ambiguous.

Please refer to the following documentation:

You can see this step in action in the First Steps Methodology webinar video:

Step 5: Target System Integration

After configuring correlation and synchronization (while the resource, object type and synchronization configuration is in Proposed lifecycle state):

Run the simulated reconciliation task on AD resource using Development configuration.
Then have a look at the task and simulation results in midPoint GUI (interactively).

If you maintained your identifier assignment conventions reasonably well, most identities should correlate well. MidPoint will show you correlation statistics for your accounts.

Of course, if the correlation is not able to use the personal/employee numbers, just users' names, there will be problems of John Smith and Josh Smith with their jsmith and jsmith42 accounts. Let’s leave that for later. For now just focus on correlating the bulk of users.

If you get 80-90% users to correlate well, you’re done here.

There will be also orphaned accounts (Unmatched synchronization situation). Based on your resource configuration, midPoint may report they will be deactivated (but we’re still in Proposed lifecycle state - just simulating).

We will analyze the accounts here, but we will take final decision later in Clean Up The Accounts to not stop us from progressing.

You can analyze/clean up the data in several iterations.

The orphaned accounts generally fall into the following categories:

Obviously orphaned accounts: Review the list of orphaned accounts (the accounts in Active Directory not having an owner in midPoint which should mean they aren’t related to HR data on which midPoint data is based) one by one and make sure these aren’t_ system accounts (see the System (service) accounts category).

Be careful if your HR system doesn’t contain/export former employees data; in such situation you will not have the former employees in midPoint as users and their Active Directory accounts will be also considered orphaned.

If you’re absolutely sure the accounts should be deactivated, you don’t need to mark them and leave them to their (later) fate.
Orphaned accounts of unclear origin: Review the list of orphaned accounts (the accounts in Active Directory not having an owner in midPoint which should mean they aren’t related to HR data on which midPoint data is based) one by one and make sure these aren’t_ system accounts (see the System (service) accounts category).

Mark the undesired ones as Decommission later to be deactivated eventually (but not yet).
System (service) accounts: For all accounts that are crucial for Active Directory, we need a different decision.

Mark the system accounts as Protected in midPoint to keep track of them, but ignore them otherwise by midPoint.
Accounts unmatched because of data inconsistencies. Review the rest of accounts which haven’t been matched or decided in the previous steps. This is the time to take care of the Smiths, Johnsons and Browns if no reasonably unique attribute could have been used for their correlation. If possible, update your correlation configuration to use more attributes to find matching users (e.g. Given name, Family name, Location, …).

You can also try to figure out which account belongs to which user and correlate them manually.

Or you can mark specific accounts as "Correlate later" to ignore them now and resolve them in later iteration.

If you did the previous steps well, there should be just a handful of them.

Sometimes there are several accounts (or groups of accounts) which need to be reviewed in more detail and remedied. To avoid getting stuck in this phase, you may simply mark these accounts for later review ("Don’t touch") and ignore any provisioning for them fow now. (This is actually similar to the concepts of protected accounts, but having a different mark allows us to differentiate the accounts. We want them marked only temporarily, and they will be reported.)

We recommend to review the accounts marked in previous iterations to avoid a constant increase of their numbers.

After you’ve finished marking of your accounts, you can run the simulated reconciliation task with Development configuration again. Your marked accounts shouldn’t be reported to be deactivated anymore. Orphaned accounts which aren’t marked should be still reported as to be deactivated.

Switch the resource, object type configuration and all synchronization actions except for Unmatched situation to Active lifecycle state. Switch the synchronization action for Unmatched situation to Draft lifecycle state (to keep the reaction temporarily disabled), and:

Run the simulated reconciliation task on AD resource using Production configuration.
Then have a look at the simulation results in midPoint GUI (interactively). Orphaned accounts shouldn’t be touched anymore - we will resolve them later, the synchronization configuration for them won’t be used now (just in simulations).

Correlate the majority of your accounts now:

Run the reconciliation task on AD resource.
Check the correlation statistics (watch for Linked situation)
Majority of your accounts should be linked to their midPoint owners.

Of course, you’re doing this for the first time. Chances are that you haven’t got all your configuration exactly right at the first try. You may even need to update your HR resource configuration (e.g. if you forgot to import employee number) and reimport HR data. Therefore, we assume you will work in iterations. Simulations will guide you all the way.

Import Active Directory usernames

Until now, users in midPoint have been created with employee number (or similar) attribute from HR. But your users already have Active Directory usernames. We can reuse them also for midPoint users - the advantage will be more obvious later, if we switch the midPoint authentication mechanism to use Active Directory.

Please refer to the following documentation:

You can see this step in action in the First Steps Methodology webinar video:

Step 6: Import Usernames from Target System

Re-configure the original HR inbound mapping for midPoint username: set its strength to weak. This allows to still create midPoint users who have no Active Directory account, but AD username will have higher priority.

Re-configure your Active Directory resource: add a new inbound mapping from AD’s login attribute to midPoint username. The mapping will be created as strong by default, to take precedence over HR, but keep the mapping lifecycle state Proposed (simulation) for now.

Simulate the username import:

Run the simulated or reconciliation task on AD resource using Development configuration (as the mapping we’re interested in is in Proposed lifecycle state).
Then have a look at the simulation results in midPoint GUI (interactively).

For all users with Active Directory account, midPoint will indicate username change. Inspect the changes and fix the username mapping in Active Directory if needed.

Re-configure your Active Directory inbound mapping: set it to Active lifecycle state.

Optional step:

Simulate the username import once again:

Run the simulated reconciliation task on AD resource using Production configuration.
Then have a look at the simulation results in midPoint GUI (interactively).

Inspect the changes and fix the username mapping in Active Directory if needed, before you turn import them for real.

Import the usernames now:

Run the reconciliation task on AD resource.
Majority of your midPoint users should be renamed according to their Active Directory usernames.
Users without accounts in Active Directory (e.g. still uncorrelated) will keep their original usernames from HR (based on e.g. employee number). Such users (without Active Directory accounts) can be easily found in midPoint using GUI.

Clean Up The Accounts

After the majority of the accounts have been correlated and usernames imported, we can handle the orphaned accounts (in situation Unmatched). You have already marked your accounts (and intentionally not marked some of them).

Please refer to the following documentation:

Resource wizard - part Synchronization

You can see this step in action in the First Steps Methodology webinar video:

Step 6.1: Clean Up Orphaned Accounts

You are ready for clean up procedure:

re-configure synchronization action for Unmatched situation: set it to Active lifecycle state.
run reconciliation task with Active Directory with Production configuration to see what would happen one last time. If the simulation results correspond to what you’ve seen earlier with Development configuration, continue.
run reconciliation task with Active Directory
unmarked orphaned accounts should be deactivated
additionally, the policy for orphaned accounts is set from now on, but the marked accounts will not be harmed.

During the clean up part (now or in one of the later iterations), you should check if there are any uncorrelatable accounts that can be correlated using additional correlation rules and/or operator intervention.

You can see this step in action in the First Steps Methodology webinar video:

Step 6.2: Correlation with Operator Confirmation

You should periodically review your marked accounts, especially those "temporary" states such as "To be decommissioned", "Don’t update" and "Correlate later".

You should also periodically run reconciliation task with your Active Directory to detect and deactivate any future orphaned accounts. Unmarking those accounts and running reconciliation task with Active Directory will remove them.

This phase may seem as pointless phase. Why not just go directly to automation? That is what we really want! However, assessment is all but pointless. Automation can be done only after the assessment phase is done. Attempts to automate processes with unreliable data are futile, they invariably lead to failures, usually a very expensive failures. Speaking from a couple of decades of identity management experience, there is no such thing as reliable data, unless the data are cleaned up and systematically maintained with an assistance of identity management platform. Simply speaking: you may think that your data is good, but it is not.

Prepare Active Directory for Provisioning

Before turning on automation, we need to ensure the provisioning configuration for Active Directory resource is correct. Especially if you’re preparing the configuration in iterations, you need to make sure you’re going right direction. Simulations will guide you all the way.

Please refer to the following documentation:

You can see this step in action in the First Steps Methodology webinar video:

Step 7: Enable Provisioning to Target System

Prepare / update outbound attribute mappings for your Active Directory attributes that you wish to provision. If you want to force midPoint policy for attributes, you would need to make your mappings strong (this is default if you use GUI to create the mappings). Set your mappings' lifecycle state attributes to Proposed to allow simulations.

Prepare / update outbound password mapping(s) for your Active Directory:

to generate initial (strength: weak) random password for any new Active Directory account from now on. The password will be forgotten; users need to cooperate with AD administrators or Helpdesk to gain their first credentials.
to allow passing midPoint password changes to Active Directory (if you wish to use midPoint for AD password changes).
set your credentials mappings' lifecycle state to Proposed to allow simulations.

Passwords may be also changed via Active Directory as usual (or both).

Prepare / update outbound activation mapping(s) for your Active Directory:

to enable/disable Active Directory accounts based on midPoint user’s Lifecycle state
(optional) configuration for Disable instead of delete, Delayed delete etc. - if needed
set your activation mappings(s') lifecycle state to Proposed to allow simulations.

midPoint authentication against Active Directory (or LDAP) is assumed for later steps.

Then you can start your simulations:

Run the simulated reconciliation task on AD resource using Development configuration.
Then have a look at the simulation results in midPoint GUI (interactively).
Inspect the results: if midPoint would change existing attributes, states or even passwords in Active Directory or add new values, there should be a reason for, e.g.: policy vs data inconsistency, such as:
1. Active Directory attributes are incorrect/missing, midPoint attributes based on HR data are correct.
2. Active Directory attributes are correct, midPoint attributes based on HR data are incorrect
3. mappings have errors (you need to correct them)
Fix data vs policy inconsistency by using one or several mechanisms:
1. let midPoint to override data in Active Directory
2. fix data in HR/midPoint and reimport the user(s)
3. adjust midPoint policies (e.g. outbound attribute mappings)
4. define exceptions for specific accounts (e.g. using marks)
5. escalate the situation to let someone help (or decide)
Repeat the process until all simulated changes make sense and can be executed for real

When all the inconsistencies are resolved, you’re prepared. You can turn on the provisioning:

Set all required outbound mappings including the mappings for activation and credentials to Active lifecycle state
Run the simulated reconciliation task on AD resource using Production configuration
Then have a look at the simulation results in midPoint GUI (interactively) one last time.
Run the reconciliation task on AD resource

Your Active Directory resource is now configured. Data inconsistency has been fixed. Policy is defined, applied and will be followed from now on. There is no automation between HR and midPoint yet, but we’re already prepared for it.

Simulation notes

When switching from Proposed to Active lifecycle state, use also simulation with Production configuration before using the feature in real execution, if possible (usually when the real execution task is not yet running) - this is as close to the real task execution as possible.
When switching the configuration from Proposed to Active lifecycle state, be sure to switch all relevant configuration. Otherwise, you might see different behaviour when simulating with Development configuration and Production configuration / real task execution.
Try not to simulate several unrelated scenarios at the same time, otherwise switching just parts of the configuration from Proposed to Active lifecycle state may be challenging. You might see different behaviour when simulating with Development configuration and Production configuration / real task execution.

You can continue to Automation step or return to Kick-off step.

Was this page helpful?

YES NO

Thanks for your feedback