For certain schema properties, it may be necessary to copy the schema property value immediately from the to the primary synchronization system each time synchronization is run. There is a property mapping rule for these schema properties whose direction of mapping is opposite to the direction of synchronization. These rules are not run by default. To transfer these schema property values during synchronization, you must ensure that these rules are carried out. This behavior is configured in the property mapping rules.
Prerequisites
To force mapping a schema property against the direction of synchronization
Property mapping rules with this option set are run after the is completed. This copies changes from the connected system against the direction of synchronization into the primary system.
Synchronization Sequence
- All property mapping rules whose is the opposite to the direction of synchronization are ignored whilst a synchronization step is being run. Property mapping rules whose mapping direction corresponds to the direction of synchronization are run.
- All changes to the connection system are saved when the synchronization step is complete.
-
All property mapping rules with the option Force mapping against direction of synchronization set are run again. For those schema properties involved, the changes are copied from the connected system into the primary system.
NOTE: The property mapping rules are also rerun after completion of the synchronization step if there are no processing methods given in the synchronization step.
Use the Force mapping against direction of synchronization option for schema properties that cannot be edited in the primary system due to technical limitations.
NOTE: This option is also taken into account when object changes are provisioned.
Example
An Active Directory environment should be administrated through One Manager. One Identity Manager is the primary system for synchronizing both systems. The user account object GUIDs are, however, not mapped in One Identity Manager but in the Active Directory environment. This means the mapping direction is different for a user account object GUID. To copy the object GUID from the target system to One Identity Manager during synchronization, the mapping must be forced in the opposite direction of synchronization for this schema property.
Table 25: Synchronization configuration
|
Direction of Synchronization: |
To the target system |
|
for schema properties: |
ADSAccount.ObjectGUID - User.ObjectGUID |
|
Mapping direction: |
To the One Identity Manager |
|
Force mapping against direction of synchronization |
Enabled |
Synchronization Sequence
Scenario: A new Active Directory user account was added in One Identity Manager.
- The user account is added in the target system through synchronization.
- The property mapping rule for the object GUID is ignored because of the opposing the mapping direction.
- Once all property mapping rules of the synchronization step have been processed, the user account is saved in the target system. A value is calculated in the target system for User.ObjectGUID.
- Once the synchronization step is complete the property mapping rule for the object GUID is run again. The object GUID is copied from Active Directory to One Identity Manager.
Related topics
To single schema properties, it could be necessary to declare one of the as the primary system. Property mapping rules for these schema properties all have the same direction of mapping. If editing these schema properties is not technically restricted in any of the connected systems, you can also change their values in a system that is not the primary system.
If the direction of synchronization matches the direction of mapping these changes are overwritten by the next synchronization.
If the direction of synchronization is opposite to the direction of mapping, data that cannot be corrected by synchronization becomes inconsistent because the property mapping rules are not run. Change like this are consider to be “”. In this case, a modification is considered to be any difference between the of the connected systems, irrespective of the system the object was actually modified.
Synchronization can identify (), log, and correct (rogue correction) rogue modifications. You can configure the respective behavior in the property mapping rules.
Prerequisites
To detect and log rogue modifications
To correct rogue modifications
- In addition, set the Correct rogue modifications option in the property mapping rule.
NOTE: Rogue modifications can only be corrected if there is write access for schema property to be corrected.
Synchronization Sequence with Modification Detection
-
A property mapping rule is detected whose is opposite to the actual direction of synchronization.
-
If Detect rogue modifications is set, One Identity Manager checks the object of the connected system for rogue modifications. Rogue modification are logged.
The log can be evaluated after synchronization. For more information, see Synchronization analysis.
-
If the Correct rogue modifications option is set, One Identity Manager runs the property mapping rule. The object property in the connected system is overwritten with the value from the primary system.
NOTE: Rogue modifications are also handled when object modifications are provisioned.
Modification detection can be usefully applied if a and a are configured, which means, the direction of synchronization is One Identity Manager and for certain schema properties the direction of mapping is the target system. In this case, only changes made to the schema properties that were made in the target system are detected as rogue modifications.
Example
The synchronization direction One Identity Manager is specified for synchronizing Active Directory groups. The groups and their properties are created, edited, and deleted in Active Directory. Only the group’s account manager is going to be assigned and changed in One Identity Manager.
Table 26: Synchronization Configuration
|
Direction of Synchronization: |
To the One Identity Manager |
|
for schema properties: |
ADSGroup.ObjectKeyManager - Group.name of manager |
|
Mapping direction: |
To the target system |
|
Detecting rogue modifications: |
Set |
|
Correct rogue modifications: |
Set |
Synchronization adds new groups in One Identity Manager. An account manager is assigned in One Identity Manager. This modification is provisioned in the target system.
There is no technical restriction to editing the account manager in the target system. If the account manager is changed in Active Directory, there is a discrepancy in the data, meaning a rogue modification. This change is detected, logged, and reverted by the next synchronization. The property mapping rule is run and the value in the target system is overwritten with the value from the One Identity Manager database.
Ignore mapping direction on adding
It may make sense to use modification detection together with the Ignore mapping direction restrictions on adding option. As in the example, a new group is added in Active Directory. This initially assigned an account manager.
By synchronizing, the group is added in One Identity Manager but the account manager remains empty because the property mapping rule is not run.
Before the account manager is assigned in One Identity Manager, the Active Directory is synchronized again. This detects a rogue modification (empty value in the database - account manager assigned in the target system). As a result, the value in the target system is corrected, deleting the account manager.
To avoid such situations, set the Ignore mapping direction restrictions on adding option. This means, the property mapping rule for the account manager is run when the group is added and the account manager is assigned in the database. The subsequent synchronization does not detect a rogue modification because the account manager is identical in both systems.
To run a property mapping rule on adding
-
Edit the property mapping rule.
-
Set the Ignore mapping direction restrictions on adding option.
Respect sort order of MVP values
It must be specified for multi-valued schema properties whether the order in which the values are sorted in the value list is relevant for detecting rogue modifications.
-
Sort order is relevant
A rogue modification is also detected if merely the sort order of the values in the value list differs.
-
Sort order is irrelevant
A rogue modification is detected if at least one of the values in the value list differs. If the value lists differ only by the order in which the values are sorted, a rogue modification is not detected.
Prerequisites:
-
Both mapped schema properties are multi-value.
-
The schema property written by the mapping has DPRSchemaProperty.IsMvpOrderSignificant=1.
-
Rogue detection enabled is set.
-
Force mapping against direction of synchronization is disabled.
-
Handle first property value as single value is disabled for both of the connected systems.
To respect the sort order of MVP values when detecting rogue modifications
-
Edit the property mapping rule.
-
In the Multi-value sort order menu, select Respect sort order.
Related topics
The source for the user data and permissions managed by One Manager may be different systems. For example, SAP R/3 user accounts are managed in One Identity Manager. The associated identity data, however, is imported into the database through the from another system.
The CSV import may cause the objects coming from another target system through to be modified. For example, the first and last names of an SAP user account change when the first and last names of an identity change through the CSV import. Changes to the SAP user account should be immediately provisioned in SAP R/3. To illustrate this, the will be named "primary systems" in the following; the systems whose data is synchronized with the CSV connector as "secondary systems".
Figure 12: Example of synchronizing user data with different systems
You can specify whether the data comes from a secondary system in the . In this case, changes are provisioned immediately (actually during synchronization) in the primary system. Conversely, the provisioning process may not start if primary systems are being synchronized.
To configure immediate provisioning when synchronizing a secondary system
- Open the for the secondary system.
For more information, see How to edit a synchronization project.
- Edit the synchronization step properties.
Set the Import data option on the General tab.
For more information, see Editing synchronization steps.
NOTE: To prevent immediately provisioning of a primary system during synchronization, open the primary system synchronization project and disable the Import data option in the synchronization step.
The session variable FullSync=FALSE is set if the Data import option is enabled. The session variable is set to FullSync=TRUE if the option is disabled. Different processes, scripts, and are only run in the One Identity Manager database if FullSync=FALSE. In this context it means they are only synchronized with a secondary system. Synchronizing with a primary system ignores processes, scripts, and templates.
Related topics
