Overview of the attribute and DN mapping

To achieve the merger of the two data sets, create proxy transformations that map the Sample Corporation’s source attributes to Example.com target attributes.

The Example.com schema already defines an attribute to contain the relative distinguished name (RDN) of user entries, called uid. However, Example.com chooses to create two new attributes within its exampleAccount object class to accommodate two attributes in the Sample Corporation schema for representing the region and the distinguished name (DN) of linked accounts.

During the merger, Example.com decides to re-parent the Sample Corporation’s customer entries, which are defined under two different subtrees, ou=east,o=sample and ou=west,o=sample, placing them under Example.com’s ou=people,dc=example,dc=com subtree. Associated proxy transformations are described in the DN Mappings table below. In this process, Example.com collapses the Sample Corporation tree, moving entries from the east and west region under a single DN, dc=example,dc=com. The DN proxy transformations assume that all the Sample Corporation users have been co-located under this single Example.com subtree.

Legacy Sample LDAP applications searching for entries in either the Sample Corporation base DN ou=east,o=sample or ou=west,o=sample will be successfully serviced, though there will be one or more differences in the user entries seen by the Sample Corporation legacy applications.

Because the Example.com directory server has no knowledge of the Sample Corporation user’s former ou=east or ou=west association, search results for client searching under o=sample will return a DN that might differ from the original search base. For instance, a search for sampleID=abc123 under ou=west,o=sample might return the user entry for abc123 with the DN of sampleID=abc123,ou=east,o=sample.

The following table illustrates the mapping DNs.