Setting up LDAP or Active Directory users in Remedy SSO

You can configure the Remedy Single Sign-On server to authenticate TrueSight Presentation Server users through an LDAP server. 

The following topics help you to perform the LDAP/AD configuration tasks in Remedy SSO and create an authorization profile in the TrueSight console:

Related topics

Setting up the Remedy SSO server Open link

Configuring tenants in Remedy SSO

Managing authorization profiles

Role-based access Open link


Before you begin

  • You must have installed and configured the Remedy SSO to work with the Presentation Server and its component products. For details, see  Planning to deploy Remedy SSO Open link   and   Installing Remedy Single Sign-On. Open link
  • You must migrate the internal user data from Atrium SSO to Remedy SSO. For details, see  Migrating internal user data from Atrium SSO to Remedy SSO. Open link
  • You must have set the Remedy SSO general settings. For details, see  Set up the Remedy SSO server. Open link
  • You must have configured tenants to be used with the Presentation Server. For details, see Configuring tenants for the Presentation Server in Remedy SSO.

Configuring LDAP or Active Directory users in Remedy SSO

Before you begin

  • Ensure that you have performed the Remedy SSO server configuration. If you intend to use SASL, it is mandatory to set up the SP details similar to SAML. For more information on server configuration, see Remedy SSO server general configuration.
  • Configure a realm for the authentication. For more information on realm configuration, see Configuring Realms.
  • Ensure that a LDAP server is configured.
  • Import the certificates for the LDAP server to the truststore of Apache Tomcat used by Remedy SSO if you want to use TLS/SSL connection to the LDAP server. For example, JavaHome \jre\lib\security\cacerts, where cacerts is the truststore file. You can use third-party utilities such as KeyStore Explorer to import the certificates
  • Obtain the following information from the LDAP administrator:
    • Host name of the LDAP server
    • Port number of the LDAP server
    • Distinguished name of the bind LDAP user
    • Password of the bind LDAP user
    • Starting location within the LDAP directory for performing user searches
    • User attribute on which search is performed
  • Note that Remedy SSO does not follow referrals. 
  1. (Optional) Click Test to verify the settings.
  2. (Optional) Click Enable Chaining Mode and perform the following steps to enable authentication chaining. For more information about the authentications that you can chain with LDAP, see Authentication chaining.
    1. Click Add Authentication.
    2. Select the required authentication type and enter the authentication details.
    3. Repeat steps a through b to add more authentications for the realm.

LDAP authentication parameters

The following table provides details of the LDAP authentication parameters.

FieldDescriptionVersion
PresetSelect a preset (Active Directory, AD Hierarchical) to fill the LDAP filters with predefined values for the most common LDAP implementations. Use AD Hierarchical to search within nested groups. You may change filters to tune queries as well. 
Server Host

Host's Fully Qualified Domain Name (FQDN) for the LDAP server.

To use SASL, enter only the host name and do not include the domain name. Or enter as host name.local.

 
Server PortPort number for the LDAP server, for example, 389. 
Use TLS connectionSelect to enable TLS to connect to the LDAP server. 
Bind DN

Type the distinguished name (DN) of an LDAP user. For example, CN=User, CN=Users, DC=example, DC=com.

This is the bind distinguished name for querying LDAP and hence this account must have privileges to search the directory.

To use SASL, leave the field as blank as it will be disabled when you select SASL.

 
Bind Password

Enter the password for LDAP user with the bind distinguished name.

To use SASL, leave the field as blank as it will be disabled when you select SASL.

 
Users Base DN

Starting location within the LDAP directory for performing user searches. The search DNs should be as specific as possible for performance reasons. The depth of the search that is performed can be configured. If an object search is specified, then the Base DN should be the DN of the node containing the users.

For example, CN=Users,DC=example,DC=com.

To use SASL, leave the field as blank as it will be disabled when you select SASL.

 
Enable Group RetrievalSelect the check box to enable Remedy SSO to display the groups list for the authenticated user as a part of the login process. It is used by applications such as BMC Atrium Orchestrator for supporting authorization based on Remedy SSO. 
Search ScopeSelect one of the options (One Level, Subtree) to provide the scope for search. 
Use SASL

Select to enable SASL. The fields SASL Mechanism and Quality of Protection are displayed.

Note that if you select Use SASL as the first field, after switching to the Authentication window (omitting all other fields), the fields Bind DN, Bind Password, and Users Base DN are disabled.

Additionally, if Bind DN and Users Base DN are disabled, then manually populate the filters - User Search Filter and Get All Users Filter, and do not use the Preset button. When the Preset button is clicked, the fields Bind DN and Bind Password are enabled and are marked as required.

 
SASL Mechanism

