Determining Which Resources to Include

The Organization Browser constructs a list of potential resources.

1. Open the Organization Browser (Accessing the Organization Browser).
2. In the left pane, under the LDAP Containers header, select the LDAP container to which you want to add a secondary LDAP source, then click the icon (or the Edit LDAP Container selection on the Tools menu). The Container Definition dialog is displayed:

   

   In this example, the selected LDAP container has one LDAP source defined (the primary) named “easyAs”.

3. Click the icon (or select New LDAP Source from the Tools menu) to display the Define LDAP Source dialog.
   Note: After an LDAP container is created, and resources have been created in that container, you cannot delete or change the secondary LDAP sources defined for that container, nor add additional secondary LDAP sources to the container. (The only exception is that you can change the value of the Resource Name Attribute for an existing LDAP source.)
4. From the Alias field drop down list, select the secondary LDAP source you would like to add to the LDAP container. (Note that when choosing a secondary source, the alias that was chosen for the primary source is omitted from the Alias field drop-down list.)

   The names in the Alias drop-down list are user-readable names that an administrator has assigned to each of the LDAP Servers available in the enterprise.

5. Optionally, in the Search Base field, enter the branch (e.g., an organization unit) in which you would like to limit the search in the LDAP tree structure. This increases the efficiency of the search if the LDAP contains a large number of branches.

   The search base must provide the complete path to the desired branch in the LDAP tree structure. For example, if you want to limit the search to the “London” organization unit in the following LDAP...

   

   ... you would enter the following in the Search Base field:

   
6. In the Query field, enter a filter string that will be used to determine which of the resources to return from the LDAP source. This allows you to limit the resources returned. For example, you may only be interested in considering resources from a specific department or region.

   It may be helpful to click the Validate Query button at this point, which causes the LDAP Attributes and LDAP Sample Data sections to be displayed and populated with entries from the LDAP source. You can use the information in the LDAP Attributes and LDAP Sample Data sections to see the attributes that are in your chosen LDAP source, as well as the values stored in those attributes.

   Note, however, before clicking the Validate Query button, you may want to change the default query string of “cn=*” (assuming you know the attributes available in the LDAP). The “cn=*” query string causes all records to be returned whose cn attribute contain a value. That query string may not be appropriate for your LDAP source.

   Query strings must be enclosed in parentheses. This allows you to specify multiple strings, each one enclosed in its own parentheses (see the examples below).

   You can use the following special characters with query strings:

   Special Character	Meaning
   *	Wild card character. Matches zero or more of any character.
   &	Logical AND. Returns resources that satisfy the first string AND the second string. Place this special character to the left of the first query string, outside of the parentheses: (&(string1)(string2))
   |	Logical OR. Returns resources that satisfy the first string OR the second string. Place this special character to the left of the first query string, outside of the parentheses: (|(string1)(string2))
   !	NOT. This means that you want all resources that do NOT match the specified value. Place this special character to the left of the query string to which it applies, inside of the parentheses: (!(string))

   Also note that queries are not case sensitive.

   The following are some examples.

   • The following query returns all resources that have “sn” attribute values beginning with “s”:

           (sn=s*)

   • The following query returns all resources that have sn attribute values beginning with “s” or “p”:

           (|(sn=s*)(sn=p*))

   • The following query returns all resources with carlicense attribute values equal to “Full” and employeetype attribute values equal to “Permanent”:

           (&(carlicense=Full)(employeetype=Permanent))

   • The following query returns all resources where sn attribute values don’t start with “s” and don’t start with “p”:

           (&(!(sn=s*))(!(sn=p*)))

     Note: Note that depending on the specific LDAP Server being used, the query syntax can vary. If the syntax described above does not return the expected results, consult the documentation for your LDAP Server.

     Note that the values in a particular LDAP attribute may not be consistent across different LDAP Servers.

     Note: The Resource Names Attribute(s) field on the Define LDAP Source dialog does not have any function when defining a secondary LDAP source.
7. Click the Validate Query button. This causes a list of resources to be returned that satisfy the query specified on the Define LDAP Source dialog. For example:

   

   Notice that on this dialog, the LDAP Attributes section has a Related Primary Attribute column — this column did not appear when you defined the primary LDAP source — it is displayed only when you are defining secondary LDAP sources. The Related Primary Attribute column is used to specify which attributes you want to compare to determine if the resource from the secondary LDAP source should be included in the list of potential resources. This is explained in more detail in later steps.

   Note: If there are LDAP attributes that contain binary data, those attributes may or may not be included in the list of LDAP attributes, depending on the setting of the getBinaryLDAPAttributes parameter in the WCC configuration file (config.xml). For information about this parameter, see the TIBCO Workspace Configuration and Customization guide.
