Define LDAP server details

You can define the details for each of the LDAP servers in your deployment on the LDAP Server Details page.

To define LDAP server details:
  1. On the LDAP Servers page, click the name of the LDAP server you want to modify, or click the Add New link to create a new LDAP server.
    1. xMatters displays the LDAP Server Details page:
  1. On the LDAP Server Details page, specify the following information:

Detail

Description

Name The name of the LDAP server used to identify the server on the LDAP Servers page, and in Users' Web Login details.
Description A brief description of the LDAP server.

Primary Host

IP address of the primary LDAP Server for xMatters.

Primary Port

Port number xMatters should use to communicate with the primary LDAP Server. (The default port for LDAP is 389; the default port for LDAP over SSL is 636.)

Use SSL

When selected, uses the Secure Sockets Layer protocol when communicating with the primary LDAP server.

Secondary Host

IP address of the secondary (failover) LDAP Server for xMatters. For more information about the secondary LDAP server settings, see Secondary LDAP Servers.

Secondary Port

Port number xMatters should use to communicate with the secondary LDAP Server. (The default port for LDAP is 389; the default port for LDAP over SSL is 636.)

Use SSL

When selected, uses the Secure Sockets Layer protocol when communicating with the secondary LDAP server.

LDAP Type

Select one of the following option to specify the type of LDAP server:

  • Simple: Creates a template using the User's xMatters Web Login ID and sends it to the LDAP directory for verification.
  • Anonymous: Queries the LDAP directory for the User's LDAP credentials.
  • Bound: Queries the LDAP directory for the User's LDAP credentials using a bound distinguished name and password.
Base DN

For simple LDAP servers, this value specifies the distinguished name (DN) when it is known, and allows the user web login to be referenced directly as part of the DN by using the special substitution token, %UID% within a template. For example, %UID%@company.com would replace the token %UID% by the Web Login ID from each User’s profile details, effectively using the User's corporate email address as the LDAP login template.

For anonymous or bound LDAP servers, this value specifies the base DN of the FDAP directory branch from which all searches should begin. At a minimum, this value should be set to the top of your LDAP directory tree. For example,

ou=directory,dc=company,dc=com,o=users,ou=mycompany.
Search Filter

Specifies the user search filter, which must be a valid LDAP search filter. This parameter provides greater flexibility in searching because it allows you to put the User Login ID (represented by the special substitution token, %UID%) in any location within the search filter. For more information about this field, see Creating LDAP search filters.

Required for anonymous and bound LDAP servers.

Bind DN

Distinguished name used in conjunction with the password value to bind to the server when searching for entries.

Required for bound LDAP servers only.

Bind Password

Password used in conjunction with the bindDN parameter. Since the bind password is probably sensitive data, it should be properly protected using the APSecure encryption utility.

Required for bound LDAP servers only.

  1. Click Save to apply your settings.

If you have any difficulties configuring your LDAP details, ask Customer Support to review the log file for information about the log in attempts.

Secondary LDAP Servers

In xMatters, the secondary LDAP server settings provide redundancy for failover situations. The secondary server is contacted only if there is a connection failure with the primary server; otherwise, responses from the primary server are considered authoritative.

The following use cases provide examples of how and when xMatters contacts the secondary server.

Login Use Case One

  1. The connection to the primary server succeeds.
  2. An LDAP bind operation is requested for authentication based on the supplied user credentials.
  3. A failed response is returned.
  4. An error message is displayed, indicated that the user credentials are not valid.

Note that xMatters does not attempt to contact the secondary LDAP server based on invalid user credentials.

Login Use Case Two

  1. The connection to the primary server fails.
  2. The connection to the secondary server succeeds.
  3. An LDAP bind operation is requested for authentication based on the supplied user credentials.
  4. A failed response is returned.
  5. An error message is displayed, indicated that the user credentials are not valid.

Login Use Case Three

  1. The connection to the primary server fails
  2. The connection to the secondary server fails.
  3. An error message is displayed, indicating that the server cannot be contacted.

Create an LDAP Base DN

xMatters uses the Base DN setting on the LDAP Server Details page with the login name and password to validate against the LDAP Server. Unlike many applications with LDAP integration, xMatters attempts to log in the user.

For simple LDAP servers, xMatters substitutes the login name supplied by the User for the %UID% in the template configured in the Base DN field on the LDAP Servers page, and sends this and the password making the login request to the LDAP directory. xMatters then examines the result to determine whether the user has valid credentials.

There are three standard formats for these templates:

  • Distinguished Name: If you know the format in which Distinguished Names are stored in your LDAP directory, you can enter the DN format directly in the template field; for example, dc=com,dc=company,ou=directory,uid=%UID%
  • Windows Domain: If you are using a Windows Active Directory Server for your LDAP server, then you will typically use a template in the following format: DOMAIN_NAME/%UID%
  • Internet format: If you are using a Linux/Unix LDAP Server, then you will typically use a template in Internet format: %UID%@company.com

If the User's Web Login ID is not part of the Distinguished Name, you must create either an anonymous or bound LDAP server to query the LDAP directory and bind the DN to the User. For more information, see Creating LDAP search filters.