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.
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
Active Directory (AD) Active Directory (AD) AD A directory service for Windows domain networks, included in most Windows Server operation systems.
- Generic LDAP directories
- LDAP connection settings
- Determine the following for each external server instance included in the
- 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 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.
- Determine which external server is the
Sync Sourcefor the synchronization topology. You can define a prioritized list of external servers for failover purposes.
- Determine which external server is the
Sync Destinationfor the synchronization topology. You can define a prioritized list of external servers for failover purposes.
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 Classmust be determined with the
evaluation-order-indexproperty. If there is an overlap between criteria used to identify a
Sync Class, the
Sync Classwith the most specific criteria is used first.
- Base DNs
- Determine which base DNs contain entries needed in the
- Include filters
- Determine the filters to be used to search for entries in the
- Synchronized entry operations
- Determine which operations to synchronize:
- Determine the differences between the DNs from the
Sync Sourcetopology to the
Sync Destinationtopology. 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 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
cn,employeeNumber. PingDataSync searches for a corresponding entry that has the same
uidvalues. If the search fails, it then searches for
employeeNumber. If that search fails, it searches for
employeeNumber. If none of these searches are successful, the synchronization change is aborted and a message is logged.Note:
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.
- Determine the differences between the attributes from the
Sync Sourceto the
Attribute consideration Description
Determine how attributes are mapped from the
Sync Sourceto the
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
For example, if you can set direct mappings for
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 Sourcemight have an attribute,
employee, while the
Sync Destinationhas 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.Note:
You can use conditional value mappings with the
conditional-value-patternproperty, which conditionalizes the
attribute mappingbased on the subtype of the entry, or on the value of the attribute. attribute mapping Matching corresponding attributes between an IdP and an SP to identify federated users or add supplemental user information.
For example, this might apply if the
adminNameattribute on the destination should be a copy of the
nameattribute on the source, but only if the
isAdminattribute 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.