When configuring a directory-to-database Sync Pipe, the following are recommended:
Identify the Object Classes
Create a Sync Class per object class, so that they can easily be distinguished and have different mappings and synchronization rules.
For each Sync Class, set the following items in the configuration menus using the
- Set the Include-Filter Property
- Make sure the
include-filterproperty is set on the Sync Class configuration menu to something that will uniquely identify the source entries, such as
- Create Specific Attribute Mappings
- Create an
attribute mappingfor every attribute mapping Matching corresponding attributes between an IdP and an SP to identify federated users or add supplemental user information. LDAPattribute to be synchronized to a database column, add these to a single attribute map, and set it on the Sync Class. With this configured, the script does not need to know about the schema on the directory side. A constructed attribute mapping that maps a literal value to the LDAP (Lightweight Directory Access Protocol) An open, cross platform protocol used for interacting with directory services.
objectClassattribute can be added to the script to determine the database entry type. For example,
"account" -> objectClasscan be added, which would result in the constructed destination LDAP entry always containing an
"account". If needed, a mulit-valued
conditional-value-patternproperty can be used to conditionalize the attribute mapping based on the subtype of the entry or on the value of the attribute.
- Create Specific DN Maps (optional)
- If necessary, create a
distinguished name (DN)map that recognizes the DN's of the source entries and maps them to a desired destination DN. In most cases, the script will use the attributes rather than the DN to figure out which database entry needs to be changed. distinguished name (DN) DN A name uniquely identifying an object within the hierarchy of a directory tree.
- Set auto-mapped-source-attribute to "-none-"
- Remove the default value of "-all-" from the
auto-mapped-source-attributeon the Sync Class configuration menu, and replace it with "-none-."
Configure Create-Only Attributes
Any attributes that should be included when created, but never modified (such as
objectclass) should be specified on the Sync Pipe as a
create-only attribute. If PingDataSync ever computes a difference in that
attribute between the source and destination, it will not try to modify it at the
destination. To avoid bidirectional loop-back, set the
ignore-changes-by-[user|dn] property on both Sync Sources when
configuring for bidirectional synchronization.
Synchronizing DELETE Operations
On PingDirectory Server and Nokia 8661 Directory
Server systems, configure the
changelog-deleted-entry-include-attribute property on the
changelog backend menu using the dsconfig tool. This property
allows for the proper synchronization of DELETE operations. For more information,
see Configure the PingDirectory server backend for synchronizing deletes.
Attribute-Synchronization-Mode for DBSync
For MODIFY operations, PingDataSync detects any
change on the source change log, fetches the source entry, applies mappings,
computes the equivalent destination entry, fetches the actual destination entry, and
then runs a diff between the two entries to determine the minimal set of changes to
synchronize. By default, changes on the destination entry are made only for those
attributes that were detected in the original change log entry. This is configurable
attribute-synchronization-mode property, which sets the
diff operation that is performed between the source and
If the source endpoint is a database server, set the
attribute-synchronization-mode property to
all-attributes on the Sync Class configuration menu. The diff
operation will consider all source attributes. Any that have changed will be updated
on the destination, even if the change was not originally detected in the change
log. This mode is useful when a list of changed columns in the database might not be
available. If both endpoints are directory servers, use the default configuration of
modified-attributes-only to avoid possible replication
Handling MODDN Operations
The concept of renaming an entry (modifyDN) does not have a direct equivalent for
relational databases. The
JDBCSyncDestination API does not handle
changes of this type. Instead, the
modifyEntry() method is called
as if it is a normal change. The extension can verify if the entry was renamed by
looking at the
SyncOperation that is passed in
syncOperation.isModifyDN()). If true, the
fetchedDestEntry parameter will have the old DN. The new DN can
be obtained by calling