Running LDAPSync

Use the ibmdisrv utility to run the LDAPSync commands to simulate, migrate, and synchronize data between the source and target directories.

Procedure

  1. After you configure the LDAPSync solution settings, you can test the connectivity by running the TestConnections AssemblyLine. Start the IBM® Security Directory Integrator server with command-line arguments to specify the path to the LDAPSync configuration XML file.
     	ibmdisrv –c LDAPSync/LDAPSync.xml –r TestConnections
    This command returns error messages if the connection settings are incorrect. If the connections are successful, messages that are similar to the following example are displayed:
    > Checking for property (ep.Sun.ldap.url) = ldap://9.118.46.245:1389
    > Checking for property (ep.Sun.ldap.user) = cn=Directory Manager
    > Checking for property (ep.Sun.ldap.password) = chirag123lab#
    > Checking for property (ep.Sun.ldap.searchBase) = o=americas,dc=acme.com
    > Initializing SourceLDAP with searchbase: o=americas,dc=acme.com...
    ! success !
    > Searching with SourceLDAP...
    ! success !
    > Checking for property (ep.SDS.ldap.url) = ldap://9.118.46.242:1389
    > Checking for property (ep.SDS.ldap.user) = cn=root
    > Checking for property (ep.SDS.ldap.password) = *******
    > Checking for property (SunFlow.target.ldap.searchBase) = ou=Source1,ou=Oslo,o=sample
    > Initializing TargetLDAP with searchbase: ou=Source1,ou=Oslo,o=sample...
    ! success !
    > Searching with TargetLDAP...
    ! success !
    > Initializing ChangeDetection_SUN with searchbase: cn=changelog...
    ! success !
    > Searching with ChangeDetection_SUN...
    ! success !
    > Reading a change entry with ChangeDetection_SUN ...
    ! success !
    > Checking for property (ep.Sun.ldap.searchBase) = o=americas,dc=acme.com
    > Confirming Source container exists (ep.Sun.ldap.searchBase) = o=americas,dc=acme.com
    > Checking for property (SunFlow.target.ldap.searchBase) = ou=Source1,ou=Oslo,o=sample
    > Confirming Target container exists (SunFlow.target.ldap.searchBase) = 
        ou=Source1,ou=Oslo,o=sample
    > Checking for property (ep.Sun.container.objectClasses) = 
        ou=organizationalUnit, dc=dcObject, c=country, o=organization
    > Checking for property (ep.Sun.containersToMigrate) = ou=Groups;ou=People
    > Checking for property (ep.Sun.userObjectClass) = person
    > Checking for property (ep.Sun.groupObjectClass) = groupofuniquenames
    > Checking for map files
     :
    !SUCCESS! All connections worked correctly!
    If the configuration of LDAPSync specifies multiple flows, then this test is run for each flow.
  2. Run a simulated migration to verify that the LDAPSync solution works as required and that entries would be written correctly to the target directory. You can run a simulation in either one of the following ways:
    • In the LDAPSync.properties file, set the simulate property to input and then run LDAPMigrate.
    • When you run LDAPMigrate from the command line, specify simulate for the argument –0.
      	ibmdisrv –c LDAPSync/LDAPSync.xml –r LDAPMigrate –0 simulate
    The simulated run results in a summary report, but no data is written to the target. The following output is an abbreviated example that shows only the summary for a flow that is labeled SunFlow. If you have more than one flow, the output includes reports for each flow.
     : --> Starting migration for SunFlow -  flattening container hierarchy
      : -->   containers to migrate: ou=Groups;ou=People
      : *** SIMULATED RUN - NO DATA WILL BE MODIFIED ***
      : * showing progress every 25 entries
      : Processing #25    currently working on entry of type: person
      : Processing #50    currently working on entry of type: person
      : > migrating group entries using search filter: (objectClass=groupofuniqu
    enames)
      : **** Simulation Only - no data has been changed in the target ****
      :
    ========= Summary for migration =========
    - Persons    Total: 51  Add:  51
    - Groups     Total: 3  Add: 3
    - Containers Total: 2  Add: 2
    --------------
    Errors: 0
    Warnings: 0
    ===========================
  3. Run LDAPMigrate again to actually migrate of data. When you run LDAPMigrate from the command line, specify actual for the argument –0.
    ibmdisrv –c LDAPSync/LDAPSync.xml –r LDAPMigrate –0 actual
    The actual run usually reports the same results as the simulation, at least for the first time. If subsequent migrations are attempted, IBM Security Directory Integrator detects that entries exist in the target. If the attributes are the same as the values that are read from the source, then unnecessary updates are skipped. The summary still lists the source entries that are processed, but only entries that are new, or entries that are different from the target system are added or modified. When you run LDAPMigrate in actual mode, the ResetChangeState operation is also run.
  4. Schedule the LDAPSync synchronization operations to ensure that the two systems remain synchronized.
    1. Stop the synchronization periodically by setting the timeout value for the source changelog.
      For example:
      source.ldap.changelogTimeout=1800
      This property ensures that if no changes are detected within 1800 seconds (30 minutes), then the synchronization is terminated and can be restarted by the scheduler.
    2. Use the ibmdisrv utility to start a new instance of the server and run LDAPSync. You can use a scheduling program that is provided on your operating system, such as the Windows Task Scheduler or a Cron Job (Scheduled Task) to schedule the synchronization.
      ibmdisrv –c LDAPSync/LDAPSync.xml –r LDAPSync –0 actual
    The LDAPSync does not display the same summary report as LDAPMigrate, but instead logs information each time that a change is detected and processed.
  5. Optional: You might need to reset the change detection state so that only new changes are picked up and transferred.

    For example, either the source or target systems might be restored from a backup or reloaded with data. You might need to run a full migration again. After the migration, the information that LDAPSync stored about the last change that was processed is no longer valid and must be reset. Run the following command to reset the current change state:

    ibmdisrv –c LDAPSync/LDAPSync.xml –r ResetChangeState –0 actual