Configuring LDAPSync

Edit online

To configure the LDAPSync solution, you must specify the connection settings and properties that control the behavior of the flows.

About this task

The examples in this procedure are based on the following sample scenario:

You must migrate the authentication and authorization data that currently exists on three systems into one central identity store. The three source systems are a Sun Directory Server and two Active Directory domain controllers. After the initial migration of data, the target IBM® Security Directory Server must be synchronized with the changes that occur in the sources.

The following names in the examples identify the different components and flows:

SunFlow is the flow from Sun Directory Server to the target IBM Security Directory Server.
AD1Flow is the flow from the first Active Directory domain controller to IBM Security Directory Server.
AD2Flow is the flow from the second Active Directory domain controller to IBM Security Directory Server.
SDS is the target IBM Security Directory Server for all flows.
SunDS is the source endpoint for the flow named SunFlow.
AD1 is the source endpoint for the flow that is named AD1Flow.
AD2 is the source endpoint for the flow that is named AD2Flow.

Procedure

To specify the connection and configuration settings, edit the LDAPSync solution properties in the LDAPSync.properties file. See LDAPSync properties.
Specify the names for each of the required flows in the global.flows property. The names of the flows must be one word without spaces.
For example:
```
global.flows=AD1Flow,AD2Flow,SunFlow
```
In this example, the property setting defines three flows, which result in three parallel data transfers.

Assign each source endpoint to a flow.

For example:

AD1Flow.source.endpoint=AD1
AD2Flow.source.endpoint=AD2
SunFlow.source.endpoint=SunDS

Specify the target directory for the flows.
As the target is the same for all flows, instead of configuring it individually for each flow, you can use a single property without any flow designation. LDAPSync first looks for flow-specific property settings. If no flow-specific properties are found, then it defaults to the basic non-flow designated properties.
For example:
```
target.endpoint=SDS
```
Specify the connection settings for the target directory server in the LDAPSync.properties file.
For example:
```
ep.SDS.ldap.url=ldap://ed.ewidgets.com:1389
ep.SDS.ldap.user=cn=Directory Manager
{protect}-ep.SDS.ldap.password=secret123a
ep.SDS.ldap.searchBase=dc=ewidgets,dc=com
```
Use the {protect}- token at the beginning of the password property to rewrite the properties file and encrypt this property.

When you specify a property for an endpoint, remove the source. or target. part of the full property name. An endpoint either a source or target; it depends on how you assign it to a flow.
To configure an SSL connection for the target directory server, take the following actions:
1. Specify the ldaps protocol and the port number for the SSL connection in the target.ldap.url parameter setting.
  For example:
```
target.ldap.url=ldaps://ed.ewidgets.com:689
```
2. Set the target.ldap.SSL to true.
  For example:
```
target.ldap.SSL=true
```
3. Specify the keystore in the IBM Security Directory Integrator solution.properties file with the javax.net.ssl.keyStore property.
  For example:
```
javax.net.ssl.keyStore=publicKeys.jks
```
  The file path is relative for publicKeys.jks. The root for relative paths in IBM Security Directory Integrator is the solution directory. Hence, the keystore file is in the solution directory.
4. Import the client certificate from IBM Security Directory Server to the IBM Security Directory Integrator keystore that is used by connectors. You can import certificate import with the keytool.exe program, which is in the jvm/jre/bin directory of the IBM Security Directory Integrator installation folder.
  For example:
```
keytool -import -file SDSclient_cert.der -keystore publicKeys.jks -keypass ew1dg3ts!
```

Specify the connection parameter for the three source endpoints.

For example:

ep.AD1.ldap.url=ldap://dcalpha.acme.com:389
...
ep.AD2.ldap.url=ldap://9.122.14.33:689
...
ep.Sun.ldap.url=ldap://sunds.acme.com:1389
...

Configure the search base for change detection of the Active Directory source endpoints.
For example:
```
ep.AD1.ad.searchBase=dc=acme1.com
ep.AD2.ad.searchBase=dc=acme2.com
```

Specify the type of change detection for each source endpoint.

ep.AD1.changeDetectionType=AD
ep.AD2.changeDetectionType=AD
ep.Sun.changeDetectionType=Sun

