LDAP Configuration - Best Practice

Identity Management

In many companies, identity management is handled by identity providers (IdP).
For small TrendMiner setups, or for new customers, it is recommended to initially use local user management (to shorten the time to value).
For larger or more mature setups, administrators can reduce their administrative overhead of managing TrendMiner by integrating these IdP’s.
- Handle creation/disabling of user accounts automatically (authentication).
- Provide data access rights based on group membership (authorization).
Most companies use some form of Active Directory (LDAP) or SSO (SAML), with SSO becoming the dominant choice.
- Note that for SaaS deployments, only SSO is available

In a typical use case, integration of an IdP intends to accomplish a scenario such as:

Automatically provide engineers and operators TrendMiner access with their standard company login.
Once logged in, they can access (only) their plant’s data (and only their data). This could mean all tags in one specific historian server, or even more granular, a subset of tags within one historian (especially relevant for large, centralized historian servers).
Some super-users or central engineers are granted access to all data to perform global projects.

LDAP Terminology

Directory Information Tree: A directory information tree (DIT) is the hierarchy of entries contained in a directory server.
Distinguished Name: A distinguished name (DN) is a name that uniquely identifies an entry and its position in the DIT. It is comprised of a series of zero or more relative distinguished names (RDNs) separated by commas.
Relative Distinguished Name: A relative distinguished name (RDN) is comprised of one or more attribute name-value pairs. Distinguished names are comprised of zero or more RDNs, but it is common to use the term RDN to refer to the leftmost component of a DN because the attribute values included in the leftmost RDN component for a DN must also be present in the entry referenced by that DN.
Domain Component (DC): DC objects represent the top (root node) of an LDAP tree.
Organizational Unit (OU): OU objects act as containers that hold other objects. They provide structure to the LDAP namespace. OUs are the only general-purpose container available to administrators in Active Directory. The OU object has the ou attribute that’s then typically used as part of the DN.
Common Name (CN): The common name is an object attribute that contains names that define it within the scope of its parent. Each name is one value of this multi-valued attribute. If the object corresponds to a person, it is typically the person's full name.
(Security) Groups: Security groups allow admins to configure authorization for certain tasks and actions to members of the group. A group is usually defined by a CN as the lowest level of its DN.

TrendMiner LDAP Integration

TrendMiner supports LDAP trees with the following sizing:

Up to 10.000 users
Up to 1.000 groups

The configuration has the following characteristics:

Search filters can have up to 4000 characters.
LDAP trees with circular references are not supported.
Disclaimer: Increased complexity of the LDAP tree (many levels, many branches) can have an impact on the target numbers and lead to synchronization issues such as timeouts. More specific queries will always perform better. TrendMiner refers to general best practices.

Integration of identity providers is done through ConfigHub in the Security > Identity providers menu section. A wizard will guide you step-by-step through the configuration. TrendMiner offers flexibility in allowing local and IdP user management side-by-side.

^{Click on image to enlarge}

Once the IdP is configured, data source access is managed through the Security >Access Management menu section. TrendMiner offers flexibility in setting up access on a user level or by group membership. Groups are managed in the Security > Groups menu section.

Example Setups

Example 1

You are licensed to use TrendMiner at one specific location (e.g., a manufacturing site). The manufacturing site has one historian that contains the time series data that engineers, and operators need to access. The available Active Directory structure is illustrated below.

^{Click image to enlarge}

In this example Active Directory structure, we assume that:

We have an Organizational U that contains all “person” objects: i.e., the Organizational Unit (OU) Users.
There are regional, site-based OU’s defined containing security groups.
There is a security group on the site-level OU that has members (engineers, operators…) allowed to access the data.

For this scenario, the best practice is:

The User base and Group base DN should be as close as possible to the relevant sections of the LDAP tree.
You want to provide all Users with TrendMiner access (i.e., login rights).
People from Site 2, members of the trendminersite2 group, should see Site 2's historian, and these people only! (i.e., access rights).

^{Click image to enlarge}

Step 1: Define Login rights

Configure the User base DN to be:
```
ou=Users,dc=company,dc=com
```
Add a Search filter to only select person objects, to avoid clutter in your access management:
```
(objectClass=person)
```

^{Click image to enlarge}

Step 2: Configure groups and define access rights

The closest entry that contains the (only) relevant group, is part of the OU=Site2 sub-OU, so this is the best starting point for the Group base DN.
```
ou=Site2,ou=NAM,dc=company,dc=com
```
The group will automatically be created in the Groups menu section. You can validate the name to use in the next step. It will look like: /LDAP/trendminersite2
In the access management menu section, map the Group to a data source (using the entity name). Groups can be added through their name with auto-complete options available. An example shown below where the entity name is Site2Historian.
```
Entity: Site2Historian

Membership: /LDAP/trendminersite2
```

Example 2

You are licensed to use TrendMiner at three locations (e.g., manufacturing sites Site1, Site2 and Site3). The manufacturing site each have one historian that contains the time series data that engineers, and operators of that site need to access. The available Active Directory structure is illustrated below.

^{Click image to enlarge}

In this example Active Directory structure, we assume that:

The tree is set up in such a way that all “persons” are defined in their geographical location, assigned to a Personnel group per site.
A structure already exists that defines access to historian data, with security groups that have the persons as members.

