Advanced Lightweight Directory Access Protocol user registry settings

Advanced Lightweight Directory Access Protocol user registry settings

Use this page to configure the advanced Lightweight Directory Access Protocol (LDAP) user registry settings when users and groups reside in an external LDAP directory.
To view this administrative page:

Click Security > Global security.

Under User account repository, click the Available realm definitions drop-down list, select Standalone LDAP registry, and click Configure.

Under Additional properties, click Advanced Lightweight Directory Access Protocol (LDAP) user registry settings.

Default values for all the user and group related filters are already completed in the appropriate fields. We can change these values depending on the requirements. These default values are based on the type of LDAP server that is selected in the Standalone LDAP registry settings panel. If this type changes, for example from Netscape to Secureway, the default filters automatically change. When the default filter values change, the LDAP server type changes to Custom to indicate that custom filters are used. When security is enabled and any of these properties change, go to the Global security panel and click Apply or OK to validate the changes.
The initial profile creation configures WebSphere Application Server to use a federated repositories security registry option with the file-based registry. This security registry configuration can be changed to use other options, including the stand-alone LDAP registry. Instead of changing from the federated repositories option to the stand-alone LDAP registry option under the User account repository configuration, consider employing the federated repositories option, which provides for LDAP configuration. Federated repositories provide a wide range of capabilities, including the ability to have one or multiple user registries. It supports federating one or more LDAPs in addition to file-based and custom registries. It also has improved failover capabilities, and a robust set of member (user and group) management capabilities. Federated repositories is required when we are using the new member management capabilities in WebSphere Portal 6.1 and above, and Process Server 6.1 and above. The use of federated repositories is required for following LDAP referrals, which is a common requirement in some LDAP server environments (such as Microsoft Active Directory).
IBM recommends that you migrate from stand-alone LDAP registries to federated repositories. If we move to WebSphere Portal 6.1 and above, and or WebSphere Process Server 6.1 and above, you should migrate to federated repositories prior to these upgrades. For more information about federated repositories and its capabilities, read the Federated repositories topic. For more information about how to migrate to federated repositories, read the Migrating a stand-alone LDAP repository to a federated repositories LDAP repository configuration topic.

User filter

Specifies the LDAP user filter that searches the user registry for users.
This option is typically used for security role-to-user assignments and specifies the property by which to look up users in the directory service. For example, to look up users based on their user IDs, specify (&(uid=%v)(objectclass=inetOrgPerson)). For more information about this syntax, see the LDAP directory service documentation.

Information Value
Data type: String

Group filter

Specifies the LDAP group filter that searches the user registry for groups
This option is typically used for security role-to-group assignments and specifies the property by which to look up groups in the directory service. For more information about this syntax, see the LDAP directory service documentation.

Information Value
Data type: String

User ID map

Specifies the LDAP filter that maps the short name of a user to an LDAP entry.
Piece of information that represents users when users display. For example, to display entries of the object class = inetOrgPerson type by their IDs, specify inetOrgPerson:uid. This field takes multiple objectclass:property pairs delimited by a semicolon (;).

Information Value
Data type: String

Group ID map

Specifies the LDAP filter that maps the short name of a group to an LDAP entry.
Piece of information that represents groups when groups display. For example, to display groups by their names, specify *:cn. The asterisk (*) is a wildcard character that searches on any object class in this case. This field takes multiple objectclass:property pairs, delimited by a semicolon (;).

Information Value
Data type: String

Group member ID map

Specifies the LDAP filter that identifies user-to-group relationships.
For directory types SecureWay, and Domino , this field takes multiple objectclass:property pairs, delimited by a semicolon (;). In an objectclass:property pair, the object class value is the same object class defined in the group filter, and the property is the member attribute. If the object class value does not match the object class in the group filter, authorization might fail if groups are mapped to security roles. For more information about this syntax, see the LDAP directory service documentation.
For IBM Directory Server, Sun ONE, and Active Directory, this field takes multiple group attribute:member attribute pairs delimited by a semicolon (;). These pairs are used to find the group memberships of a user by enumerating all the group attributes that are possessed by a given user. For example, attribute pair memberof:member is used by Active Directory, and ibm-allGroup:member is used by IBM Directory Server. This field also specifies which property of an object class stores the list of members belonging to the group represented by the object class. For supported LDAP directory servers, see "Supported directory services".

Information Value
Data type: String

Perform a nested group search

Specifies a recursive nested group search.
Select this option if the LDAP server does not support recursive server-side group member searches and if recursive group member search is required. It is not recommended selected this option to locate recursive group memberships for LDAP servers. Application server security leverages the recursive search functionality of the LDAP server to search a user's group memberships, including recursive group memberships. For example:

IBM Directory Server is preconfigured by the application server security to recursively calculate a user's group memberships using the ibm-allGroup attribute.

SunONE directory server is preconfigured to calculate nested group memberships using the nsRole attribute.

Information Value
Data type: String

Kerberos user filter

Specifies the Kerberos user filter value. This value can be modified when Kerberos is configured and is active as one of the preferred authentication mechanisms.

Information Value
Data type: String

Certificate map mode

Whether to map X.509 certificates into an LDAP directory by EXACT_DN or CERTIFICATE_FILTER. Specify CERTIFICATE_FILTER to use the specified certificate filter for the mapping.

Information Value
Data type: String

Certificate filter

Filter certificate mapping property for the LDAP filter. The filter is used to map attributes in the client certificate to entries in the LDAP registry.
If more than one LDAP entry matches the filter specification at runtime, authentication fails because the result is an ambiguous match. The syntax or structure of this filter is: (&(uid=${SubjectCN})(objectclass=inetOrgPerson)). The left side of the filter specification is an LDAP attribute that depends on the schema that the LDAP server is configured to use. The right side of the filter specification is one of the public attributes in the client certificate. The right side must begin with a dollar sign ($) and open bracket ({) and end with a close bracket (}). We can use the following certificate attribute values on the right side of the filter specification. The case of the strings is important:

${UniqueKey}

${PublicKey}

${IssuerDN}

${Issuerxx}
where <xx> is replaced by the characters that represent any valid component of the Issuer Distinguished Name. For example, you might use ${IssuerCN} for the Issuer Common Name.

${NotAfter}

${NotBefore}

${SerialNumber}

${SigAlgName}

${SigAlgOID}

${SigAlgParams}

${SubjectDN}

${Subjectxx}
where xx is replaced by the characters that represent any valid component of the Subject Distinguished Name. For example, you might use ${SubjectCN} for the Subject Common Name.

${Version}

Avoid trouble: Subject alternative names (SANs) are not supported as certificate filter items.gotcha

Information Value
Data type: String

Related concepts

Federated repositories

Related tasks

Migrate a stand-alone LDAP repository to a federated repositories LDAP repository configuration

Standalone LDAP registry settings