Methodology: First Steps With MidPoint: Automation
Last modified 22 Jan 2024 11:00 +01:00
Table of Contents
Goal
Make on-boarding and off-boarding processes more efficient and reliable. Save some money and improve efficiency by speeding up the processes. However, the most important goal is enabled by reliability of the automated processes. Accounts belonging to off-boarded people are automatically disabled. Orphaned accounts are reliably detected. The most severe identity-related risks are addressed.

Finally, we have reliable data to build on. What are we waiting for?

User lifecycle
We have user lifecycle figured, and partially implemented/pre-configured at this step. The lifecycle management starts with HR import. But this is the point where it has to work well.

Username Generation

We have previously imported all existing Active Directory usernames which became midPoint usernames. Now it’s time to prepare automation for this step.

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

Step 8: Automate Integration

  1. Disable (or remove) the inbound mapping in HR resource which populates midPoint username

  2. Disable (or remove) the inbound mapping in Active Directory resource which populates midPoint username

  3. Choose and activate (or create your own) username mapping in Person Object Template (object template for Person archetype) which will generate username based on given name and family name (e.g. jsmith, resolving duplicate usernames with suffixes, e.g. jsmith2)

    The mapping can be used for sAMAccountName as it keeps the username under 20 characters (actually 8 + 2 digits for iterator)

  4. Keep this mapping weak. Usernames should never automatically change.

The new username policy is active from now on: for all new users created in the future.

Naming convention notes

Make sure your naming convention is good enough to not collide with existing AD/LDAP accounts (or other objects) that won’t be imported to midPoint. These include orphaned accounts that won’t be imported (but still exist), system accounts etc.

In case of collision, you may want to rename such accounts in AD/LDAP or the colliding users in midPoint manually.

In case you would like to have more automated solution, you may want to create your own naming convention that avoids duplicate usernames in midPoint as well as in AD/LDAP by doing an additional check against AD/LDAP when generating midPoint username.

If your HR source already contains new records which have not yet been imported to midPoint, you can use the following mechanisms to double-check the username generator before going live:

  • single HR account Import with preview action (Production configuration)

  • simulated HR import task (Production configuration)

On-Boarding Automation (Provisioning)

In this step, turn on the on-boarding automation for the joiners and automatic account updates for existing users.

This is the right time to suspend your legacy on-boarding/provisioning process (e.g. scripts or manual processes). If the accounts will be also updated by system other-than-midPoint, the behaviour in midPoint can be set as "tolerant" for the account attributes which may be still managed by other solution(s), e.g. access rights managed by request/approve process using tickets etc. After the access right management is moved to midPoint, this tolerance should be turned off.

Until any roles are created and conditions for their automatic assignment are defined, the on-boarding automation may simply create accounts in Active Directory for all people from HR with the help of Person archetype we assign to everyone upon import from HR:

  1. Edit Person archetype

  2. Add inducement for Active Directory resource account for all users with Person archetype

  3. Create scheduled reconciliation task for HR resource

We can also add Active Directory accounts to pre-existing groups, e.g. general "all users" group using the same Person archetype and group association for AD account to implement the concept of birthrights in midPoint.

Off-Boarding Automation (Deprovisioning)

The automation between HR and midPoint covers on-boarding as well as off-boarding as data is transferred from HR to midPoint and then from midPoint to Active Directory.

Temporarily inactive HR persons (their Lifecycle state in midPoint is suspended) will be disabled in Active Directory.

Former employees will be disabled in midPoint and their Active Directory (possibly other in the future) accounts will be deleted after a defined time (e.g. 6 months). Former employees will be kept in midPoint indefinitely (their Lifecycle state in midPoint is archived).

Incorrect Data Overrides

HR data is usually authoritative, but not ideal. There might be mistakes in data (typos) or even in person states. Such errors are usually spotted by end users or target system administrators and should be fixed in the source system. Sometimes, however, the fix must be done in the provisioning system - either because we need the fix fast or because some data is constructed by midPoint based on data in HR that will not change just because the end user requires it - this is for example how username is generated.

The data overrides fall into the following categories:

  1. source system user status is incorrect - user must be disabled: this happens in case of malicious employees. We need to disable user’s access now, without waiting for data in HR to be updated and synchronized. MidPoint computes its lifecycleState from HR data (and all target system accounts states based from midPoint lifecycleState). We need to disable user by using special midPoint property: Administrative status: Disabled. User and his/her accounts will be immediately disabled. If the user is cleared from all suspicions, administrator may revert to the original lifecycle state by removing the Administrative status override.

  2. source system user status is incorrect - user must be enabled: this happens in case that HR incorrectly stores user’s status as inactive, but the user should be working normally. Administrative status override cannot be currently used for the positive override; we need to use something else. We will mark user’s HR account as "Invalid data" and then change user’s Lifecycle state in midPoint. From now on, the HR data are no more synchronized for the user. After HR fixes their data, administrator may revert these steps.

  3. source system data is incorrect: this is a simpler version of the previous. Data in HR is incorrect, so administrator can mark user’s HR account as "Invalid data" and fix data directly in midPoint. From now on, the HR data are no more synchronized for the user. After HR fixes their data, administrator may revert these steps.

  4. username change: usually the username is never automatically changed, in some environments, it is actually never changed. But there might be situations when user insists on username change, e.g. because the generated username is inappropriate or even offensive. This cannot be influenced by HR data as username is generated in midPoint. So the quick action is simply to change the username property of midPoint user. Such a change will be automatically propagated to the target systems (so the Active Directory username will change too).

    We recommend to use username change with extreme care.

Follow-Up Steps

Your follow-up steps can differ based on your requirements and their priorities. They can include:

  • Add additional source system e.g. for additional populations

  • Add additional target system using this methodology (without username import)

  • Automate scans for orphaned accounts in Active Directory with automatic reaction (or reporting/notification).

  • Import existing Active Directory groups as roles and assign these roles to midPoint users corresponding to the AD group members.

    • We plan to concentrate on this topic in the follow-up for First steps methodology.

  • Start provisioning Active Directory groups and their membership via midPoint (after they have been initially imported).

    • We plan to concentrate on this topic in the follow-up for First steps methodology.

  • Start moving self-service (password change/reset) to midPoint. Probably makes more sense after more target systems accounts with different passwords are provisioned by midPoint.

  • Switch from batch mode to event-driven synchronization (Live synchronization) from HR.

  • Start creating roles for request/approvals (based on existing roles in the organization). Move request/approval process to midPoint.

    • We plan to concentrate on this topic in the follow-up for First steps methodology.

  • Start creating roles for automatic/conditional assignment. Use role auto-assignment expressions.

    • We plan to concentrate on this topic in the follow-up for First steps methodology.

Was this page helpful?
YES NO
Thanks for your feedback