For this scenario, the best practice is:

The User base and Group base DN should be as close as possible to the relevant sections of the LDAP tree.
Provide all persons in Site 1, 2 and 3 access to TrendMiner based on their membership of the Site OU’s.
Provide each person data access through their membership of the historian access security groups.

^{Click image to enlarge}	Step 1: Define login rights Configure the User base DN to be the lowest common node for users, in this case it would be the NAM OU as it contains the different target sites Site1, Site2 and Site3: OU=NAM,dc=company,dc=com Since this could lead to too many objects being imported, as there could be many more sublayers to the NAM OU, it is best practice to add a Search filter to only select the persons in the relevant groups (*): (&(objectClass=person) (\|(memberOf=CN=Personnel,OU=Site1,OU=NAM,dc=company,dc=com) (memberOf=CN=Personnel,OU=Site2,OU=NAM,dc,company,dc=com) (memberOf=CN=Personnel,OU=Site3,OU=NAM,dc,company,dc=com)))
Note It is not possible to directly filter an OU for membership.
^{Click image to enlarge}	Step 2: Configure groups and define access rights The group base DN again needs to be the lowest common root level from where groups should be accessible. In this case, we can re-use the existing historian access security groups. OU=Historian Access,dc=company,dc=com The three groups will be available in the Groups menu section. In the access management menu section, map each Group to the relevant data source (using the entity names). Groups can be added through their name with auto-complete options available. Entity: Site1Historian, Membership: /LDAP/historiansite1 Entity: Site2Historian, Membership: /LDAP/historiansite2 Entity: Site3Historian, Membership: /LDAP/historiansite3

Example 3

You are licensed to use TrendMiner at many locations around the world. Most sites have one or more historians that contain the time series data that (a subset of) engineers, and operators of that site need to access. There are also a group of central users (from the Data analytics Center of Excellence) that need access to all data sources for global improvement projects. The available Active Directory structure is illustrated below.

^{Click image to enlarge}

In the previous examples, there were easy ways to either define the users that should have access to TrendMiner or define the correct data access through readily available security groups.

In this more complex Active Directory structure, we assume that:

Each site contains both the persons that should have access and the security group that defines their data access.
There is a central group (CoE) with persons that should have access to TrendMiner and to all global data sources.

^{Click image to enlarge}	The first consideration in this case is that we cannot simply use the lowest common root node for users and groups, because in this case, due to the complexity, it would be the root DC node. Synching from the root node will lead to running into the limits for number of allowed users and groups. Secondly, creating a filter will be complex because there are many AND/OR conditions to be combined, leading to an error-prone situation. The filter might potentially even exceed the limit of max. 4000 characters for a search filter. Therefore, we need to consider a different solution.
^{Click image to enlarge}	The best practice in this case is to create a new TrendMiner security group that maps the necessary memberships as the license allows. In this case, a new TrendMiner security group has been created as part of an existing OT applications OU. Relevant groups and members can be added to the TrendMiner group as members (e.g. through the MemberOf attribute of an individual group), meaning the normal management can proceed (no impact on existing structures), and the TrendMiner license and access management is strictly managed through this new object. For example, if a site needs to be added to TrendMiner, the only thing that needs to happen is selecting that site’s Personnel security group and make it member of the TrendMiner security group.
Note An existing group that’s already being used for other applications, e.g. historian access, can be re-used, but only if they would not lead to license violations in terms of entitled capacity.
^{Click image to enlarge}	Step 1: Define login rights Configure the User base DN to be the OT Applications OU that contains the TrendMiner security group. OU=OT Applications,dc=company,dc=com Add a Search filter to only select the persons that are member of the TrendMiner security group. (&(objectClass=person) (memberOf=:1.2.840.113556.1.4.1941:CN=TrendMiner,OU=OT Applications,dc=company,dc=com))
Note Because we nested existing groups in the new TrendMiner group, we need to use the “transitive” magic keyword for the memberOf criterium. This will ensure not only direct membership, but also membership through a nested group is considered. This magic keyword is :1.2.840.113556.1.4.1941:. Note We need to be careful not to add too many users/groups this way – we should add the lowest level, most specific groups only.
^{Click image to enlarge}	Step 2: Configure groups and define access rights Configure the Group base DN to be the lowest level that contains the necessary groups. In this case, it is the root level. dc=company,dc=com Configure the Group search filter to point to the new TrendMiner security group (). (memberOf=CN=TrendMiner,OU=OT Applications,dc=company,dc=com) The groups that were added to the TrendMiner security group as direct members will appear automatically in the Groups menu section(). In the access management, map each Group to the relevant data source (using the entity names). Groups can be added through their name with auto-complete options available. We use the magic ALL keyword to give the CoE access to all datasources. Entity: Site11Historian, Membership: Site11 Personnel Entity: Site12Historian, Membership: Site12 Personnel … Entity: ALL, Membership: CoE Personnel
Note (*) If nested groups are required, the same transitive magic keyword :1.2.840.113556.1.4.1941: should be added to the filter.

In this section:

Documentation Portal

LDAP Configuration - Best Practice

Identity Management

LDAP Terminology

TrendMiner LDAP Integration

Example Setups

Example 1

Example 2

Note

Example 3

Note

Note

Note

Note

Search results