Methodology: Group Synchronization

Last modified 07 Nov 2024 09:37 +01:00
Since 4.9
This functionality is available since version 4.9.
Table of Contents

Introduction

Evolveum’s First Steps with MidPoint methodology has been created to deploy midPoint for users and their accounts quickly. However, it has been prepared to be universal. Group Synchronization Methodology extends First Steps Methodology with processing of entitlements, typically groups, on connected systems.

The Complexity of Group Management

One could think that moving from users to groups won’t be such a difference but in practice, there is a huge step in complexity. Groups typically don’t have a single authoritative source that you can use and just provision the same groups everywhere. If there is an authoritative source, which is not always true, it contains groups representing business roles. But when you are connecting the target system, you need to provision groups representing application roles that are supported on a given system.

Moreover, the integrated system usually has existing groups that cannot be simply overwritten, since there is no source of truth. This is especially true for Directory services which are typically the first systems you need to integrate with IGA solution. Therefore, the management of such groups need to be migrated to midPoint where they can be managed in an organized way. To complicate the situation even more, the groups in an integrated system are often managed using a combination of several approaches. It’s not rare to have a combination of manual and automated management using different interfaces and organizational processes.

Methodical Approach

In order to untangle such chaos, we need to analyze the existing state and migrate the management of groups to midPoint not only on the technical level but also change the organizational processes related to that. The change in processes might include removing legacy automated management or updating user guides on how they can manually manage or request the roles. Changing processes is generally a complicated task, also in this case different groups might have different management processes associated which adds even more to the difficulty. That is leading us to an indisputable need to migrate the group management consequently one-by-one or in batches of groups with similar characteristics.

To address the described complication, we will use the proved Connect → Clean-up → Automate iterative approach. That will enable us to gradually migrate all the groups, including clean up in data and taking into account existing processes and operational needs. Such migration can be safely executed in a production environment without any negative impact on end users. To fully reflect the real needs the migration process is very flexible so it can be finalized in a single day in favourable conditions, but it also can last virtually indefinitely if there is a need to do so (e.g. when migrating from legacy IdM which requires a big change in the infrastructure).

Added Values

In summary, the Group Synchronization methodology will help in many areas and address potential pain-points, namely:

  • Working on production data with simulations will:

    • Speed up execution of individual steps, leading to saving time or utilizing the extra time on other project activities.

    • Boost confidence of engineers and eliminate stress from executing significant system change for both technical team and the leadership.

  • Ability to migrate groups in chunks will:

    • Help achieve partial results immediately.

    • Execute large part of migration without being blocked by special cases and exceptions.

    • Diversify and mitigate the risk related to change of organization processes.

  • Reducing the technical complexity and streamlining the process will:

    • Allow less experienced engineers to execute the process safely, saving time of the experts.

    • Get you on the right track towards IGA.

  • Increase in configuration flexibility will:

    • Enable to simultaneously have objects (e.g. users, groups) managed by midPoint with object of the same type managed externally, which is reflecting the needs of typical deployments.

    • Allow fine-tuning of reactions on unexpected changes (e.g. when a new group will appear) which will strengthen the cybersecurity.

  • Ability to synchronize groups into midPoint even when they are managed externally will:

    • Allow use midPoint’s IGA features, like reporting or risk analysis, even for externally managed groups.

    • Move forward with following identity analytics steps, like role-mining or outlier detection, even before the migration is fully completed.

Group Synchronization & IGA Principles

The Group synchronization methodology has been designed to be particularly useful for situations where there are some groups that cannot be managed by midPoint, either temporarily or permanently, but which are needed to be imported to midPoint to make them visible as roles. Marking the groups using the well-known Protected mark would not allow importing the groups as roles. However, the midPoint roles and their assignments are ultimately more visible in midPoint. They can be used to report user accesses, manage and optimize using midPoint’s IGA-related features such as application roles, business roles, role mining etc.

Therefore, by group migration we mean two things:

  1. migration of data: groups → roles; group membership → role assignments

  2. migration of mindset: from group management to role management using midPoint

Before continuing, please make yourself familiar with First Steps with MidPoint methodology.

