Advanced settings of a generic LDAP connector
IMPORTANT: Changes to advanced settings should only be carried out by experienced Synchronization Editor users and system administrators.
Use the system connection wizard to configure the following extended properties of the generic connector:
-
Definition of auxiliary classes of type Auxiliary
-
Definition of virtual classes for non-RFC compliant object mappings
-
Definition of system attributes for object identification, revision properties and additional operational attributes
-
Definition of additional attributes for supporting dynamic groups
NOTE: To make advanced settings, on the start page of the system connection wizard, set the Configure advanced settings (expert mode) option.
Define auxiliary classes
On the Define auxiliary classes page, select the structural classes that are handled as auxiliary classes by the LDAP connector. This may be necessary if a non-RFC compliant LDAP system allows assignment of several structural object classes to one entry although only one structural class is allowed.
Assigning more than one structural class means that an LDAP entry cannot be uniquely assigned to a schema type. If structural object classes have been defined that only serve as property extensions (meaning auxiliary classes), you can, with help from this option, set the connector to handle the object class as an auxiliary class.
NOTE: Object classes that are configured as auxiliary are subsequently not handled as independent schema types and cannot, therefore, be synchronized separately.
Assigning auxiliary classes
On the Assign auxiliary classes page, assign additional auxiliary classes to structural classes.
Auxiliary classes are classes of type Auxiliary and contain attributes for extending structural classes. Auxiliary class attributes are offered as optional attributes for structural classes in the schema.
NOTE: To map the attributes of the auxiliary classes in One Identity Manager, custom extensions to the One Identity Manager schema may be necessary under certain circumstances. Use the Schema Extension program to do this.
Defining virtual classes
On the Virtual classes page, define additional virtual classes. Objects made up of several structural classes can only be created in non-RFC compliant LDAP systems. They consist of one or more different classes that are not derived from each other, such as OrganizationalUnit and inetOrgPerson.
To create a virtual class
-
In the system connection wizard, on the Virtual classes page, click 
in the Configured virtual classes pane and enter the virtual class' name in the Virtual class field.
-
In the Select structural classes pane, select the structural classes that are mapped to the virtual class.
Specifying additional system attributes
On the System attributes page, you specify which LDAP system attribute is used to uniquely identify the objects.
-
In the Object identification attribute pane, select the attribute that can be used to uniquely identify the objects in the LDAP. The attribute must be unique and set for all objects LDAP.
-
In the Revision properties pane, specify which attributes can be used for revision filtering.
-
In the Additional operational attributes pane, specify which attributes should also be determined for the LDAP objects. Functional attributes are used for managing directories. Attributes are only determined if they are explicitly given.
NOTE: To map the operational attributes in One Identity Manager, custom extensions to the One Identity Manager schema may be required. Use the Schema Extension program to do this.
Defining attributes for supporting dynamic groups
If the LDAP server supports dynamic groups, on the Select dynamic group attributes page, mark the attribute that contains the URL with the search information for matching members of dynamic groups, memberURL for example.
Related topics
Extended schema configuration with the LDAP connector V2
By preconfiguring this connector that you can select in the system connection wizard, the required schema configuration is already set up. If, in exceptional cases, it becomes necessary to make changes you can use the system connection wizard to configure schema types, schema properties, and methods.
IMPORTANT: Changes to the schema configuration should only be carried out by experienced Synchronization Editor users and system administrators.
NOTE: To make advanced settings, on the start page of the system connection wizard, set the Configure advanced settings option.
On the Connector schema configuration page, a hierarchical meta schema is displayed showing the schema types that will be created. You can add, edit, or delete schema classes, schema properties, and methods. The information displayed is similar to the information in the Synchronization Editor.
Use these setting to:
-
Specify which schema property is used for revision filtering.
-
Specify which schema property is used to uniquely identify an object.
-
Define virtual schema types if necessary.
Implementation types
NOTE: Global settings for implementing read and write access are stored in the Schema entry on the Connector schema configuration.
Table 7: Implementation
|
Implementation for queries |
Implementation used for calling up entries from the LDAP server.
The DefaultQueryStrategy implementation uses the configured LDAP connection to call up entries. |
|
Implementation for type resolution |
The implementation that inspects LDAP entries returned by LDAP servers to determine and assign the connector schema type for the resulting connector object.
This option can only be changed in the through the user with the Request & Fulfillment | | Administrators application role. |
|
Implementation for read access |
Implementation converts a schema property’s values based on an LDAP entry. |
|
Reference handling |
Implementation for creating or resolving reference values of an LDAP entry’s schema property. A reference in LDAP is usually a property pointing to another entry through a distinguished name. |
|
Implementation for commit |
The implementation to be used when entries are saved by the connector to the LDAP server.
The DefaultCommitStrategy implementation calls the methods Insert, Update, or Delete depending on the state of the object. |
|
Implementation for insert method |
Implementation to be used for the Insert method of the schema types.
The DefaultInsertMethodStrategy implementation will send add requests to the LDAP server to publish new entries. |
|
Implementation for update method |
Implementation to be used for the Update method of the schema types.
The DefaultUpdateMethodStrategy implementation sends modify and modifydn requests to the LDAP server to publish changes to existing entries. |
|
Implementation for delete method |
Implementation to be used for the Delete method of the schema types.
The DefaultDeleteMethodStrategy implementation sends delete requests to the LDAP server to delete existing entries. |
Schema property handler
|
DNBackLinkPropertyHandler |
Backlink handler. This handler resolves backlinks between schema properties.
Example:
This handler is configured for the group’s Member schema property. The MemberOf schema property is selected as Backlink property.
If a user account is assigned to a group, the user account is entered in the in the target system in the group’s Member schema property. The handler determines the referenced object, in this case, the user account and enters the group reference in the MemberOf schema property. |
|
MirrorPropertyHandler |
Mirror property handler This handler transfers values and changes of a schema property, for which the handler is defined, to the schema property given under Mirror property.
Example:
This handler is configured for the group’s Member schema property. The equivalentToMe schema property is selected as Mirror property.
If a user account is assigned to a group, the user account is entered in the in the target system in the group’s Member schema property. This is also added to the equivalentToMe schema property. |
|
RdnPropertyHandler |
This handler handles the vrtEntryRDN virtual schema property. The vrtEntryRDN schema property represents the relative distinguished names of the entry. The distinguished name is made up of one or more pairs of attribute name and attribute value combined, with the syntax <attribute name>=<attribute value>[+<attribute name>=<attribute value>]
Examples:
CN=Ben King
OU=Sales
CN=Clara Harris+UID=char
The handler ensures that when the vrtEntryRDN is set, the matching referenced property of the LDAP entry is set the same.
Example:
If the vrtEntryRDN has the value CN=Ben King, the CN property is set to Ben King.
If the vrtEntryRDN has the value OU=Sales, the OU property is set to Sales.
If the vrtEntryRDN has the value CN=Clara Harris+UID=char, the CN property is set to Clara HarrisUID and the UID is given the value char. |
|
DefaultValueModificationHandler |
This handler ensures that there is always at least one defined default value is written to a schema property. This can currently be free text or the distinguished name of the object that the value is defined on, such as a group.
A CheckForDefaultValueAction operation is queued at the start and when changes are made to the schema property that was assigned to the handler.
The handler ensure the following behavior:
-
If the object was just added, it checks that the schema property contains a value. If this is not the case, the default value is written to the schema property.
-
If this is a change, first the property is loaded from the target system.
There are the following possible cases:
-
In LDAP, the schema property is already set to the default value. The pending change will allocate another (additional) value to the schema property.
The default value is removed from the schema property in LDAP and the new value is allocated to the schema property.
-
In LDAP, the schema property is not set to the default value yet. The pending change will clear the schema property or delete the last value, for example.
In LDAP, the default value is allocated to the schema property. |
To edit a schema type
-
In the system connection wizard on the Connector schema configuration page, select the schema type in the Schema pane.
On the right-side of the view, you can see the schema type’s properties.
To add a simple virtual schema type
-
In the system connection wizard on the Connector schema configuration page, select the schema type in the Schema pane and click .
-
Edit the schema type properties.
To create a virtual schema type from several schema classes
-
In the system connection wizard on the Connector schema configuration page, in the Schema pane, select the schema classes to be combined using Ctrl + select and click 
.
-
Edit the schema type properties.
To delete a virtual schema type
To edit a method
-
In the system connection wizard on the Connector schema configuration page, select the schema type in the Schema pane.
-
In Methods, select the method.
On the right-side of the view, you can see the method’s properties.
To add a method
-
In the system connection wizard on the Connector schema configuration page, select the schema type in the Schema pane.
-
Select the Methods item and click .
- Edit the method's properties.
To delete a method
-
In the system connection wizard on the Connector schema configuration page, select the schema type in the Schema pane.
-
Select the method in the Methods list and click 
.
To edit a schema property
-
In the system connection wizard on the Connector schema configuration page, select the schema type in the Schema pane.
-
Select the schema property in the Properties list.
On the right-side of the view, you can see the schema property’s attributes.
To add a virtual schema property
-
In the system connection wizard on the Connector schema configuration page, select the schema type in the Schema pane.
-
Select the Properties item and click .
- Edit the schema property details.
To delete a virtual schema property
-
In the system connection wizard on the Connector schema configuration page, select the schema type in the Schema pane.
-
Select the schema property in the Properties list and click .
Related topics
Updating schemas
All the schema data (schema types and schema properties) of the target system schema and the One Identity Manager schema are available when you are editing a synchronization project. Only a part of this data is really needed for configuring synchronization. If a synchronization project is finished, the schema is compressed to remove unnecessary data from the synchronization project. This can speed up the loading of the synchronization project. Deleted schema data can be added to the synchronization configuration again at a later point.
If the target system schema or the One Identity Manager schema has changed, these changes must also be added to the synchronization configuration. Then the changes can be added to the schema property mapping.
To include schema data that have been deleted through compression and schema modifications in the synchronization project, update each schema in the synchronization project. This may be necessary if:
To update a system connection schema
-
In the Synchronization Editor, open the synchronization project.
-
Select the Configuration > Target system category.
- OR -
Select the Configuration > One Identity Manager connection category.
-
Select the General view and click Update schema.
- Confirm the security prompt with Yes.
This reloads the schema data.
To edit a mapping
-
In the Synchronization Editor, open the synchronization project.
-
Select the Mappings category.
-
Select a mapping in the navigation view.
Opens the Mapping Editor. For more information about mappings, see the One Identity Manager Target System Synchronization Reference Guide.
NOTE: The synchronization is deactivated if the schema of an activated synchronization project is updated. Reactivate the synchronization project to synchronize.
Speeding up synchronization with revision filtering
When you start synchronization, all synchronization objects are loaded. Some of these objects have not be modified since the last synchronization and, therefore, must not be processed. Synchronization is accelerated by only loading those object pairs that have changed since the last synchronization. One Identity Manager uses revision filtering to accelerate synchronization.
LDAP supports revision filtering. Revision properties defined when the synchronization project was set up, are used for the revision count. In the default version, the creation date and the date that LDAP objects were last modified is used. Every synchronization saves the last date it was run on in the One Identity Manager database. (DPRRevisionStore table, value column). This value is used as a comparison for revision filtering when the same workflow is synchronized the next time. The next time synchronization is run, only those objects that have been changed since this date are loaded. This avoids unnecessary updating of objects that have not changed since the last synchronization.
The revision is found at start of synchronization. Objects modified by synchronization are loaded and checked by the next synchronization. This means that the second synchronization after initial synchronization is not significantly faster.
Revision filtering can be applied to workflows and start up configuration.
To permit revision filtering on a workflow
To permit revision filtering for a start up configuration
NOTE: Specify whether revision filtering will be applied when you first set up initial synchronization in the project wizard.
For more information about revision filtering, see the One Identity Manager Target System Synchronization Reference Guide.
Creating virtual classes