Select a SASL authentication method. You can select one of the following methods:

  • DIGEST-MD5
  • GSSAPI

This field is displayed only if you select Use SASL.

 
Quality of ProtectionSpecify the integrity and privacy protection that SASL mechanism should support. You can select one of the following options:
  • Authentication only
  • Authentication with integration protection
  • Authentication with integrity and privacy protection

This field is displayed only if you select Use SASL.

 
User Authentication
User Search Filter

Enter the LDAP query to search for the user to be authenticated and if found to display the user's distinguished name.

User is specified by $USER$ macro, for example - (&(objectCategory=user)(sAMAccountName=$USER$)).

9.1.03 and later
Identity Attribute

Enter the attribute to be used as a user name. It will be later provided as a user's name to the integrated systems with Remedy SSO.

For example, sAMAccountName.

This field is not displayed if you had selected Use SASL.

 
Get All Users Filter

Enter the LDAP query to display all LDAP users, for example (objectCategory=user).

The filter can be used by integrated application for administration purposes to browse all users in LDAP to be considered as authorization subjects.

 9.1.03 and later
Group Support
Users of Group Filter

Enter the LDAP query to return the groups list for a particular group.

The group is specified by $GROUP$ macro, for example - (&(objectCategory=user)(memberOf=$GROUP$)). Groups information can be used by an integrated application for administration and authorization purposes.

 9.1.03 and later
Groups Base DN

Enter Base DN for group search.

If this is not specified, Users Base DN is used.

9.1.03 and later
Group Search Filter

 Enter the LDAP query to display the list of all groups, for example - (objectCategory=group).

The filter can be used by an integrated application for administration purposes to browse all groups to be considered as authorization subjects.

9.1.03 and later
Group Name Attribute

Enter the attribute to be used as group name.

For example, cn.

9.1.03 and later
Groups of User Filter

Enter the LDAP query to return the list of the groups for a particular user. The user is specified by $DN$ macro. For example,

(&(objectCategory=group)(member=$USER$)).

When the Enable Group Retrieval check box is selected, this is a required field.

This field (Groups of User Filter) can be used by an integrated application for administration purposes to browse the groups for a particular user. In addition, an administrator may use the keyword $DN$.

9.1.03 and later

To configure local authentication for use with App Visibility Manager

Add local authentication if your system includes integration with App Visibility Manager, Synthetic Monitor, or both.

  1. Click Enable Chaining Mode.
  2. By the List of Authentications, click Add Authentication.
  3. From the Authentication Type list, select LOCAL.
  4. Click Save to save the authentication type, and click Save to save the chain of authentication.

To create or edit an authorization profile with LDAP users in the Presentation Server

  1. Log in to the TrueSight console as a Super Admin.
  2. Navigate to Administration>Authorization Profiles.
  3. Create a new authorization profile or edit an existing authorization profile to associate the user groups from Active Directory.
  4. Select the tenant that you configured in Remedy Single Sign-On for Active Directory users and select Edit under User Groups.
  5. Click Add and select the Active Directory user group from the list of user groups.
  6. Select the required roles from the list roles.
  7. (Optional) Select the required objects from the list of object.
  8. Select OK and then Save.
  9. Select Yes to confirm changes to the authorization profile.
  10. Log out of the TrueSight console.
  11. Log in to the TrueSight console as an Active Directory user.
  12. Log in to the Infrastructure Management server as an Administrator and perform the following steps:
    1. Edit the self_collector.mrl file located at /pw/server/etc/<cellname>/kb/collectors/ and add the groups to the permissions that are needed.

      r - Read-only

      w - Write

      x - Execute

    2. Save the self_collector.mrl file.
    3. Recompile the cell using the commands
      mccomp -n <cellname>
      mcontrol -n <cell> restart

Was this page helpful? Yes No Submitting... Thank you

Comments

  1. Ali Khoshkar

    Is there a more refined way to do step 12...? Kind of strange that all the other changes are done in the console but I have to modify a config file manually on the server for this one step. Not everyone has access to the server - a little bit restricting.

    Edit the self_collector.mrl file located at /pw/server/etc/<cellname>/kb/collectors/ and add the groups to the permissions that are needed.

    r - Read-only

    w - Write

    x - Execute

    Save the self_collector.mrl file.

    Recompile the cell using the commands

    mccomp -n <cellname>

    mcontrol -n <cell> restart


    May 13, 2019 03:29
    1. Harihara Subramanian

      Hi Ali Khoshkar,

      Editing an MRL file is supposed to be restricted and therefore, only an Admin user can do that task.

      Some use cases might fail if that step is not performed.

      Jul 18, 2019 05:09