Skip to main content

Documentation Portal

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.

Example_1i.png

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).

Example_1ii.png

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)
Example_1iii.png

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.

Example_2i.png

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.

Example_2iii.png

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.

Example_2iii.png

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.

Example_3i.png

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.

Example_3ii.png

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.

Example_3iii.png

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.

Example_3iv.png

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.

Example_3v.png

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: