Configuring LDAP Authentication

To configure LDAP authentication for SBM:

  1. On the General tab, select one of the following options in the Validate user credentials against drop-down list:
    • LDAP
    • LDAP then Internal
    • SSO LDAP
    • SSO LDAP then Internal
    The LDAP sub-tab appears.
  2. In the User sessions are managed by drop-down list, select an applicable session management option. If you selected SSO LDAP or SSO LDAP then Internal, user sessions are managed by Single Sign-On (SSO).
  3. On the LDAP sub-tab, enter the following information:
    • Server

      Specify the server name, IP address, or fully qualified domain name of the LDAP server. If your directory is replicated on more than one server, list each server's name separated by a space. If a replicated server uses a different port than is specified in the Port box on this dialog box, type :portnumber after the server name.

    • Port

      Specify the port number of the directory server. The default setting for LDAP using clear text is 389; the default LDAP port for Secure Sockets Layer (SSL) is 636. You can specify a different port if necessary for your installation.

    • Secure connection
      Select this check box to connect to LDAP via Secure Sockets Layer (SSL). If this check box is selected, the Port setting automatically changes to 636, which is the default LDAP port for SSL. You can alter this value if necessary.
      Tip: SSL is less efficient than the clear text authentication method because response times may be slower. For best results, use the unencrypted bind whenever possible. If your SBM server and directory server are local to one another, it may be unnecessary to use SSL.
    • Certificate location
      This field is enabled if the Secure connection check box is selected. Enter the full path to the certificate on the SBM Application Engine Web Server. This certificate is used by Application Engine for Web service authentication requests that do not have SSO security tokens. SBM accepts the following encoded certificates:
      • A DER-encoded root certificate for the issuer of the LDAP server certificate. If you choose to specify a DER-encoded certificate, it must be the root certificate authority (CA) certificate, and the LDAP server must be configured to transmit all other certificates in the chain of trust during the SSL handshake.
      • A PEM-encoded file that includes the root CA certificate and, optionally, any intermediate CA certificates in the chain of trust. If a multi-step SSL chain of trust must be honored by SBM to connect to LDAP, you can specify a single PEM file that contains the root CA certificate and any intermediate CA certificates. If there are intermediate CA certificates that are not included in this file, the LDAP server must be configured to transmit those certificates during the SSL handshake.
        Important: The LDAP server must not require client authentication, as SBM does not supply a client certificate.
    • Click Managed Trusted Certificates to launch the Certificates window and import, export, or remove trusted certificates from the Java truststore (cacerts file). This enables you to manage multiple certificates in the Java truststore. This option only applies if you are using SSO LDAP.
      Note: You manage your trusted certificates on the server that hosts Single Sign-On (SSO). For distributed installations, ensure that you configure the LDAP security settings for SSO LDAP on the Single Sign-On server. This is where the cacerts file is stored.
    • Search Base

      Type the Directory root at which searching for user information will begin. All nodes at and beneath the base are searched for records of users being authenticated. The search timeout period is 30 seconds.

    • Search Filter
      Select one of the provided search filters or type your own search filter. The search filter is used to authenticate users and for mapping and updating user information. The search filter must contain one or more format specifiers ({0} for the first, {1} for the second—if needed), which are replaced by SBM at runtime with the SBM login ID of the user being authenticated. For example:
      (&(objectClass=user)(sAMAccountName={0}))
      In this case, when user "Joe Smith" attempts to log in, the {0} specifier is replaced by his SBM login ID jsmith and he is authenticated against LDAP. The authentication will succeed if the SBM login ID matches his LDAP sAMAccountName value and he provides the proper password.
    • Follow Referrals
      Select this checkbox to enable LDAP referrals. This feature can enable SBM to locate LDAP user objects on separate servers in the event that some users can not be found in the primary server's LDAP directory. If your LDAP directory entries are split across two or more LDAP servers, the primary LDAP server can be configured to respond to queries in multiple ways:
      • If the primary server enables "chaining", it will automatically search any secondary servers and build a list of responses as though all the entries were on the primary server. In this scenario, SBM does not need to be configured to search other servers.
      • If the primary server does not enable "chaining", it may return "referrals" for the secondary servers. In that case, SBM must either follow the referral by directing a new search request to the secondary server, otherwise SBM will not find any directory entries that are not on the primary server.
      If all of the entries of interest to SBM are on the primary server or if the primary server enables chaining, then SBM does not need to follow referrals; if there are necessary entries on a secondary server and the primary server does not do chaining, then SBM should be configured to follow referrals.
      Note: There are some limitations on how SBM will interact with secondary LDAP servers when following referrals. Because the Search DN and password may only be applicable to the primary server, queries to secondary servers will be performed anonymously. Consequently, the secondary LDAP servers must allow anonymous searching and authentication in order for SBM to follow referrals successfully.
    • Search DN

      Type the distinguished name of an LDAP user account that has permission to search and read other user accounts that are to be authenticated in or imported into SBM. If your LDAP provider allows anonymous searches, this box can be empty. If a DN is provided, however, it must be an active and valid LDAP account located in the same root level directory specified in the Search Base and not in a subordinate container. The DN must be able to search all subordinate containers, so it must be placed in a root level directory that encapsulates the rest of the containers that hold your user accounts.

    • Password

      In the Password box, type the password for the user account specified in the Search DN box. The password is encrypted before it is stored in the SBM database.

    • Test Connection
      • User name

        Type the SBM login ID of a user account to test the provided connection and search parameters settings.

      • Password

        Type the LDAP password of the user account specified in the User name box.

      Click OK to test the connection and search parameter settings. If your authentication test fails, an error message appears and explains the settings that need to be modified.
      Note: You can test connection and search parameter settings without applying them to the database.
  4. Configure password restrictions for external users (if any) on the External Passwords tab. For details, refer to Password Restrictions.
  5. If you want users to access SBM without logging in to your network domain, type the name of an application in IIS with anonymous authentication in the Virtual Directory for external authentication field on the Other Settings tab. For more information, refer to Other Settings.
  6. Click Apply.