Connect Active Directory Resource for Groups

Connect Active Directory as a group data source to midPoint. Decide which type of groups represents the access. Decide which type of midPoint objects you want to use to represent the groups (Roles, Organizations, Services). Roles are most typically used to represent the groups.

Establish a role naming convention that suits your environment. The role names are typically based on group identifiers, but there could be multiple systems with the same group identifiers, yet the role name must be unique. The simplest way how to achieve the uniqueness of the role name property is to prefix the group name with the resource name or a string based on resource name and keep the original group identifier in a dedicated role property, e.g. identifier for correlation purposes.

Imagine the following situation: there are multiple directory systems (AD, DS, AD Ext) configured as midPoint resources. All these systems contain, among others, group named cn=administrators, . . .. Role with name administrators would not be suitable as we need to distinguish between multiple roles for multiple groups.

This could be resolved by the following naming convention:

Resource Group identifier (unique per resource) Unique prefix Role name (unique in midPoint) Role identifier

AD

administrators

ad

ad:administrators

administrators

DS

administrators

ds

ds:administrators

administrators

AD Ext

administrators

ad-ext

ad-ext:administrators

administrators

Similar technique can be used for role display name (which is optional in midPoint and you don’t need to use it).

Create the new object type configuration in Proposed lifecycle state to allow simulations. Configure the object type to create a new archetype for all roles created by its configuration. It will allow to quickly filter the roles and define provisioning behavior for them:

  • Create inducement: select true to allow creation of new resource entitlements for all roles with this archetype

  • Create inducement for membership: select the object type for account that will be created in AD resource and associated with the group for the entitlement that is provisioned by the role with this archetype.

    If you do not select any value, existing members of the role with this archetype, that already have account in AD resource, will be associated with the corresponding group. If the role is assigned to users without AD resource account, new account won’t be created.

Configure synchronization configuration to make Active Directory resource authoritative for role creation and deactivation/deletion based on new/deleted groups:

Situation Action Notes

Unmatched

Add focus

Create a new focus object (role) from entitlement

Unlinked

Link

Link the entitlement object to correlated focus object (role)

Linked

Synchronize

Synchronize data between entitlement and focus object (role) using mappings.

Deleted

Inactivate focus

Disable focus object (role).
Instead of Inactivate focus, it is also possible to use Delete focus. Dangling role assignments will be cleared during user recomputation or reconciliation automatically.

Create inbound mappings to allow creation of midPoint roles for at least:

  • Name (using a good naming convention)

  • Display name (optional, using a good naming convention)

  • Description (from group description, if it exists)

  • Identifier (from group identifier, e.g. cn or dn)

The main idea is that you may use group identifier for correlation with midPoint roles and still have unique role name. Display name may be derived from group identifier and/or can be changed anytime by the administrators.

Configure Default operation policy as Unmanaged to automatically consider all resource groups as "inbound-only" objects.

If there are legacy groups that cannot be migrated to midPoint because they are still managed by another system (e.g. legacy IDM tool), create Marking rules to explicitly mark such groups as Unmanaged.

Please refer to the following documentation:

Import Groups

Start with import simulation while the object type for groups is in Proposed lifecycle state.

Adjust the inbound configuration as necessary.

When finished, switch the object type to Active lifecycle state and import the groups to create midPoint roles. The roles representing Active Directory groups are visible in midPoint can be distinguished from other roles by their archetype defined in object type definition and automatically assigned during the role creation process.

Scheduled reconciliation task can be created for AD resource groups to synchronize the groups with roles regularly.

Active Directory resource is authoritative for the groups and role creation.

Import Group Membership

Configure associations for group membership in Proposed lifecycle state. Specify subject and object of the association (which objects can be associated with which objects).

You can create several association configurations for different group types. Just define new association types for different subject/object combinations. Each of the association type configurations will be using different association reference attribute name.

We recommend to configure association tolerance as undefined (defaults to tolerant; will be overridden by marks in later steps).

Create synchronization configuration for association to allow assignment of midPoint roles based on user accounts' associations (resource group membership) if the roles are not already assigned indirectly:

