Primary and Secondary Sources

Every LDAP container must include one primary LDAP source. It can also include one or more secondary LDAP sources.

The primary LDAP source identifies the candidate resources that are available to map to groups and positions in the organization models.

If there are secondary LDAP sources defined, they are used to find additional information about each candidate resource.

Lookups are performed into each secondary LDAP source. If an exact match of a candidate resource can be found in every secondary LDAP source, the data from all sources is merged together. This is accomplished using attribute relationships you specify when adding a secondary LDAP source to a container.

The following are reasons you might want to define a secondary LDAP source:

  • The business process needs to access attribute data that is in both the primary and secondary LDAP sources.
  • The business process needs to access attribute data from an LDAP source that is not used for login authentication (the primary LDAP source is always used for authentication).

The Organization Browser constructs the list of candidate resources as follows:

  • It starts with a list of candidate resources from the primary LDAP source.
  • An attempt is made to match those candidate resources with entries in each secondary resource. If an exact match is found in every secondary LDAP source, the data from the secondary sources is merged in with the data from the primary source.

    If a candidate resource is not found inside one or more of the secondary LDAP sources, the candidate resource is eliminated from the list.

    If matches are found in every secondary LDAP source, they must uniquely identify only one LDAP entry in each source. If one or more match multiple items, the item remains in the candidate resources list but is marked as invalid.

As an example, suppose you have two LDAP sources: Acme-Employees and Acme-Developers. The Acme-Employees LDAP source includes sales and support resources, as well as developers. The Acme-Developers LDAP source includes Acme employees who are developers, as well as developer contractors who are not Acme employees. If you want the list of candidate resources to include all Acme employees that are developers, and the business process needs attribute data from both LDAP sources, you would add both sources to one container, using filter criteria to filter out all resources other than Acme developers.

Conversely, if the attribute data needed by the business process is available in one of the LDAP sources, it is much more efficient to include only the one LDAP source in the container.

Also note that when you specify primary and secondary LDAP sources, you can use either an LDAP query or an LDAP group DN to identify the candidate resources to include in the LDAP container. For more information, see LDAP Query Sources and LDAP Group Sources, respectively.

Multiple Entries

When you are defining a secondary LDAP source, you must choose attributes from both the primary and secondary source whose values are compared to determine the final set of resources to include in the LDAP container. The goal is to choose the appropriate attributes so that you know the resources used from the secondary source are exactly the same resources that are in the primary source. If you choose attributes where it cannot make a one-to-one match, you may see a icon in the resource list, and a "Multiple Entries" message next to a resource name:

This could occur, for instance, if you were comparing attributes between the primary and secondary sources that contained only the resource's last name (for example, the sn attribute):

In this particular example, the uid attribute would be a better choice to uniquely identify each resource.

For the procedure to chose the attributes to match resources in the primary and secondary sources, see Defining a Secondary Source Using an LDAP Query (if using LDAP queries) or Defining a Secondary Source Using an LDAP Group (if using LDAP groups).