PingDirectory

Configuration checklist

Before any deployment, determine the configuration parameters necessary for the synchronization topology.

For a better configuration experience, gather the following information before you start your configuration.

External servers

As a best practice, external server definitions should not point at load balancers. Instead, direct connections should be made to the required systems.
External server type

Determine the type of external servers included in the synchronization topology. Supported servers include:

  • PingDirectory server

  • PingDirectoryProxy server

  • Sun Directory Server Enterprise Edition

  • Sun Directory Server

  • Oracle Unified Directory

  • OpenDJ

  • Microsoft Active Directory (AD)

  • Generic LDAP directories

LDAP connection settings

Determine the following for each external server instance included in the synchronization topology:

  • Host

  • Port

  • Bind distinguished name (DN)

  • Bind password

Security and authentication settings

Determine the following:

  • The secure connection types for each external server, such as SSL or StartTLS

  • The authentication methods for external servers, such as simple authentication or external SASL mechanisms

    If you are synchronizing encoded passwords or clear-text passwords in particular, the connection should be secure. To synchronize to or from a Microsoft AD system, establish an SSL or StartTLS connection to PingDataSync. You should also enable password encryption for synchronization from AD or when synchronizing clear-text passwords. For more information, see Configuring password encryption.

Sync Pipes

A Sync Pipe defines a single synchronization path between the source and destination targets. One Sync Pipe is needed for each point-to-point synchronization path defined for a topology.

Sync Source

Determine which external server is the Sync Source for the synchronization topology. You can define a prioritized list of external servers for failover purposes.

Sync Destination

Determine which external server is the Sync Destination for the synchronization topology. You can define a prioritized list of external servers for failover purposes.

Sync Classes

A Sync Class defines how attributes and DNs are mapped and how source and destination entries are correlated. For each Sync Pipe defined, define one or more Sync Classes with the following information:

Evaluation order

If you are defining more than one Sync Class, the evaluation order of each Sync Class must be determined with the evaluation-order-index property. If there is an overlap between criteria used to identify a Sync Class, the Sync Class with the most specific criteria is used first.

Base DNs

Determine which base DNs contain entries needed in the Sync Class.

Include filters

Determine the filters to be used to search for entries in the Sync Source.

Synchronized entry operations

Determine which operations to synchronize:

  • create

  • modify

  • delete

DNs

Determine the differences between the DNs from the Sync Source topology to the Sync Destination topology. For example, if there are structural differences in each directory information tree (DIT).

Destination correlation attributes

Determine the correlation attributes used to associate a source entry to a destination entry during synchronization. During the configuration setup, one or more comma-separated lists of destination correlation attributes are defined and used to search for corresponding source entries. PingDataSync maps all attributes in a detected change from source to destination attributes using the attribute maps defined in the Sync Class.

The correlation attributes are flexible enough that several destination searches with different combinations of attributes can be performed until an entry matches. For LDAP server endpoints, use the DN to correlate entries.

For example, to correlate entries in LDAP deployments, specify the attribute lists dn,uid, uid,employeeNumber and cn,employeeNumber. PingDataSync searches for a corresponding entry that has the same dn and uid values. If the search fails, it then searches for uid and employeeNumber. If that search fails, it searches for cn and employeeNumber. If none of these searches are successful, the synchronization change is aborted and a message is logged.

To prevent incorrect matches, the most restrictive attribute lists (those that will never match the wrong entry) should be first in the list, followed by less restrictive attribute lists, which are used when the earlier lists fail. For LDAP-to-LDAP deployments, use the DN with a combination of other unique identifiers in the entry to guarantee correlation. For non-LDAP deployments, determine the attributes that can be synchronized across the network.
Attributes

Determine the differences between the attributes from the Sync Source to the Sync Destination.

Attribute consideration Description

Attribute mappings

Determine how attributes are mapped from the Sync Source to the Sync Destination.

For example, if they’re mapped directly, mapped based on attribute values, or mapped based on attributes that store DN values.

Automatically mapped source attributes

Determine if there are attributes that can be automatically synchronized with the same name at the Sync Source to Sync Destination.

For example, if you can set direct mappings for cn, uid, telephoneNumber, or for all attributes.

Non-auto mapped source attributes

Determine if there are attributes that shouldn’t be automatically mapped.

For example, the Sync Source might have an attribute, employee, while the Sync Destination has a corresponding attribute, employeeNumber. If an attribute isn’t automatically mapped, you must provide a map to synchronize it.

Conditional value mapping

Determine if some mappings should only be applied some of the time as a function of the source attributes.

You can use conditional value mappings with the conditional-value-pattern property, which conditionalizes the attribute mapping based on the subtype of the entry, or on the value of the attribute.

For example, this might apply if the adminName attribute on the destination should be a copy of the name attribute on the source, but only if the isAdmin attribute on the source is set to true. Conditional mappings are multivalued. Each value is evaluated until one is matched (the condition is true). If none of the conditional mappings are matched, the ordinary mappings is used. If there isn’t an ordinary mapping, the attribute is not created on the destination.