Configure DN maps
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 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.
If a literal '*' is required in a DN then it must be escaped as |
The wild card 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"
matchesdc=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
PingDataSync automatically validates any DN mapping prior to applying the configuration. |