WAS v8.5 > Secure applications > Authenticate users > Select a registry or repository

Configure LDAP user registries

To access a user registry using the LDAP, you must know...

Choose any valid user in the user registry that is searchable. We can use any user ID that has the administrative role to log in.

There are two different identities used for security purposes:

When administrative security is enabled, the user ID and password for administrative functions is authenticated with the registry. If authentication fails, access to the admin console is not granted or tasks with wsadmin scripts are not completed. Choose an ID and password that do not expire or change often. If this user ID or password need to change in the registry, verify the changes are performed when all the application servers are up and running.

The server identity is used for internal process communication. As part of this task, we can change the server identity from the default automatically generated ID to a server ID and password from the LDAP repository.

  1. In the admin console, click...

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

  2. Enter a valid user name in the Primary administrative user name field.

    Typically, the user name is the short name of the user and is defined by the user filter in the Advanced LDAP settings panel.

  3. Determine whether to specify the user identity used for internal process communication.

    Cells containing v5.1 or v6.x nodes require a server user identity defined in the active user repository. By default, the option...

      Automatically generated server identity

    ...is enabled, and the application server generates the server identity. However, we can select the Server identity stored in the repository option.

  4. Select the type of LDAP server to use from the Type list.

    The type of LDAP server determines the default filters used by WebSphere Application Server. These default filters change the Type field to Custom, which indicates that custom filters are used. This action occurs after you click OK or Apply in the Advanced LDAP settings panel. Choose the Custom type from the list and modify the user and group filters to use other LDAP servers, if required.

    IBM Tivoli Directory Server users can choose IBM Tivoli Directory Server as the directory type. Use the IBM Tivoli Directory Server directory type for better performance. For a list of supported LDAP servers, see the Supported hardware, software, and APIs website.

    IBM SecureWay Directory Server has been renamed to IBM Tivoli Directory Server in WAS version 6.1.

  5. Enter the fully qualified host name of the LDAP server in the Host field.

    We can enter either the IP address or DNS name.

  6. Enter the LDAP server port number in the Port field.

    The host name and the port number represent the realm for this LDAP server in the WAS cell. If servers in different cells are communicating with each other using LTPA tokens, these realms must match exactly in all the cells.

    The default value is 389. If multiple WASs are installed and configured to run in the same single sign-on domain, or if the WAS interoperates with a previous version of the WAS, then it is important the port number match all configurations. For example, if the LDAP port is explicitly specified as 389 in a version 5.x configuration, and a WAS at version 6.0.x is going to interoperate with the version 5.x server, then verify that port 389 is specified explicitly for the version 6.0.x server.

    To set the value of the realm name placed in the token, set custom property...


  7. Enter the base distinguished name (DN) in the Base distinguished name field.

    The base DN indicates the starting point for searches in this LDAP directory server. For example, for a user with a DN of...

      cn=John Doe, ou=Rochester, o=IBM, c=US

    ...specify the base DN as any of the following options, assuming a suffix of c=us:

    • ou=Rochester, o=IBM, c=us
    • o=IBM, c=us
    • c=us

    For authorization purposes, this field is case sensitive by default. Match the case in your directory server. If a token is received (for example, from another cell or Lotus Domino) the base DN in the server must match exactly the base DN from the other cell or Domino. If case sensitivity is not a consideration for authorization, enable the Ignore case for authorization option.

    In WAS, the distinguished name is normalized according to the LDAP specification. Normalization consists of removing spaces in the base distinguished name before or after commas and equal symbols. An example of a non-normalized base distinguished name is...

      o = ibm, c = us


      o=ibm, c=us

    An example of a normalized base distinguished name is...


    To interoperate between WAS v6.0 and later versions, enter a normalized base distinguished name in the Base Distinguished Name field. In WAS, v6.0 or later, the normalization occurs automatically during runtime.

    Required for all LDAP directories except the Lotus Domino Directory. The Base Distinguished Name field is optional for the Domino server.

  8. Optional: Enter the bind DN name in the Bind distinguished name field.

    The bind DN is required if anonymous binds are not possible on the LDAP server to obtain user and group information. If the LDAP server is set up to use anonymous binds, leave this field blank. If a name is not specified, the application server binds anonymously.

  9. Optional: Enter the password corresponding to the bind DN in the Bind password field.

  10. Optional: Modify the Search time out value.

    Maximum amount of time the LDAP server waits to send a response to the product client before stopping the request. The default is 120 seconds.

  11. Ensure the Reuse connection option is selected.

    The server should reuse the LDAP connection. Clear this option only in rare situations where a router is used to send requests to multiple LDAP servers and when the router does not support affinity. Leave this option selected for all other situations.

  12. Optional: Verify the Ignore case for authorization option is enabled.

    When enabled, the authorization check is case insensitive. Normally, an authorization check involves checking the complete DN of a user, which is unique in the LDAP server and is case sensitive. However, when we use either the IBM Directory Server or the Sun ONE Directory Server LDAP servers, enable this option because the group information that is obtained from the LDAP servers is not consistent in case. This inconsistency affects the authorization check only. Otherwise, this field is optional and can be enabled when a case sensitive authorization check is required. For example, you might select this option when we use certificates and the certificate contents do not match the case of the entry in the LDAP server.

    We can also enable the Ignore case for authorization option when we are using SSO between the product and Lotus Domino. The default is enabled.

  13. Optional. To use Secure Sockets Layer communications with the LDAP server, select the SSL enabled option.

    This step will only be successful provided the Signer certificate for the LDAP is first added to the truststore that will be eventually used. If the Signer certificate from the LDAP is not added to the truststore, then

    • An error will be issued by the Administrative console.

    • The deployment manager (DMGR) systemout.log will show the message...


      ...indicating the Signer certificate needs to be added to the truststore.

    To fix...

    1. Extract the signer certificate of the LDAP to a file
    2. Send that file to the WAS machine
    3. Add the certificate to the truststore defined for the LDAP

    If you select SSL enabled, we can select either...

      Centrally managed Specify the SSL configuration for the particular set of endpoints. The panel...

      ...displays all of the inbound and outbound endpoints that use the SSL protocol. If you expand the Inbound or Outbound section of the panel and click the name of a node, we can specify an SSL configuration used for every endpoint on that node. For an LDAP registry, we can override the inherited SSL configuration by specifying an SSL configuration for LDAP.

      To specify an SSL configuration for LDAP...

      Use specific SSL alias Use only when SSL is enabled for LDAP. The default is DefaultSSLSettings.

      To create a new SSL configuration:

  14. Click OK and either Apply or Save until you return to the Global security panel.