8. At this point, you need to make a determination which attributes in the secondary LDAP source will be compared to attributes in the primary LDAP source.

   The goal of comparing secondary / primary attributes is to ensure that data from the secondary LDAP source is only merged together with the appropriate potential resource from the primary LDAP source.

   Where a match cannot be found, or where it is not one-to-one, the potential resource will not have a complete, accurate set of information, and it will be either omitted (where no match is found) or marked as invalid (where the match isn't one-to-one).

   For example, if there are several resources with the same last name, you need to check more than just the last name; maybe checking first name too will be enough, or maybe you need to check more attributes (because there may be multiple resources in the secondary LDAP source with the same first and last name — it would not know which to include). Maybe there are other types of data, such as an employee ID that would work better and would avoid inconsistencies in data entry (typos, nicknames, abbreviations, etc.).

   You may need to also go back and view the data in the attributes in the primary LDAP source — from the Container Definition dialog, select the primary LDAP source, click the Edit LDAP Source icon (), then click the Validate Query button.

   For this example, we know that the “ou” attribute in the primary LDAP source contains the complete name of the resources (Clint Hill, John Eustace, etc.), the “displayname” attribute in the secondary LDAP source contains the same information. So those attributes would be prime candidates to link in the Related Primary Attribute column.

   Note: If you choose attributes that contain names, always be aware that there may be differences in the way those names were entered in the different LDAP sources, for example, Bob vs. Robert, Mike vs. Michael, or simple misspellings. Things like employee numbers tend to make good attributes to link.
9. In the row for the LDAP attribute you want to relate to the primary source LDAP attribute, click in the Related Primary Attribute column.

   For example, if you want to relate the displayname attribute to an attribute in the primary LDAP source:

   
10. Click in the empty field that is exposed when you click in the column. This displays a list of the attributes available in the primary LDAP source:

    

11. Select the desired attribute from the list. For this example, we will select “ou”:

    

    At this point, you could choose additional attributes to link. To do so, repeat steps 9-11.

    Note: After an LDAP container is created, and resources have been created in that container, you cannot modify the "Related Primary Attributes" that had been defined for the container.
12. When you are finished linking attributes, click Save.

    The Container Definition dialog is displayed, which will now show both of the LDAP sources in the container:

    

    At this point, you could define additional LDAP sources for the container, if desired. To do so, repeat steps 3 through 12.

13. If you are finished defining LDAP sources for the container, click the Save button.
14. In the left pane, select the container you just created.

    The upper-right pane of the Organization Browser is populated with the list of potential resources:

    
15. From the Tools menu on the resource list, select Include Invalid Resources In List.

    This causes the following icon to be shown for any resources for which it was unable to find an exact match in the secondary LDAP source, based on the attributes you specified to link the primary and secondary LDAP sources.

    

    If this icon is shown, it means there are multiple resources in the secondary LDAP source that match the attributes you linked.

    For example, let’s say you linked only the “sn” attribute from both sources, which contains the resource’s last name in both sources, and the following is displayed when you select Include Invalid Resources In List.

    

    This means that Tony Pulis exists in the primary LDAP source, but there is more than one resource in the secondary LDAP source where the “sn” attribute contains the value “Pulis”.

    In this example, you would probably need to specify another attribute in the Related Primary Attribute column (see step 9) to make the relationship more specific.

    If you are not getting the resources you expect, you may also find that data needs to be cleaned up in one or more of the LDAP source because of misspellings, etc.

    Also note that once resources are either created or mapped to a group or position, the resource icon is no longer grayed out:

    	Resource has been created or mapped to a group or position.
    	Resource has not yet been created or mapped.

    For information about mapping and creating resources, see Mapping Resources and Creating Resources.

16. If the “invalid potential resource” icon shown in the previous step is shown for any resources, make the relationship more specific — see step 9.

    Once there are no invalid potential resources, you can do the following:

    • map resources to groups/positions - see Mapping Resources.
    • map resource attributes - see Mapping Resource Attributes.
    • create resources - see Creating Resources.