Situation Action Notes

Unmatched

Add focus value

Creates an assignment from association

Matched

Synchronize

Synchronizes data between association and assignment for existing direct assignments corresponding to the association

Matched indirectly

Undefined

Does nothing if there is already an indirect assignment corresponding to the association

Create inbound association mapping to populate assignment’s targetRef property from association:

From resource attribute Expression Target

(keep default association reference attribute)

Shadow owner

targetRef
Please refer to the following documentation:

Start with import simulation while the association type configuration is in Proposed lifecycle state.

Adjust the inbound association configuration as necessary.

When finished, switch the association type to Active lifecycle state and import the group membership to create midPoint role assignments.

Role assignments representing group membership in Active Directory are now visible in midPoint.

Scheduled reconciliation task can be created for AD resource accounts to synchronize the group membership with role assignments regularly.

Active Directory resource is authoritative for the group membership and role assignments/unassignments.

Migrate Group Management to MidPoint

Configure the Active Directory resource outbound behavior for groups and their memberships (associations). You don’t need to use Proposed configuration while the Default operation policy is Unmanaged as the provisioning is completely ignored. We recommend using the role Identifier as a source of group identifiers for the following reasons:

  1. it has been derived from group identifiers for existing groups

  2. the role name or display name may be changed by administrators and it should not automatically rename the group

Create outbound association mapping to populate account membership corresponding to midPoint assignments:

Source Expression To resource attribute

(keep empty)

Association from link

(keep default association reference attribute)
Please refer to the following documentation:

The migration of the groups follows in several steps explained in the next chapters.

Migrate the Management of Selected Groups to MidPoint

This step allows to test the outbound configuration and migrate specific groups using a group-by-group approach. This will be achieved by individual group marking using mark’s Proposed lifecycle state.

Any background tasks, such as scheduled reconciliation with HR source, will keep using the production configuration and will ignore processing of objects with marks in Proposed lifecycle state.

Select one or several groups which have been already imported to midPoint as roles.

  1. mark the selected group(s) with mark(s): Managed with lifecycle state: Proposed

  2. edit the corresponding role and attempt to make a simulated modification (using Preview with development configuration) to allow outbound mappings to be evaluated in simulation

  3. run reconciliation with Active Directory resource accounts with development configuration to allow outbound association mappings to be evaluated in simulation

  4. if the simulation results correspond to your expectations, update the Managed marks: change their lifecycle state to: Active

Please refer to the following documentation:
MidPoint is now authoritative for the groups with Managed mark. If the groups are updated in Active Directory resource, midPoint will overwrite the group attributes and maintain the group membership according to the role assignments.
If you assign user a role which has Unmanaged projection, the role will be assigned, but user’s projection won’t be created/updated as the outbound configuration is not used at all.
MidPoint cannot create new groups yet, as the Default operation policy is still Unmanaged.

Migrate the Management of Non-legacy Groups to MidPoint

After you have performed migration of one or several groups in the previous step, you can migrate all non-legacy groups in a single step by changing Default operation policy, while the marking rule for legacy groups is still in place and allows their management outside midPoint.

Any background tasks, such as scheduled reconciliation with HR source, will keep using the production configuration and will ignore processing of objects with Default operation policy in Proposed lifecycle state.

  1. change Default operation policy: set the lifecycle state for Unmanaged to: Deprecated and add a new policy: Managed with lifecycle state: Proposed

  2. run reconciliation with Active Directory resource groups with development configuration to allow outbound mappings to be evaluated in simulation

  3. run reconciliation with Active Directory resource accounts with development configuration to allow outbound association mappings to be evaluated in simulation

  4. if the simulation results correspond to your expectations, change the Default operation policy again: set the lifecycle state for Unmanaged to: Archived and lifecycle state for Managed to: Active

Please refer to the following documentation:
MidPoint is now authoritative for all groups and their membership except the legacy groups which have Unmanaged mark.

Automate Group Integration

Even with legacy groups in place, midPoint is now able to create new groups. Configuration is already prepared in role archetype and outbound mappings/outbound association mappings.

