Active directory / LDAP
LDAP - Identity Provider Configuration
TrendMiner supports Active Directory / LDAP for authentication. Integration for user- and permission-management is supported. User metadata is synchronized from the directory and groups can be used in TrendMiner's access management.
This document describes the required steps to enable LDAP as Identity provider (IdP) for TrendMiner via Confighub.
Note
How do we switch between LDAP and LDAPs?
We strongly recommend setting up secure LDAP (or LDAPs) from the start.
Looking to switch from LDAP to LDAPs -> follow these instructions:
Import the right certificates (AD Root CA) into ConfigHub (certifications section)
Restart tm-keycloak
Change the URL in the Identity Providers session from ldap:// to ldaps://
Note
ldaps go by default through port 636 (ldap goes through 389), so this one will need to be open.
TrendMiner ConfigHub configuration
Via ConfigHub we can see an overview of the existing Identity Providers and have the ability to configure a new one.
Navigate to ConfigHub and open the "Identity Providers" tab in the "Security" section.
Click the "Add provider"-button.
Select the "Active Directory / LDAP" option.
Create a TrendMiner backup. A backup allows you to rollback to the final non-AD/LDAP state.
Upload a Self-signed certificate if necessary. Self-signed certificates might be necessary if the IDP uses a custom CA certificate over HTTPS.
An AD root CA can be uploaded in the Trusted Certificates section if self-signed certificates are used.
Configure the Active directory / LDAP connection. Users are found by starting at a configurable point in the LDAP tree structure. TrendMiner will then recursively descend the tree and select users thatmatch a given filter.
Name:
Vendor: Choose your vendor from the available list:
Active Directory
Red Hat Directory Server
Tivoli
Novel eDirectory
Other
Provider URL: The hostname of the LDAP server, including the protocol ldap://
Manager DN: Name of LDAP attribute, which is mapped as Keycloak username. For many LDAP server vendors it can be 'uid'. For Active directory it can be 'sAMAccountName' or 'cn'. The attribute should be filled for all LDAP user records you want to import from LDAP to TrendMiner.
Note
This user must have query permissions on the server. Typically a 'service' account with a non-expiring password is used.
Manager password: The password of the Manager DN user.
User base DN: Full DN of LDAP tree where your users are. This DN is the parent of LDAP users. It could be for example 'ou=users,dc=example,dc=com' assuming that your typical user will have DN like 'uid=john,ou=users,dc=example,dc=com'"
Search filter: Additional LDAP Filter for filtering searched users to restrict the users that are permitted access to TrendMiner. Make sure that it starts with '(' and ends with ')' E.g. (objectCategory=Person) will select all users.
Group base DN: The DN of the starting point of tree walking for groups. For example, 'ou=groups,dc=example,dc=org'.
Groups are used for permission management in TrendMiner. This does not influence which users are allowed access.
Username attribute mapping: The name of the attribute that represents the username of the user.
RDN attribute (top attribute): Name of LDAP attribute, which is used as RDN (top attribute) of typical user DN. Usually it is the same as Username LDAP attribute, however it is not required. For example, for Active directory, it is common to use 'cn' as RDN attribute when username attribute might be 'sAMAccountName'.
First name attribute mapping (optional): This attribute points to the user's first name.
Last name attribute mapping (optional): This attribute points to the user's surname or last name.
Email attribute mapping (optional): mail address of the user.
Note
Not providing any email may lock the user out of some TrendMiner functionality like unsubscribing from monitors or in-app guidance.
Test connection: You can use the Test connection functionality to validate your configuration quickly
Configure the server settings:
Sync settings:
Batch size: Count of LDAP users to be imported from LDAP to TrendMiner within a single transaction.
Schedule full sync: Enable a full synchronization of LDAP users to TrendMiner. If scheduled syncs are disabled, no users or groups are available until individual users have logged into the application.
Full sync period (days): Period of full synchronization of LDAP users in days.
Schedule changed users sync: Enable synchronization of new or changed LDAP users to TrendMiner.
Changed users sync period (days): Period of synchronization of changed or newly created LDAP users in days.
Note
A manual sync can be performed by the TrendMiner admin after the configuration is complete.
Connection settings:
Connection timeout: LDAP connection timeout in seconds.
Read timeout: LDAP read timeout in seconds.
The next screen allows to map existing (local) TrendMiner users to the users of the LDAP provider.
The LDAP setup is complete and you should be able to login in TrendMiner.
Active Directory Configuration Examples
Two example configurations are described here. A first case describes a simple configuration where users of one group receive access. A second case describes a more advanced configuration where users of multiple groups receive access.
Consider the following LDAP tree structure:

The Active Directory domain is ‘ad.trendminer.intra’
All users are located under ‘Users AD Domain’. Users of production site A are defined in ‘Users Site A’. Global IT administrators are defined in ‘Users Admin’.
A separate hierarchy defines the roles of each user. All process engineers of Site A are added to a group ‘Process Engineers Site A’. All users that will receive administrative rights in TrendMiner are added in ‘TrendMiner Admins’.

Example 1: Users of one role are granted access.
Users in ‘TrendMiner Admins’ will be granted access to TrendMiner.
Since all users are located under ‘Users AD Domain’, this is a good DN to use as the User base DN in TrendMiner:
OU=Users AD Domain,DC=ad,DC=trendminer,DC=intra
The Search filter defines which users will be granted access. It is an LDAP filter. LDAP filters can include multiple criteria.
One criterion is that the object in the LDAP tree is a user. This is specified as: (objectClass=person)
Furthermore, the object should be a member of the TrendMiner Admins group:
(memberOf=CN=TrendMiner Admins,OU=TM Roles,OU=Roles,DC=ad,DC=trendminer,DC=intra)
Both criteria can be combined with a logical AND operator. This results with a full filter:
(&(objectClass=person)(memberOf=CN=TrendMiner Admins,OU=TM Roles,OU=Roles,DC=ad,DC=trendminer,DC=intra))
Since this is an Active Directory LDAP tree, the username is found in the sAMAccountName property of the user object.
This example can easily be extended to include users of multiple groups by adding a third criterion to the LDAP logical AND.
Example 2: Grant access to users in groups within groups (Active Directory only)
All users in the TrendMiner Users group will be granted access to TrendMiner. The TrendMiner Users group does not contain users directly, but includes users in TrendMiner Admins and in Process Engineers Site A.
Since all users are located under ‘Users AD Domain’, this is a good DN to use as the User base DN in TrendMiner:
OU=Users AD Domain,DC=ad,DC=trendminer,DC=intra
The Search filter defines which users will be granted access. It is an LDAP filter. LDAP filters can include multiple criteria.
One criterion is that the object in the LDAP tree is a user. This is specified as:
(objectClass=person)
The second criterion is that the user is a member of a group that is included in the TrendMiner Users role. The standard LDAP memberOf filter is not sufficient to handle this case. Active Directory provides an extension to the LDAP filter syntax to support this use case:
(memberOf:1.2.840.113556.1.4.1941:=CN=TrendMiner Users,OU=TM Roles,OU=Roles,DC=ad,DC=trendminer,DC=intra)
The full filter becomes:
(&(objectClass=person)(memberOf:1.2.840.113556.1.4.1941:=CN=TrendMiner Users,OU=TM Roles,OU=Roles,DC=ad,DC=trendminer,DC=intra))
Since this is an Active Directory LDAP tree, the username is found in the sAMAccountName property of the user object.