First Steps With MidPoint: Assessment
Last modified 13 Feb 2024 13:08 +01:00
Table of Contents
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 are 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:

  1. 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.

  2. accounts: we should not harm any existing accounts in an unexpected way

  3. passwords: we should not 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:

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:
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:

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:
Make sure you have 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 are 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 should not be there (if we do not 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 have managed to import users from source system with an incorrect archetype, please do the following:

  1. Delete all imported users from midPoint (make sure you do not 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)

  2. Re-configure HR resource to use a correct archetype for user creation.

  3. 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:
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 have (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 do not 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):

  1. Run the simulated reconciliation task on AD resource using Development configuration.

  2. 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 are 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 are 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:

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

    Be careful if your HR system does not 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 are absolutely sure the accounts should be deactivated, you do not need to mark them and leave them to their (later) fate.

  2. 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 are not related to HR data on which midPoint data is based) one by one and make sure these are not system accounts (see the System (service) accounts category).

    Mark the undesired ones as Decommission later to be deactivated eventually (but not yet).

  3. 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.

  4. Accounts unmatched because of data inconsistencies. Review the rest of accounts which have not 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 ("Do not 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 have finished marking of your accounts, you can run the simulated reconciliation task with Development configuration again. Your marked accounts should not be reported to be deactivated anymore. Orphaned accounts which are not 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:

  1. Run the simulated reconciliation task on AD resource using Production configuration.

  2. Then have a look at the simulation results in midPoint GUI (interactively). Orphaned accounts should not 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:

  1. Run the reconciliation task on AD resource.

  2. Check the correlation statistics (watch for Linked situation)

  3. Majority of your accounts should be linked to their midPoint owners.

Of course, you are doing this for the first time. Chances are that you have not 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:

  1. Run the simulated or reconciliation task on AD resource using Development configuration (as the mapping we’re interested in is in Proposed lifecycle state).

  2. 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:

  1. Run the simulated reconciliation task on AD resource using Production configuration.

  2. 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:

  1. Run the reconciliation task on AD resource.

  2. Majority of your midPoint users should be renamed according to their Active Directory usernames.

  3. 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:

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:

  1. re-configure synchronization action for Unmatched situation: set it to Active lifecycle state.

  2. 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 have seen earlier with Development configuration, continue.

  3. run reconciliation task with Active Directory

  4. unmarked orphaned accounts should be deactivated

  5. 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", "Do not 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 are preparing the configuration in iterations, you need to make sure you are 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:

  1. 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.

  2. to allow passing midPoint password changes to Active Directory (if you wish to use midPoint for AD password changes).

  3. 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:

  1. to enable/disable Active Directory accounts based on midPoint user’s Lifecycle state

  2. (optional) configuration for Disable instead of delete, Delayed delete etc. - if needed

  3. 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:

  1. Run the simulated reconciliation task on AD resource using Development configuration.

  2. Then have a look at the simulation results in midPoint GUI (interactively).

  3. 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)

  4. 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)

  5. Repeat the process until all simulated changes make sense and can be executed for real

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

  1. Set all required outbound mappings including the mappings for activation and credentials to Active lifecycle state

  2. Run the simulated reconciliation task on AD resource using Production configuration

  3. Then have a look at the simulation results in midPoint GUI (interactively) one last time.

  4. 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 are already prepared for it.

Simulation notes

  1. 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.

  2. 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.

  3. 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