PingDirectory

Configuration components

PingDataSync supports the following configuration parameters that determine how synchronization takes place between directories or databases:

Sync Pipe

Defines a single synchronization path between the source and destination topologies. Every Sync Pipe has one or more Sync Classes that control how and what is synchronized. Multiple Sync Pipes can run in a single server instance.

Sync Source

Defines the directory topology that is the source of the data to be synchronized. A Sync Source can reference one or more supported external servers.

Sync Destination

Defines the topology of directory servers where changes detected at the Sync Source are applied. A Sync Destination can reference one or more external servers.

External Server

Defines a single server in a topology of identical, replicated servers to be synchronized. A single external server configuration object can be referenced by multiple Sync Sources and Sync Destinations

Sync Class

Defines the operation types and attributes that are synchronized, how attributes and DNs are mapped, and how source and destination entries are correlated. A source entry is in one Sync Class and is determined by a base DN and LDAP filters. A Sync Class can reference zero or more Attribute Maps and DN Maps, respectively. Within a Sync Pipe, a Sync Class is defined for each type of entry that needs to be treated differently, such as entries that define attribute mappings, or entries that should not be synchronized at all. A Sync Pipe must have at least one Sync Class but can refer to multiple Sync Class objects.

DN Map

Defines mappings for use when destination DNs differ from source DNs. These mappings allow the use of wild cards for DN transformations. A single wild card ("*") matches a single RDN component and can be used any number of times. The double wild card ("**") matches zero or more RDN components and can be used only once. The wild card values can be used in the to-dn-pattern attribute using {1} and their original index position in the pattern, or {attr} to match an attribute value. For example:

**,dc=myexample,dc=com->{1},o=example

Regular expressions and attributes from the user entry can also be used. For example, the following mapping constructs a value for the uid attribute, which is the RDN, out of the initials (first letter of givenname and sn) and the employee ID (eid attribute).

uid={givenname:/^(.)(.*)/$1/s}{sn:/^(.)(.*)/$1/s}{eid},{2},o=example

The following figure illustrates how a nested DIT can be mapped to a flattened structure.

A diagram illustrating the mapping of a nested DIT to a flattened structure.
Attribute Map and Attribute Mappings

Defines a mapping for use when destination attributes differ from source attributes. A Sync Class can reference multiple attribute maps. Multiple Sync Classes can share the same attribute map. There are three types of attribute mappings:

  • Direct Mapping – Attributes are directly mapped to another attribute: For example:

    employeenumber->employeeid

  • Constructed Mapping – Destination attribute values are derived from source attribute values and static text. For example:

    {givenname}.{sn}@example.com->mail

  • DN Mapping – Attributes are mapped for DN attributes. The same DN mappings that map entry DNs can be referenced. For example:

    uid=jdoe,ou=People,dc=example,dc=com.