WAS v8.5 > Secure applications > Authenticate users > Select a registry or repository > Configure LDAP user registries

Configure LDAP search filters


Overview

Use the steps below to...

A default set of filters is provided for each LDAP server supported by WAS. If you make and apply changes, the directory type in the Standalone LDAP registry panel changes to custom, to indicate custom filters are being used.


Configure search filters

  1. Log on to the dmgr console and go to...

      Security | Global security | User account repository | Standalone LDAP registry | Configure | Additional properties | Advanced LDAP user registry settings

  2. Modify the user filter, if necessary.

    The user filter is used for...

    • Searching the registry for users
    • Security role-to-user assignment
    • Authenticating a user with the attribute specified in the filter.

    In the following example, the property assigned to %v, which is the short name of the user, must be a unique key. Two LDAP entries with the same object class cannot have the same short name. To look up users based on their user IDs (uid) and to use the inetOrgPerson object class:

      (&(uid=%v)(objectclass=inetOrgPerson)

  3. Modify the Kerberos user filter, if necessary.

    The Kerberos user filter name is used for searching the registry for the Kerberos principal name. Specify the LDAP attribute that holds the Kerberos principal name.

    Filter Attributes
    IBM Lotus Domino default krbuser (&(krbPrincipalName=%v)(objectcategory=Person))
    IBM SecureWay Directory Server default krbuser (&(krbPrincipalName=%v)(objectcategory=ePerson))
    Microsoft Active Directory default krbuser (&(userprincipalname=%v)(objectcategory=user))
    Sun Java System Directory Server default krbuser (&(krbPrincipalName=%v)(objectcategory=inetOrgPerson))
    Novell eDirectory default krbuser (&(krbPrincipalName=%v)(objectcategory=Person))

  4. Optional: If your using Federated Repositories, modify the Kerberos attribute name if necessary. The Kerberos attribute name is used for searching the registry for Kerberos principal. Specify the LDAP attribute that holds the Kerberos principal name.

    Filter Attributes
    IBM Lotus Domino default krbuser filter: krbPrincipalName
    IBM SecureWay Directory Server default krbuser filter: krbPrincipalName
    Microsoft Active Directory default krbuser filter: userprincipalname
    Sun Java System Directory Server default krbuser filter: krbPrincipalName
    Novell eDirectory default krbuser filter: krbPrincipalName

  5. Modify the group filter, if necessary.

    Search registry for groups. Security role-to-group assignment. Specify property by which to look up groups in the directory service.

    In the following example, the property assigned to %v, the short name of the group, must be a unique key. Two LDAP entries with the same object class cannot have the same short name. To look up groups based on their common names (CN) and to use either the groupOfNames object class or the groupOfUniqueNames object class:

  6. Modify the user ID map, if necessary.

    This filter maps the short name of a user to an LDAP entry and specifies the piece of information that represents users when these users are displayed with their short names. For example, to display entries of...

      object class = inetOrgPerson

    ...by their IDs, specify...

      inetOrgPerson:uid

    This field takes multiple objectclass:property pairs, delimited by a semicolon (;). To provide a consistent value for methods like the getCallerPrincipal method and the getUserPrincipal method, the short name that is obtained using this filter is used. For example, the user...

      CN=Bob Smith, ou=austin.ibm.com, o=IBM, c=US

    ...can log in using any attributes that are defined, for example, email address, social security number, and so on, but when these methods are called, the bob user ID is returned no matter how the user logs in.

    Only the getUserDisplayName API honors the user ID map.

  7. Modify the group ID map filter, if necessary.

    This filter maps the short name of a group to an LDAP entry and specifies the 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 (;).

  8. Modify the group member ID map filter, if necessary.

    This filter identifies user-to-group memberships. For SecureWay, and Domino directory types, this field is used to query all groups that match the specified object classes to see if the user is contained in the specified attribute. For example, to get all the users that belong to groups with the groupOfNames object class and the users that are contained in the member attributes, specify...

      groupOfNames:member

    This syntax, which is a property of an object class, stores the list of members that belong to the group that is represented by the object class. This field takes multiple objectclass:property pairs that are delimited by a semicolon (;).

    For the IBM Tivoli Directory Server, Sun ONE, and Active Directory, this field is used to query all users in a group with the information stored in the user object. For example, the memberof:member filter (for Active Directory) is used to get the memberof attribute of the user object to obtain all groups to which the user belongs. The member attribute is used to get all the users in a group that use the Group object. Using the User object to obtain the group information improves performance.

  9. If the LDAP server does not support recursive server-side searches, select the option...

      Perform a nested group search

  10. Modify the Certificate map mode, if necessary.

    We can use the X.590 certificates for user authentication when LDAP is selected as the registry. This field is used to indicate whether to map the X.509 certificates into an LDAP directory user by EXACT_DN or CERTIFICATE_FILTER. If EXACT_DN is selected, the DN in the certificate must exactly match the user entry in the LDAP server, including case and spaces.

    Select the Ignore case for authorization option on the Standalone LDAP registry settings to make the authorization case insensitive. To access the Standalone LDAP registry settings panel...

      Security | Global security | User account repository | Available realm definitions | Standalone LDAP registry

  11. If you select CERTIFICATE_FILTER, specify the LDAP filter for mapping attributes in the client certificate to entries in LDAP. If more than one LDAP entry matches the filter specification at run time, authentication fails because an ambiguous match results. The syntax or structure of this filter is:

      LDAP attribute=${Client certificate attribute} (for example, uid=${SubjectCN})

    The left side of the filter specification is an LDAP attribute that depends on the schema the LDAP server is configured to use. The right side of the filter specification is one of the public attributes in your client certificate. Note the right side must begin with a dollar sign ($), open bracket ({), and end with a close bracket (}). Use the following certificate attribute values on the right side of the filter specification. The case of the strings is important.

    • ${UniqueKey}
    • ${PublicKey}
    • ${IssuerDN}

    • ${Issuer<xx>}

      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}
    • ${Subject<xx>}

      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}

    To enable this field, select CERTIFICATE_FILTER for the certificate mapping.

    Subject alternative names (SANs) are not supported as certificate filter items.

  12. Click Apply.

    When any LDAP user or group filter is modified in the Advanced LDAP Settings panel click Apply. Clicking OK navigates you to the Standalone LDAP registry panel, which contains the previous LDAP directory type, rather than the custom LDAP directory type. Clicking OK or Apply in the Standalone LDAP registry panel saves the back-level LDAP directory type and the default filters of that directory. This action overwrites any changes to the filters made. To avoid overwriting changes, we can take either of the following actions:

    • Click Apply in the Advanced LDAP user registry settings panel. Click Security > Global security and change the User account repository type to Stand-alone custom registry.

    • Select Custom type from the Standalone LDAP registry panel. Click Apply and then change the filters by clicking the Advanced LDAP user registry settings panel. After completing your changes, click Apply or OK.

    The validation of the changes does not take place in this panel. Validation is done when we click OK or Apply on the Global security panel. If you are in the process of enabling security for the first time, complete the remaining steps and go to the Global security panel. Select Standalone LDAP registry as the user account repository. If security is already enabled and any information on this panel changes, go to the Global security panel and click OK or Apply to validate your changes. If your changes are not validated, the server might not start.


Results

These steps result in the configuration of the LDAP search filters. These steps are required to modify existing user and group filters for a particular LDAP directory type. The steps are also used to set up certificate filters to map certificates to entries in the LDAP server.

  1. Validate this setup by clicking OK or Apply on the Global security panel.

  2. Save, stop, and start all the product servers, including the cell, nodes and all of the application servers for any changes in this panel to become effective.
  3. After the server starts, go through all the security-related tasks (getting users, getting groups, and so on) to verify the changes to the filters function.


Related concepts:
Standalone LDAP registries
Local operating system registries
Configure LDAP user registries
Enable security
Migrating a stand-alone LDAP repository to a federated repositories LDAP repository configuration


+

Search Tips   |   Advanced Search