Some complications exist when defining multiple distinguished names (DN) mappings that are used for the same request processor and the same source or target DN or that have source or target DNs that are hierarchically related.
The client request might not include enough information to disambiguate and determine the proper rule to follow.
Several solutions exist to avoid problems of disambiguation. If the client does not need to be able to see all mappings at the same time, then a new client connection policy can be created to use connection criteria that select the set of mappings applied to the client based on information such as the IP address or bind DN. Each client connection policy would have separated subtree views with separate proxying request processors that reference the appropriate transformation for that client.
Alternatively, if it is unnecessary to search under the
o=sample base DN,
then you can create separate subtree views in the same client connection policy. For
example, you would create one subtree view for ou=east,o=sample and
one for ou=west,o=sample. Each subtree view is then associated with
its own proxying request processor, one for
ou=east requests and one for