Use these instructions to initiate ways to specify methods for PingFederate to search for particular user data.
On the LDAP Directory Search window, 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.
The base distinguished name (DN) of the tree structure in which the search begins. This field is optional if records are located at the root of the directory.
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.
A list of attributes based on the selected Root Object Class value.
The attribute option for the selected attribute.
Specify a base DN.
Tip: Choose a base DN that is as specific as possible for your search. A broad base DN can result in longer search times and increased network traffic, while a narrow base DN can help ensure that your search is accurate and efficient.
- Select a search scope.
- Optional: Click View Attribute Contract to determine what attributes to look up.
Select a root object class, an attribute, and, optionally, enter an
Option. Click Add Attribute.
You do not have to add an attribute here to use it 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 are removed when the configuration is saved.
- 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, if 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.Important:
Do not enter any value for the Option field. Only the attributes that are defined in the directory server schema can be returned.
- Oracle Directory Server or Oracle Unified Directory
Choose isMemberOf under Attribute for nested group membership. For information related to Oracle Directory Server, go to docs.oracle.com/cd/E29127_01/doc.111170/e28967/ismemberof-5dsat.htm. For information related to Oracle Unified Directory, go to Fusion Middleware Administering Oracle Unified Directory and search for memberof user attributes.
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.
- Microsoft Active Directory
- Repeat step 4 to add more attributes as needed.
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 window, enter
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