By editing the group role archetype, you can add focus mappings to only ask administrators for role Identifier and automatically fill in other role properties, such as Name and Display name.

By creating new roles with the group role archetype, the new groups will be automatically created in the Active Directory resource.

After the legacy groups are not created by IDM tool anymore, processes have been updated and administrators trained, restrictions for legacy roles can be removed:

  1. delete marking rules specific for legacy groups to remove exceptions and make midPoint handle the groups using the Default operation policy (now Managed)

  2. update synchronization configuration to stop Active Directory resource being authoritative for roles. Instead, configure midPoint to either delete unmatched groups or mark them automatically (situation: Unmatched). Also, configure midPoint to re-create any groups forcibly deleted in Active Directory resource (situation: Deleted).

    Situation Action Notes

    Unmatched

    Delete resource object

    Delete the group from resource

    Unlinked

    Link

    Link the entitlement object to correlated focus object (role)

    Linked

    Synchronize

    Synchronize data between entitlement and focus object (role) using mappings.

    Deleted

    Synchronize

    Recreate the resource object
Instead of deleting unmatched group, you may want to use Undefined reaction and create an automatic marking rule to mark such groups.
Please refer to the following documentation:
Migration of the Active Directory resource group management to midPoint has been finished. From now on, midPoint is authoritative for the group creation and deletion and for the group membership based on the role assignments.

Use Person Archetype for Birthrights

If there are any groups (roles) which should be automatically assigned to all users, Person archetype can be modified to allow this automation:

  1. edit Person archetype

  2. edit inducement for the Active Directory resource account and set its lifecycle state to: Deprecated

  3. add new inducements for roles that should be automatically assigned and set their lifecycle state to: Proposed

  4. run a simulated reconciliation task for HR resource with development configuration and examine the simulation results (no changes in user assignments should be indicated)

  5. edit Person archetype once again, set the lifecycle state of the inducement for Active Directory account to: Archived and set the lifecycle state of the role inducements to: Active

You can also do a cleanup - unassign the roles that are now being induced by Person archetype, from all users. For each such role:

  1. edit the role in midPoint

  2. unassign all its members (direct role assignments)

  3. wait until the background unassignment task finishes

Limitations

There are some inherent limitations that you should keep in mind when using this methodology.

  1. Protected groups won’t be imported as roles: as Protected mark makes midPoint ignore inbound mappings entirely, such groups won’t be imported as roles. MidPoint will simply ignore such roles.

  2. Protected group membership won’t be imported as role assignments: similar to the previous statement, Protected mark makes midPoint ignore inbound association mappings entirely. Tolerance for Protected groups is automatically set to true. MidPoint will not handle such membership, it will keep it untouched. This is a safety mechanism - Protected groups should be simply not touched and that is true also for their members.

  3. Unknown members of groups won’t be handled by midPoint: if group contains members (accounts), which are not projections of midPoint users, midPoint won’t handle them. They will not be automatically created as users. We recommend to minimize number of such user and prefer to import such accounts to midPoint as users to improve the visibility of their group membership by using the role assignments and allow other IGA features.

  4. If you assign user a role which has Unmanaged projection: the role will be assigned, but user’s projection won’t be created/updated as the outbound configuration is not used at all. There is currently no simple way of reporting such users with midPoint (user with role assigned, but technically not applied for given resource object)

Conclusion

The approach presented here is not limited just for groups and roles. In fact, it can be used to synchronize any resource objects with any focal objects in midPoint, for example:

  • resource groups with midPoint organization structure

  • resource organizational units with midPoint organization structure

  • resource printer objects with midPoint services

With a good naming convention, multiple resources having the same names (identifiers, cn, dn etc.) of resource objects can be connected to unique role-like objects. One example of such naming convention is suggested in this methodology.

The approach presented here is also not limited to a single group type. You can define multiple object types to differentiate how midPoint handles the groups, for example:

  • groups with different object classes

  • groups located in different subtrees and/or different naming conventions

You need to follow the recommendations for the naming conventions and use different archetypes for different group roles.

Follow-Up Steps

The possible follow-up steps include:

Was this page helpful?
YES NO
Thanks for your feedback