Home

 

Synchronize LDAP changes with Profiles

As administrator, you need to synchronize changes from your LDAP to the Profiles database to ensure that your organizational information is kept up-to-date. You can use the sync_all_dns task to keep your profiles data synchronized with changes to the LDAP


The information in Profiles reflects the data that is present in your LDAP or other data source. When you need to change or update this information – for example, if an employee moves department or leaves the company, or if your organization has taken over another division and you want to import new hires into the Profiles database – you update the LDAP directory first and then synchronize the change to Profiles.

For all LDAP directories, the sync_all_dns task can be used to take changes from the LDAP and apply them to the Profiles database. To keep the Profiles database in a close synchronized state with your LDAP directory, run this task nightly or at another frequency that suits you. Because this task performs a complete comparison of the LDAP search scope with the Profiles database, be sure to allow sufficient time for it to run. It also creates temporary files that are used during the synchronization process so you need to allocate sufficient disk space. The entries in the Profiles database are compared to the values in the LDAP and the changes are then applied to the Profiles database. The mapping values used to populate profiles are used to match the fields. If you configure supplemental information, such as custom extension attributes, that information is also synchronized.

To keep your profiles synchronized with your LDAP directory, it is recommended that you use the generic sync_all_dns command. However, if your LDAP is IBM Tivoli Directory Server or Microsoft Active Directory, you can use the process_tds_changes or process_ad_changes commands. For more information on synchronizing changes when your LDAP is Tivoli Directory Server or Active Directory, see Synchronizing IBM Tivoli Directory Server and Microsoft Active Directory LDAP changes.

To synchronize LDAP changes with Profiles, perform the following steps:

  1. Open a command prompt and then enter the following script to process changes made after the initial population:

    • AIX and Linux

      chmod +x sync_all_dns.sh

      ./sync_all_dns.sh

    • Microsoft Windows

      sync_all_dns.bat

  2. In addition to the general Tivoli Directory Integrator configuration properties, use the following properties to control the synchronization process: For more information about Tivoli Directory Integrator configuration properties, see Tivoli Directory Integrator properties.

    Option Description
    source_ldap_binary_attributes Enables the binary LDAP attributes to be processed properly.

    When the LDAP is Novell eDirectory, the attribute must be set as follows: source_ldap_binary_attributes=GUID

    This attribute is only for sync_all_dns task.

    sync_updates_show_summary_only=true Shows only the records that will be changed, and does not make the changes. The changes are summarized in the following files:

    • employee.adds. Contains a list of the new employee records found in the LDAP to be added to Profiles.

    • employee.updates. Contains a list of the employee records to be updated.

    sync_updates_working_directory=sync_updates The where the working files are stored. The path can be relative to the Tivoli Directory Integrator solution or an absolute path.
    sync_updates_hash_partitions=10 Number of partitions to divide the search base into. The default is sufficient in most cases. If the file size gets too large, this can be increased.
    sync_updates_hash_field=uid Used as the hash value to partition the LDAP search base. The default is sufficient in most cases.
    sync_updates_clean_temp_files=true Deletes temporary files after the synchronization process is complete.
    sync_updates_double_check=false The synchronization process attempts to match the Profiles records based on the mapping value of the uid attribute. When a match cannot be found, a double check can be done to match on the distinguishedName mapping (usually $dn). If that match fails also, and this property is set to true, the user is assumed to no longer be in the LDAP and is deleted.

    These properties can only be used with the sync_all_dns task; they cannot be used with the process_tds_changes and process_ad_changes commands.

  3. Optional: If you are storing data from multiple LDAP branches in the same database, and you want to keep these distinct areas synchronized with the LDAP directory, then you also need to synchronize them separately or distinctly. To accomplish this, you can set the following properties in the profiles_tdi.properties file:

    Option Description
    sync_store_source_url=true Stores the source LDAP URL in the prof_source_url field in the database. The source LDAP URL is needed to determine the source of the data to correctly synchronize it. If a subtree of the LDAP directory is being synchronized, the LDAP URL can fully specify the scope.

    For example: ldap://ghtds01.acme.com:389/cn=users,ou=mm,o=software,dc=ibm,dc=com???(objectclass=inetOrgPerson)

    sync_source_url_override=true Updates the source_url field if it doesn't match when the employee is being updated.
    sync_source_url_enforce=true Synchronizes only those records that have a matching URL. When set to true, it limits the scope of the set of data in the database and skips the records that do not match the source URL. When set to false, it deletes the records that do not match the source URL. The default value is false.

    These properties can only be used with the sync_all_dns task; they cannot be used with the process_tds_changes and process_ad_changes commands.

 

Example

In a scenario in which you have pulled users A, B, and C from ldap_branch1 and users X, Y, and Z from ldap_branch2, your employee table looks as follows:

uid distinguishedName
A ldap_branch1
B ldap_branch1
C ldap_branch1
X ldap_branch2
Y ldap_branch2
Z ldap_branch2

You want to synchronize the ldap_branch2 users, so you set the following properties:

By setting these properties, you get updates for the ldap_branch2 users X, Y, and Z, but not for users A, B, and C. This is because their PROF_SOURCE_URL does not match the Tivoli Directory Integrator property source_ldap_url. When you set sync_source_url_enforce to true, the script skips users A, B, and C. If you had set sync_source_url_enforce to false, this would have deleted users A, B, and C from the database. Supposing you now move the ldap_branch1 users to another branch of the LDAP – ldap_branch3. To do this you set the following properties:

This retrieves the users from ldap_branch3, and finds users A, B, and C but not users X, Y, and Z. It matches users A, B, and C because the hash field is the same. This changes the Profiles database as follows:

uid distinguishedName
A ldap_branch3
B ldap_branch3
C ldap_branch3
X ldap_branch2
Y ldap_branch2
Z ldap_branch2


Updating the LDAP directory

 

Related tasks

Determining the notification language for Profiles

Switching to unique administrator IDs for system level communication

 

Related reference


Tivoli Directory Integrator properties


+

Search Tips   |   Advanced Search