This set of steps is required to set up the LDAP user registry. This step is required as part of enabling security in the WAS.

  1. If you are enabling security, complete the remaining steps as specified in Enable security for the realm.

  2. Save, stop, and restart all the product servers (deployment managers, nodes and appservers) for changes in this panel to take effect. If the server comes up without any problems the setup is correct.


  1. Standalone LDAP registry settings
  2. Standalone LDAP registry wizard settings
  3. Advanced LDAP user registry settings
  4. Configure LDAP search filters
  5. Use specific directory servers as the LDAP server
  6. Locate user group memberships in a LDAP registry
  7. Configure multiple LDAP servers for user registry failover
  8. Test an LDAP server for user registry failover
  9. Delete LDAP endpoints using wsadmin
  10. Update LDAP binding information
  11. Standalone LDAP registry settings
  12. Standalone LDAP registry wizard settings
  13. Advanced LDAP user registry settings
  14. Configure LDAP search filters
  15. Use specific directory servers as the LDAP server
  16. Locate user group memberships in a LDAP registry
  17. Configure multiple LDAP servers for user registry failover
  18. Test an LDAP server for user registry failover
  19. Delete LDAP endpoints using wsadmin
  20. Update LDAP binding information

Related concepts:

Local operating system registries


Select a registry or repository
Enable security
Enable security for the realm


Security custom properties