Similar to attribute maps, DN maps define mappings when destination DNs differ from source DNs. These differences must be resolved using DN maps in order for synchronization to successfully take place. For example, the Sync Source could have a DN in the following format:

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

while the Sync Destination could have the standard X.500 DN format.

DN mappings allow the use of wildcards for DN transformations. A single wildcard (*) matches a single RDN component and can be used any number of times. The double wildcard (**) matches zero or more RDN components and can be used only once.

Note:

If a literal '*' is required in a DN, it must be escaped as '\2A'.

The wildcard values can be used in the to-dn-pattern attribute using {1} to replace their original index position in the pattern, or {attr} to match an attribute value. For example:

*,**,dc=com->{1},ou=012,o=example,c=us

For example, using the DN, uid=johndoe,ou=People,dc=example,dc=com, and mapping to the target DN, uid=johndoe,ou=012,o=example,c=us:

  • "*" matches one RDN component, uid=johndoe
  • "**" matches zero or more RDN components, ou=People,dc=example
  • "dc=com" matches dc=com in the DN.

The DN is mapped to the {1},ou=012,o=example,c=us. "{1}" substitutes the first wildcard element "uid=johndoe", so that the DN is successfully mapped to:

uid=johndoe,ou=012,o=example,c=us

Regular expressions and attributes from the user entry can also be used in the to-dn-pattern attribute. For example, the following expression constructs a value for the uid attribute, which is the RDN, out of the initials (first letter of given name and sn) and the employee ID (the eid attribute) of a user.

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

PingDataSync automatically validates any DN mapping before applying the configuration.