When you choose to retrieve attribute values from a directory server, you follow this path through the configuration steps.

On the LDAP Directory Search screen you begin to specify the branch of your directory hierarchy where you want PingFederate to look up user data. For more information about each field, refer to the following table:

Field Description
Base DN The base distinguished name of the tree structure in which the search begins. This field is optional if records are located at the root of the directory.
Search Scope The node depth of the query. Select Subtree (the default value), One level or Object.
Root Object Class The object class containing the desired attributes.
Attributes A list of attributes based on the selected Root Object Class value.
  1. Optional: Specify a base DN.
  2. Select a search scope.
  3. Optional: Click View Attribute Contract to determine what attributes to look up.
  4. Select a root object class, select an attribute, and then click Add Attribute.
    Note:

    It is not required to add an attribute here for it to be used as part of a search filter. Add only the attributes that are required by subsequent sibling configuration items, such as contract fulfillment or token authorization. Any added attributes that are left unused will be removed when the configuration is saved.

    Repeat this step to add more attributes as needed.

    Note:

    When connecting to Microsoft Active Directory, if you choose the memberOf attribute, an optional check box, Nested Groups, appears on the right. Select this check box if you want PingFederate to query for groups the end users belong to directly and indirectly through nested group membership (if any) under the base DN.

    For example, suppose you have three groups under a base DN: Canada, Washington and Seattle. Seattle is a member of Washington. Ana Smith is an end user and a member of Seattle. If the Nested Groups check box is selected, when PingFederate queries for Ana's memberOf attribute values, the expected results are Seattle and Washington. (When the Nested Groups check box is not selected (the default), the expected result is Seattle.)

    For Oracle Directory Server or Oracle Unified Directory, choose isMemberOf under Attribute for nested group membership. For information related to the Oracle Directory Server, see documentation about isMemberOf from Oracle (docs.oracle.com/cd/E29127_01/doc.111170/e28967/ismemberof-5dsat.htm). For information related to Oracle Unified Directory, go to the Fusion Middleware Administering Oracle Unified Directory documentation and search for memberof user attributes.

    Tip:

    If you need to include tokenGroups as one of the attributes, select Object as the search scope and enter a Base DN matching the Subject DN of the authenticated user—You can use variables from the authentication source (an adapter or an authentication policy contract) or results from the previous lookup in the Base DN to fulfill this requirement.

Example

Suppose you want to map the sn Active Directory (AD) user attribute into an OpenID Connect policy. The users for this use case reside under a specific container on your directory server, OU=West, DC=example, DC=com.

On the LDAP Directory Search screen, enter OU=West, DC=example, DC=com as the base DN, keep the default Search Scope value (Subtree), select <Show All Attributes> from the Root Object Class list, select the sn AD user attribute, and click Add Attribute.