Tchater maintenant avec le support
Tchattez avec un ingénieur du support

Identity Manager 9.2 - Administration Guide for Connecting to LDAP

About this guide Managing LDAP environments Synchronizing LDAP directories
Setting up initial LDAP directory synchronization Adjusting the synchronization configuration for LDAP environments Running synchronization Tasks following synchronization Troubleshooting Ignoring data error in synchronization Pausing handling of target system specific processes (Offline mode)
Managing LDAP user accounts and identities Managing memberships in LDAP groups Login credentials for LDAP user accounts Mapping LDAP objects in One Identity Manager Handling of LDAP objects in the Web Portal Basic data for managing an LDAP environment Troubleshooting Configuration parameters for managing an LDAP environment Default project template for LDAP LDAP connector V2 settings

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 6: Implementation

Implementation

Meaning

Query implementation

Implementation used for calling up entries from the LDAP server.

The DefaultQueryStrategy implementation uses the configured LDAP connection to call up entries.

Type resolution implementation

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.

Read access implementation

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.

Commit implementation

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.

Insert method implementation

Implementation to use for the schema types' Insert method.

The DefaultInsertMethodStrategy implementation will send add requests to the LDAP server to publish new entries.

Update method implementation

Implementation to use for the schema types' Update method.

The DefaultUpdateMethodStrategy implementation sends modify and modifydn requests to the LDAP server to publish changes to existing entries.

Implementation for delete method

Implementation to use for the schema types' Delete method.

The DefaultDeleteMethodStrategy implementation sends delete requests to the LDAP server to delete existing entries.

Schema property handler

Handler

Meaning

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=Pat Identity1

OU=Sales

CN=Jo User1+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=Pat Identity1, the CN property is set to Pat Identity1.

If the vrtEntryRDN has the value OU=Sales, the OU property is set to Sales.

If the vrtEntryRDN has the value CN=Jo User1+UID=char, the CN property is set to Jo User1UID 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.

ClosedEditing, adding, and deleting schema types
ClosedEditing, adding, and deleting methods
ClosedEditing, adding, and deleting schema properties
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:

  • A schema was changed by:

    • Changes to a target system schema

    • Customizations to the One Identity Manager schema

    • A One Identity Manager update migration

  • A schema in the synchronization project was shrunk by:

    • Enabling the synchronization project

    • Saving the synchronization project for the first time

    • Compressing a schema

To update a system connection schema

  1. In the Synchronization Editor, open the synchronization project.

  2. Select the Configuration > Target system category.

    - OR -

    Select the Configuration > One Identity Manager connection category.

  3. Select the General view and click Update schema.

  4. Confirm the security prompt with Yes.

    This reloads the schema data.

To edit a mapping

  1. In the Synchronization Editor, open the synchronization project.

  2. Select the Mappings category.

  3. 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

  • In the Synchronization Editor, open the synchronization project.

  • Edit the workflow properties. Select the Use revision filter item from Revision filtering menu.

To permit revision filtering for a start up configuration

  • In the Synchronization Editor, open the synchronization project.

  • Edit the start up configuration properties. Select the Use revision filter item from the Revision filtering menu.

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.

Configuring the provisioning of memberships

Memberships, such as user accounts in groups, are saved in assignment tables in the One Identity Manager database. During provisioning of modified memberships, changes made in the target system may be overwritten. This behavior can occur under the following conditions:

  • Memberships are saved as an object property in list form in the target system.

    Example: List of user accounts in the Member property of an LDAP group (GroupOfNames)

  • Memberships can be modified in either of the connected systems.

  • A provisioning workflow and provisioning processes are set up.

If one membership in One Identity Manager changes, by default, the complete list of members is transferred to the target system. Therefore, memberships that were previously added to the target system are removed in the process and previously deleted memberships are added again.

To prevent this, provisioning can be configured such that only the modified membership is provisioned in the target system. The corresponding behavior is configured separately for each assignment table.

To allow separate provisioning of memberships

  1. In the Manager, select the LDAP > Basic configuration data > Target system types category.

  2. In the result list, select the LDAP target system type.

  3. Select the Configure tables for publishing task.

  4. Select the assignment tables that you want to set up for single provisioning. Multi-select is possible.

  5. Click Merge mode.

    NOTE:

    • This option can only be enabled for assignment tables that have a base table with a XDateSubItem column.

    • Assignment tables that are grouped together in a virtual schema property in the mapping must be marked identically.

      Example: LDAPAccountInLDAPGroup, LDAPGroupInLDAPGroup, and LDAPMachineInLDAPGroup

  6. Save the changes.

For each assignment table labeled like this, the changes made in One Identity Manager are saved in a separate table. Therefore, only newly added and deleted assignments are processed. During modification provisioning, the members list in the target system is compared to the entries in this table. This means that only modified memberships are provisioned and not the entire members list.

NOTE: The complete members list is updated by synchronization. During this process, objects with changes but incomplete provisioning are not handled. These objects are logged in the synchronization log.

You can restrict single provisioning of memberships with a condition. Once merge mode has been disabled for a table, the condition is deleted. Tables that have had the condition deleted or edited are marked with the following icon: . You can restore the original condition at any time.

To restore the original condition

  1. Select the auxiliary table for which you want to restore the condition.

  2. Right-click on the selected row and select the Restore original values context menu item.

  3. Save the changes.

NOTE: To create the reference to the added or deleted assignments in the condition, use the i table alias.

Example of a condition on the LDAPAccountInLDAPGroup assignment table:

exists (select top 1 1 from LDAPGroup g
where g.UID_LDAPGroup = i.UID_LDAPGroup
and <limiting condition>)

For more information about provisioning memberships, see the One Identity Manager Target System Synchronization Reference Guide.

Documents connexes

The document was helpful.

Sélectionner une évaluation

I easily found the information I needed.

Sélectionner une évaluation