Synchronize LDAP directory changes with Profiles 

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


Before starting

If your LDAP directory has a data size limitation, consider using the source_ldap_iterate_with_filter property set to true when synchronizing changes from the LDAP directory back to the Profiles database. This property replaces the sync_all_dns_forLarge and collect_dns_iterate scripts.


About this task

The information in Profiles reflects the data that is present in your LDAP directory or other data source. When you need to change or update this information, you update the LDAP directory first and then synchronize the changes to Profiles. 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 and then synchronize the changes to the Profiles database afterwards.

For all LDAP directories, the sync_all_dns task can be used to take changes from the LDAP directory and apply them to the Profiles database. If you want 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 directory search scope with the Profiles database, be sure to allow sufficient time for it to run.

The sync_all_dns task 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 directory 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.

Like the other IBM Tivoli Directory Integrator tasks, the sync_all_dns task has its own log file that shares the same name as the task. You can check the log to see whether the task finishes successfully, and look for error information if necessary. You can also check the ibmdi.log file. This file is a system log that records detailed information about the task when it is run. All the Tivoli Directory Integrator log files are located in the TDI\logs folder.

Note: To keep your profiles synchronized with your LDAP directory, use the generic sync_all_dns command. However, if your LDAP directory is IBM Tivoli Directory Server or Microsoft™ Active Directory, you can use the process_tds_changes or process_ad_changes commands. For more information about synchronizing changes when your LDAP directory is Tivoli Directory Server or Active Directory, see Synchronize IBM Tivoli Directory Server and Microsoft Active Directory LDAP changes.


Procedure

To synchronize LDAP directory 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:

    • IBM AIX or 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, you can set the following properties in the profiles_tdi.properties file to control the synchronization process.

      For more information about Tivoli Directory Integrator configuration properties, see Tivoli Directory Integrator properties.

      Note: With the exception of sync_delete_or_inactivate, 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.

      Option Description
      perform_deletion_for_sync Controls whether extra records in the database are deleted or inactivated as part of the sync_all_dns task. Set this property to true when you want to delete or mark as inactive those users who are no longer in the Profiles database.

      The logic applied when using the perform_deletion_for_sync property works as follows:

      1. Check the value of the property:

        • If perform_deletion_for_sync=false:

          1. Perform neither the delete nor the inactivate action.

        • If perform_deletion_for_sync=true:

          1. Look at the sync_delete_or_inactivate property.

          2. Based on the value of the sync_delete_or_inactivate property (either delete or inactivate), perform the specified action.

      The following list shows sample settings of the perform_deletion_for_sync and sync_updates_show_summary_only properties, and the result of those settings.

        sync_updates_show_summary_only=false
        perform_deletion_for_sync=true

      • Extra records in the Profiles database are deleted during the sync_all_dns task.

          sync_updates_show_summary_only=false
          perform_deletion_for_sync=false

      • Extra records in the database are not deleted during the sync_all_dns task.

          sync_updates_show_summary_only=true
          perform_deletion_for_sync=true

      • Extra records in the database are not deleted during the sync_all_dns task.

          sync_updates_show_summary_only=true
          perform_deletion_for_sync=false

      • Extra records in the database are not deleted during the sync_all_dns task.

      source_ldap_binary_attributes Enables the binary LDAP attributes to be processed correctly.

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

      source_ldap_iterate_with_filter When set to true, this property specifies that the default iterations assembly line must use the collect_ldap_dns_generator.js file to iterate through a set of LDAP search bases and filters.

      This property replaces the sync_all_dns_forLarge and collect_dns_iterate scripts.

      sync_check_if_remove Specifies the name of your deletion double-checking assembly line. By default, the assembly line's name is set to sync_all_dns_check_if_remove. For more information about this property, see Customize the logic used for the delete operation.
      sync_delete_or_inactivate Controls what happens to a user record when the delete action is performed: delete or inactivate. By default, the property is set to inactivate so that users are not deleted. The inactive state is propagated to all the other IBM Connections applications.

      This property can be used with the sync_all_dns, process_tds_changes, and process_ad_changes commands.

      For more information about this property, see Customize the logic used for the delete operation.

      sync_updates_clean_temp_files When set to true, this property deletes temporary files after the synchronization process is completed.
      sync_updates_double_check Uses the custom deletion-checking assembly line that is defined in the sync_check_if_remove_property to perform a double check. The logic of the default double-check assembly line provided by IBM Connections is to match on the distinguishedName mapping (usually $dn). If that match fails, and this property is set to true, the user is assumed to no longer be in the LDAP directory and is deleted.
      sync_updates_hash_field This property is used as the hash value to partition the LDAP directory search base, and its value must be a constant attribute in the LDAP directory. The default of uid is sufficient in most cases.

      If you change the value of uid in the LDAP directory, set this property to a different value that has not changed. For example, if you have not changed the value of email, you can set it to email.

      sync_updates_hash_partitions Number of partitions to divide the search base into. The default of 10 is sufficient in most cases. If the file size gets too large, this value can be increased.
      sync_updates_show_summary_only When set to true, this property shows only the records that need to be changed, but 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 directory to be added to Profiles.

      • employee.delete. Contains a list of the employee records to be deleted.

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

      sync_updates_working_directory The directory where the working files are stored. The path can be relative to the Tivoli Directory Integrator solution directory or an absolute path.

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

      Note: 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.
      Option Description
      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.
      sync_source_url_override=true Updates the source_url field if it doesn't match when the employee is being updated.
      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.

      When storing the sync_store_source_url property in the Profiles database, the data format of prof_source_url in the Profiles database is as follows:

        ldap://{hostname}:port/ldap_search_base?ldap_search_filter


  4. Optional: When the sync_all_dns task is performed, it generates a lock file in the Tivoli Directory Integrator solution directory to prevent other customers from starting another sync_all_dns process in the same Tivoli Directory Integrator solution. The name of the lock file is sync_all_dns.lck. When the sync_all_dns process has finished successfully, the lock file is automatically deleted. However, if the process did not complete in the usual way (for example, using Ctrl+C), the lock file won't be deleted. In this case, you can delete it yourself, or run the clearLock.sh or clearLock.bat file. You can find this file in your Tivoli Directory Integrator solution directory.

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. Updates are not provided for users A, B, and C 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. When you set sync_source_url_enforce to false, users A, B, and C are deleted from the database.

To move the ldap_branch1 users to another branch of the LDAP directory , ldap_branch3, you set the following properties:

This configuration 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 synchronization 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


Parent topic

Manage user data using Tivoli Directory Integrator scripts

Related concepts
Manage users


Related tasks


Synchronize the application member tables and corporate directory
Switching to unique administrator IDs for system level communication
Customize the logic used for the delete operation
Manage user data using Profiles administrative commands
Update Profiles when changing LDAP directory

Related reference
Tivoli Directory Integrator properties
Batch files for processing Profiles data


   

 

});

+

Search Tips   |   Advanced Search