Specify the object classes for each entry type, where applicable.
The LDAPSync solution compares the object class attribute of each entry that is read from the source. It compares the attribute with the value of the following three properties to determine whether it is a user, group, or container entry: source.userObjectClass, source.groupObjectClass, and source.container.objectClasses. Sun Directory Server uses default object classes for all entry types. The defaults are inetOrgPerson for person, groupOfUniqueNames for group, and organization, organizationalUnit, dcObject, and country for the container classes. Hence, no property setting is required for this endpoint or flow. However, for Active Directory, you must specify the object classes.
For example:
```
ep.AD1.UserObjectClass=User
ep.AD1.groupObjectClass=Group
ep.AD2.UserObjectClass=User
ep.AD2.groupObjectClass=Group
```

Specify the integration flows and assign the source endpoint for each flow.

For example:

global.flows=SunFlow,AD1Flow,AD2Flow
SunFlow.source.endpoint=Sun
AD1Flow.source.endpoint=AD1
AD2Flow.source.endpoint=AD2

Specify the target directory for all flows. As the target is the same for all flows, you can use just one entry for all flows by using a property name without the flow specifier.
For example:
```
target.endpoint=SDS
```
Define the uid attribute that must be used as the RDN for the IBM Security Directory Server entries. Also, define the object class that must be used to create person and group entries in the IBM Security Directory Server target.
For example:
```
target.userRDN=uid
source.userRDN=cn
target.userObjectClass=inetOrgPerson,ewidgetsPerson
target.groupObjectClass=groupOfUniqueNames
```
In this example, multiple object classes are required to create person entries in the target due to the auxiliary class, ewidgetsPerson. Hence the value is specified as a comma-separated list of object class names.
Specify the following flow-specific settings:
1. Whether the entries must mirror or flatten the source hierarchy.
2. The suffixes under which each flow must write its entries.
3. The mapping file for each entry type of each flow.
In this example, the entries from each source system must be written under different containers in the target directory. To flatten the source hierarchy, the global.preserveSourceContainers property is set to false. To mirror the source hierarchy for some flows and flatten it for other, you can set the global.preserveSourceContainers property for each flow separately.
```
global.preserveSourceContainers=false
SunFlow.suffixForUsers=ou=employees,dc=ewidgets,dc=com
SunFlow.suffixForGroups=ou=groups,dc=ewidgets,dc=com
AD1Flow.suffixForUsers=ou=employeesAD1,dc=ewidgets,dc=com
AD1Flow.suffixForGroups=ou=groupsAD1,dc=ewidgets,dc=com
AD1Flow.person.mapFile=ad_person.map
AD2Flow.suffixForUsers=ou=employeesAD2,dc=ewidgets,dc=com
AD2Flow.suffixForGroups=ou=groupsAD2,dc=ewidgets,dc=com
AD2Flow.person.mapFile=ad_person.map 
```
Ensure that the specified ad_person.map file is present in the LDAPSync directory. If it is not found, an error occurs.

As no specific person map file is configured for the Sun Directory Server flow, it uses the default person map file, person.map, which is set up for mapping between inetOrgPerson schemas.

As no group map is specified for any of the flows, all flows use the default group map file, group.map.
Specify the source containers from which entries must be migrated for each flow. Specify a semicolon-separated list as the value of the source.containersToMigrate property.
For example:
```
AD1Flow.source.containersToMigrate=cn=Users;cn=Groups;cn=Deleted Objects
AD2Flow.source.containersToMigrate=cn=Users;cn=Groups;cn=Deleted Objects
SunFlow.source.containersToMigrate=ou=people;ou=groups
```
In this example, the CN=Deleted Objects container is specified for the Active Directory sources because the scenario requires that delete operations be handled during synchronization.

If there are subcontainers that you do not require, you can also specify source.containersToSkip. Both these values are used for substring comparisons with the DN of an entry to check whether it is in scope or outside the bounds of the solution.
As there is no uid attribute available in the user entries that come from Active Directory, specify that the cn attribute is used for providing this value.
For example:
```
AD1Flow.source.userRDN=cn
AD2Flow.source.userRDN=cn
```
Optional: Modify the mapping rules for person, group, and container entries, which are defined in the files with the extension .map.
Optional: If you want to use custom JavaScript functions in the mapping file, add these functions to the customScript.js file.