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 Identity 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 26: 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 27: 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 matching rule is run and the value in the target system is overwritten with the value from the One Identity Manager database.
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
Related topics
The source for the user data and permissions managed by One Identity Manager may be different systems. For example, SAP R/3 user accounts are managed in One Identity Manager. The associated employee 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 employee 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 How to edit 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
You have two options for deleting objects in the One Identity Manager, which do not exist in the target system, by using .
- The objects are deleted immediately on synchronization.
You can view the synchronization log to see which objects have been deleted.
NOTE: Memberships that exist based on an inheritance cannot be deleted immediately. They are always marked as outstanding.
- The objects are marked as outstanding by synchronization.
Outstanding objects must be post-processed separately in One Identity Manager. They can either be deleted or published in the target system in the process. This prevents objects being deleted because of an incorrect data situation or an incorrect synchronization configuration.
Outstanding objects:
-
Cannot be edited in One Identity Manager.
-
Are ignored by subsequent synchronizations.
-
Are ignored by inheritance calculations.
This means, all memberships and assignments remain intact until the outstanding objects have been processed.
To delete objects immediately in One Identity Manager
- Edit the properties.
For more information, see How to edit synchronization steps.
- Select the Processing tab.
- Specify the processing method. Select the following options as appropriate:
| Objects that are only found in One Identity Manager: |
Delete |
To mark object as outstanding in One Identity Manager
- Edit the synchronization step properties.
For more information, see How to edit synchronization steps.
- Select the Processing tab.
- Specify the processing method. Select the following options as appropriate:
| Objects that are only found in One Identity Manager: |
MarkAsOutstanding |
Outstanding objects cannot be editing in One Identity Manager until they have been verified. They are ignored by every other synchronization.
To delete outstanding objects in the One Identity Manager
- Start the Manager.
- Select the <target system type> > synchronization: <target system type> > <table> category.
- Select the objects you want to delete. Multi-select is possible.
- Click
.
- Confirm the security prompt with Yes.
The selected objects are immediately deleted in the One Identity Manager database. Deferred deletion is not taken into account. The "outstanding" label is removed from the objects.
Related topics
