configuring factorytalk historian se...

CONFIGURING FACTORYTALK HISTORIAN SE SECURITY

Rockwell Automation Publication HSECHS-UM031A-EN-E–September 2013

Supersedes Publication HSECHS-UM030A-EN-E

Customer Support Telephone — 1.440.646.3434 Online Support — http://www.rockwellautomation.com/support/overview.page

© 2013 Rockwell Automation, Inc. All rights reserved. Printed in the USA.

This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation, Inc. Any reproduction and/or distribution without prior written consent from Rockwell Automation, Inc. is strictly prohibited. Please refer to the license agreement for details.

FactoryTalk, FactoryTalk Historian Machine Edition (ME), FactoryTalk Historian Site Edition (SE), FactoryTalk Live Data, FactoryTalk Services Platform, FactoryTalk VantagePoint, FactoryTalk View, FactoryTalk ViewStudio, Rockwell, Rockwell Automation, Rockwell Software, RSView, RSView Machine Edition, RSView ME Station, RSView Studio, and RSLinx Enterprise are trademarks of Rockwell Automation, Inc.

Any Rockwell Automation logo, software or hardware not mentioned herein is also a trademark, registered or otherwise, of Rockwell Automation, Inc.

For a complete list of products and their respective trademarks, go to

http://www.rockwellautomation.com/rockwellautomation/legal-notices/overview.page?%23tab4#/tab4.

ActiveX, Microsoft, Microsoft Access, SQL Server, Visual Basic, Visual C++, Visual SourceSafe, Windows, Windows ME, Windows NT, Windows 2000, Windows Server-, Windows XP, Windows 7, and Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Adobe, Acrobat, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.

ControlNet is a registered trademark of ControlNet International.

DeviceNet is a trademark of the Open DeviceNet Vendor Association, Inc. (ODVA)

OLE for Process Control (OPC) is a registered trademark of the OPC Foundation.

Oracle, SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation.

All other trademarks are the property of their respective holders and are hereby acknowledged.

This product is warranted in accordance with the product license. The product’s performance may be affected by system configuration, the application being performed, operator control, maintenance, and other related factors. Rockwell Automation is not responsible for these intervening factors. The instructions in this document do not cover all the details or variations in the equipment, procedure, or process described, nor do they provide directions for meeting every possible contingency during installation, operation, or maintenance. This product’s implementation may vary among users.

This document is current as of the time of release of the product; however, the accompanying software may have changed since the release. Rockwell Automation, Inc. reserves the right to change any information contained in this document or the software at any time without prior notice. It is your responsibility to obtain the most current information available from Rockwell when installing or using this product.

Contacting Rockwell

Copyright Notice

Trademark Notices

Other Trademarks

Warranty

Configuring FactoryTalk Historian SE Security iii

Table of Contents

Introduction to Historian Server Security .................................................................................... 1

A Brief Look at Historian Server Security ........................................................................... 1 How the Security Model Has Changed .................................................................... 1 What are PI Identities and PI Mappings? ................................................................ 4

Why Use Windows Integrated Security? ............................................................................ 9

Configuring Security on a New Historian Server Installation .................................................. 11

Quick-Start Configuration ................................................................................................. 11 About the Configuration ......................................................................................... 12 How to Configure ................................................................................................... 12 Improve the Quick-Start Configuration .................................................................. 13

Recommended Configuration .......................................................................................... 14 Configure Authentication ....................................................................................... 15 Configure Access Permissions .............................................................................. 21

Other Security Configurations .......................................................................................... 24 Use Local Windows Security ................................................................................. 25 Use Local Windows Security with AD .................................................................... 28 Use PI Users and Groups ...................................................................................... 28

Configure Historian Interface Connections ...................................................................... 30 About Trusts ........................................................................................................... 31 How to Create a Trust ............................................................................................ 31

Configuring Security for Historian Server Upgrades ................................................................ 35

What is in the New Security Model? ................................................................................ 35 Why a New Security Model? ............................................................................................ 36 Your Upgrade Options...................................................................................................... 36

Quick-Start Security Migration ............................................................................... 37 Migrate over Time .................................................................................................. 38 Implement a New Configuration ............................................................................ 46 Keep Existing Configuration .................................................................................. 46

Security for Historian Collectives ............................................................................................... 47

Overview of Security in Historian Collectives ................................................................... 47 Custom Security Configurations ....................................................................................... 48 How to Enable the Lookup-Failure Tuning Parameter ..................................................... 48 Creation of Mappings with a Windows Security ID (SID) ................................................. 49

Tightening Security ...................................................................................................................... 53

Protect piadmin ................................................................................................................ 53

Table of Contents

iv

Disable Explicit Logins for piadmin ........................................................................ 53 Disable Historian Password Authentication (Explicit Logins) ........................................... 54

Disable All Explicit Logins ...................................................................................... 54 Disable Explicit Logins with Blank Passwords ....................................................... 55 Disable Explicit Logins for Individual User Accounts ............................................. 56

Secure piconfig Utility ....................................................................................................... 56 Retire SDK Trusts ............................................................................................................ 56

When Both a Mapping and a Trust Apply .............................................................. 57 Configure SDK Authentication Protocols ............................................................... 57 Disable SDK Trusts................................................................................................ 58

Configure Historian Firewall ............................................................................................. 58 Disable PIWorld ................................................................................................................ 59

How Will FactoryTalk Historian 3.0 Affect My Clients and Interfaces? ................................... 61

Products That Connect Through a Trust .......................................................................... 61 Check for Unauthenticated API Connections ........................................................ 62

Products that Connect to an Application Server .............................................................. 62 Administrative Client Applications .................................................................................... 62

Which Administrative Tools are Compatible with FactoryTalk Historian 3.0 ......... 63 How to Maintain Backwards-Compatible Access Permissions ............................. 63 Change PIUserIncompatible and PIGroupIncompatible Names ........................... 64

MDB to AF Security Synchronization Considerations .............................................................. 65

Task-Based Access Permissions Reference ............................................................................. 67

Product Access Permissions Reference and Configuration Issues ....................................... 71

AF 2.x Client ..................................................................................................................... 72 AF 1.3 Server ................................................................................................................... 73 AF 1.3 Client ..................................................................................................................... 74 ACE .................................................................................................................................. 75 FactoryTalk Historian DataLink ........................................................................................ 76 DataSheet Control ............................................................................................................ 77

PI Groups and DataSheet Control ......................................................................... 78 FactoryTalk Historian BatchView ........................................................................... 79

Historian Notifications....................................................................................................... 81 Historian OLEDB .............................................................................................................. 82 FactoryTalk Historian ProcessBook ................................................................................. 83 RtAlerts ............................................................................................................................. 83 Historian data Services .................................................................................................... 85

Configuring Security for FactoryTalk Historian data Access Products .................. 86 Interfaces .......................................................................................................................... 87

Interfaces that Create Points ................................................................................. 87 Historian to Historian TCP/IP Interface .................................................................. 88 Historian OPC DA/Historian OPC HDA Interfaces ................................................ 89 APS ........................................................................................................................ 91 ICU ......................................................................................................................... 95

Configuring FactoryTalk Historian SE Security v

New SMT Highlights ..................................................................................................................... 99

Checklist: Configure Windows Authentication for Upgrades ................................................ 101

Checklist: Configure Windows Authentication for New Installations ................................... 103

Configuring FactoryTalk Historian SE Security 1

FactoryTalk Historian 3.0 introduced Windows integrated security for the Historian Server, allowing you to manage Historian Server authentication through Windows and Microsoft Active Directory (AD). This new security model improves Historian Server security, reduces your management workload, and provides users a single-sign on experience.

• A Brief Look at Historian Server Security (page 1)

• What are PI Identities and PI Mappings? (page 4)

• Why Use the New Security Model? (page 9)

Note: The Historian Server continues to support previous Historian Server security mechanisms. If you decide not to use the new security model, then no action is required on your part. If you do choose to keep your existing security configuration, you are free to gradually migrate to the new security model at a later date.

A Brief Look at Historian Server Security

Computer security has two parts: authentication (who is the user, and how do we confirm that the user is really who he or she says?) and authorization (once we know who the user is, what is that user allowed to do?).

The Windows integrated security model relies on Windows security for authentication, but provides its own authorization to Historian objects. This is accomplished through two structures: PI identities for which you define PI permissions, and PI mappings which provide the mapping from Windows users and groups to PI identities.

How the Security Model Has Changed

Starting in FactoryTalk Historian 3.0, both the authentication and the authorization mechanisms are different from the mechanisms in earlier versions of the Historian Server. Although the old model continues to be supported, the new mechanisms are more flexible, easier to manage, and more secure.

• Authentication (page 2)

• Authorization (page 4)

Chapter 1

Introduction to Historian Server Security


2

Authentication Before the FactoryTalk Historian 3.0 release, two methods of authentication were available: Trusts and Historian password authentication (also called explicit logins).

• Trusts were typically used for Historian Interfaces, which run unattended. Trust authentication works by comparing the connection credentials of the connecting application to the trust records in the trust database. Human intervention is not required at the time of connection.

• Users connecting to Historian Server through client applications were typically authenticated through explicit logins, which means that the user logs on to Historian Server by typing in a PI user name and password. Explicit logins have a number of drawbacks: They require users to log in separately to Windows and to Historian Server; they require system managers to maintain separate user accounts for every user on Historian Server; and they are not especially secure.



Starting with FactoryTalk Historian 3.0, a third method of authentication becomes available: Windows authentication. With this method of authentication, users log onto their Windows accounts and are automatically authenticated on the Historian Server. Rather than requiring individual user accounts on the Historian Server, in the new model you define user categories, called PI identities, on the Historian Server. You then create mappings from groups of Windows users to the relevant user categories. PI identities and PI mappings are new objects in FactoryTalk Historian 3.0.

This authentication model provides single sign-on for PI users, requires less maintenance for Historian administrators, and significantly increases security over the previous model. Both Trusts and explicit logins remain as authentication mechanisms on the Historian Server. Trusts are still the recommended method for authenticating most interfaces. However, explicit logins are not recommended. They are available to provide backward compatibility.


4

Authorization The new security model includes a much more flexible model for access permissions. In previous versions of the Historian Server you could set permissions only for one owner, one user group, and for world access (everyone else). With the new security model, each Historian Server object can have read and/or write permissions defined for any number of PI identities.

What are PI Identities and PI Mappings?

PI identities and PI mappings are the central components of the new Historian Server security model. They determine which Windows users are authenticated on the Historian Server and what access permissions they have there (for example, is the user allowed to create a point? Run a backup?)

Each PI identity represents a set of access permissions on the Historian Server. Each PI mapping points from a Windows user or group to a PI identity (or a PI user or PI group). You cannot directly grant a Windows user or group access to a Historian Server resource (such as a point or a module). Instead, you create a PI identity that has that access and then you create a PI mapping between the Windows user or group and that PI identity.

Members of the Windows groups that are mapped to a PI identity are automatically granted the access permissions for that PI identity. For example, in the following illustration, the PI identity called PIEngineers has read/write access to the data for the TestTag point. Because the Active Directory (AD) group EngineeringTeam is mapped to PIEngineers, all the members in that AD group get read/write permission for the point data.



Each Historian Server resource (such as the TestTag in the illustration above) can have defined access permissions for any number of PI identities. Although the Windows user gets access permissions through one or more PI identities, the Historian Server keeps track of the specific Windows user ID both in the audit trail and in the last change information.

Note: Although the Historian Server can use Windows security for authentication, you still need to define access permissions explicitly on the Historian Server.

What about PI Users and PI Groups? Previous versions of the Historian Server relied on individual user accounts that could be included in groups. The new security model discourages user accounts (and groups of users) on the Historian Server. They are replaced by PI identities, which provide a layer of abstraction that we can use to make a connection between Windows users and Historian Server access permissions.

For backward compatibility, groups and users are still supported and the standard built-in accounts (such as piadmin and pidemo) are still provided. This allows Historian Servers upgraded to 3 to keep their existing security configurations. It also provides an alternate authentication mechanism if Windows authentication is not a viable option for you.

On FactoryTalk Historian 3.0 and later, PI groups and PI users are implemented as special types of PI identities. The Users and Groups tool in System Management Tools (SMT) is now the Identities, Users, & Groups tool. You can use the PI Users and PI Groups tabs to manage existing users and groups just as you did in earlier versions of the Historian Server.


6

Managing Identities and PI Mappings System Management Tools (SMT) provides tools for configuring and managing PI identities and PI mappings, as well as for other security components. Every Historian Server installation includes SMT.

To manage PI identities, use the Identities, Users, & Groups tool in SMT. By default, separate tabs show identities, users, and groups, but you can display everything in one single list, if you prefer (click the Options button to select display options).

Note: The PI Identities tab appears only if you are connected to at least one Historian Server version 3.0 or later. If not, then only the PI Users and PI Groups tabs appear.

To see what identities you are currently connected as, look at the connection information at the bottom left of SMT. It displays your Windows user ID, followed by the list of your identities (and/or PI users and groups).

If you click the identities, a dialog box tells you how you are connected (for example, through a mapping, a trust or as a default user).

Note: Your Windows account is always displayed, even if you are not connected to the Historian Server through a mapping.



To manage PI mappings in SMT, use the Mappings & Trusts tool. Click the Mappings tab to see all the PI mappings defined for all connected Historian Servers.

Note: The Mappings tab appears only if you are connected to at least one Historian Server version 3.0 or later. If not, then only the Trusts tab appears.

Built-in PI Identities, Users, and Groups The Historian Server includes several built-in PI identities, users, and groups. The most important are:

• piadmin — A PI user with super-user access

• piadmins — A PI group with administrative access

• PIWorld — A PI identity with general access

The following table shows all the built-in PI identities, PI users, and PI groups:

Name Description

piadmin A PI user with super privileges. The piadmin user always has complete read/write access to all Historian Server resources. You cannot modify the access permissions for piadmin. In most cases, you should not map piadmin to any AD group or user. At most, you should map it to a very small group of administrators. Though you cannot delete the piadmin user, you can disable it to varying degrees.

piadmins A PI group intended to represent Historian Server administrators. You can use piadmins for all routine administrative tasks. On new Historian Servers running versions 3.0 and later, this preconfigured group has read and write access to all Historian Server resources and default points. On older versions and on upgrades from older installations, the piadmins group does not have these preconfigured access permissions. You can map piadmins to the AD group that represents your Historian Server system administrators, and you can adjust the piadmins access permissions to meet your needs. You cannot delete the piadmins group and you cannot set up an explicit login for the piadmins group.

PIOperators, PIEngineers, and PISupervisors

Sample identities that have no preconfigured access permissions. These identities do not really do anything. However, you can use them as a starting point, if you like. These sample PI identities are completely configurable. You can delete them, if you like. Only Historian Server versions 3.0 and later include these PI identities.


8

Name Description

piusers A built-in PI group with no preconfigured access permissions.

PIWorld A PI identity with default access permissions for read-only access to most PI resources. The PIWorld identity represents the "everyone" concept of Windows; it specifies the rights of non-explicit users or groups. By default, PIWorld is granted read access to most Historian Server databases and objects. All authenticated Historian Server users are given at least PIWorld privileges. PIWorld is available only on Historian Server version 3.0 and later. You can rename the PIWorld identity and you can change its access permissions. You cannot delete PIWorld. You cannot map PIWorld to an AD group and you cannot use it in a trust.

Note: There is also a hidden user and a hidden group: PIUserIncompatible and PIGroupIncompatible. Historian Server uses them to display an owner and group in older administrative tools that do not support Windows authentication. They do not appear in the list of identities by default. To show them, use the Options button. These PI identities are included only on Historian Servers 3 and later.

The piadmin User The piadmin user is the built-in Historian Server super-user account. As piadmin you have complete access to all objects and operations on the Historian Server, regardless of the security specification. You cannot delete or disable this powerful account.

Previous versions of the Historian Server reserved several maintenance operations for the piadmin account. You could not delegate these operations. This led to the common practice of using the piadmin account for all administrative tasks. This is a dangerous practice because the piadmin account is so powerful.

On version 3.0 and later, the Historian Server reserves no tasks for the piadmin account. You should not use the piadmin account for any normal administrative tasks. Delegate common administrative tasks to piadmins (or to a different PI group or PI identity) and rely on the piadmin account only for exceptional or recovery procedures. See The piadmins Group (page 8).

You should take further steps to protect the piadmin account, if possible. See Protect piadmin (page 53).

The piadmins Group The piadmins group is a built-in PI group intended to represent Historian Server administrators. Rockwell Automation recommends that you use piadmins, rather than the super-user account (piadmin) for common administrative tasks.

On new installations of FactoryTalk Historian 3.0 and later, the built-in PI group called piadmins is granted full administrative access permissions by default, so you need not configure access permissions for it.

Earlier versions of the Historian Server did not grant piadmins administrative access by default and upgrade installations do not change the access permissions for piadmins. On upgraded Historian Servers the piadmins group has whatever access you granted it. You

Why Use Windows Integrated Security?


might need to reconfigure the piadmins access permissions in order to use this PI group for administrative tasks. To do this, add read/write access for piadmins to:

• All database security entries (in SMT)

• All existing points and modules.

See How to Configure Access Permissions (page 22) for more information. You can then map piadmins to the Windows users and/or groups that represent your Historian Server system administrators.

Note: The piadmins PI group was called piadmin on previous versions of the Historian Server. This meant that Historian Servers had both a PI user called piadmin and a PI group called piadmin. The PI group name was changed to piadmins (plural) with the FactoryTalk Historian 3.0 release, in order to prevent conflict with the piadmin user account.

The PIWorld Identity FactoryTalk Historian 3.0 introduces a special built-in PI identity, called PIWorld. The PIWorld identity represents the Everyone concept of Windows; it specifies the rights of non-explicit users or groups. All authenticated Historian Server users automatically get the access permissions defined for PIWorld (in addition to any other access permissions they have been granted).

Note: You can disable PIWorld. If you do that, then users no longer get PIWorld access along with their explicitly-granted access permissions. This can be risky however, especially for upgrades. You might be relying on PIWorld access in a number of places without knowing it. See Disable PIWorld (page 59).

The PIWorld identity replaces the world access of earlier versions of the Historian Server; world access was always granted to all authenticated users, but there was no explicit world user account. On FactoryTalk Historian 3.0 and later, the previously implied world access is now made explicit with the PIWorld identity.

By default, PIWorld is granted read access to most Historian Server databases and objects. The PIWorld identity does not have access to the following tables: PIARCADMIN, PIARCDATA, PIBACKUP, PIMSGSS, PIReplication, PITuning, PIAFLINK, PIAUDIT, PIMAPPING, and PITRUST. You can change the access permissions granted PIWorld, but you cannot delete this identity. The PIWorld identity cannot be used in a mapping or a trust.

Why Use Windows Integrated Security?

Windows-integrated security provides substantial advantages in security, efficiency, and flexibility:

• Less work for Historian Server administrators. You no longer need to create and manage individual user accounts on the Historian Server. When a user enters, leaves, or changes roles, you only need to modify the Windows configuration. Historian Server


10

security automatically reflects these changes. You also get complete traceability of the specific Windows account in the Historian Server log and audit trail records.

• Single-sign on for users. Users need only log on to their Windows account. Historian clients will automatically authenticate through the PI SDK. No additional Historian Server login is required.

• Improved Security: ο Secure authentication. Connections are authenticated through Microsoft's Security

Support Provider Interface (SSPI). If you're using AD, then this means the most secure Kerberos authentication, which greatly improves your Historian Server security.

ο Control over server-side authentication policies. With the new security model, you have control over the authentication protocols that client applications can use to connect to the Historian Server. You can disable authentication methods that are less secure and keep only the connection methods that you need.

• More control over access permissions. The new security model includes a much more flexible model for access permissions. In previous versions of the Historian Server you could set permissions only for one owner, one user group, and for world access (everyone else). With the new security model, each Historian Server resource can have read and/or write permissions defined for any number of PI identities.


This section discusses how to configure security for new Historian Server installations. If you implement one of these configurations now, you are free to make changes at any time.

• Option 1: Quick-Start Configuration (page 11) describes a simple configuration that you can use while you are working on a more comprehensive security configuration plan. While very quick to implement, this configuration is not as secure or as flexible as the recommended configuration. However, options for improving the security and flexibility of this configuration are included. For simple systems, this might be sufficient for your needs.

• Option 2: Recommended Configuration (page 14) explains how to create and implement a custom Historian Server security configuration that uses Microsoft Active Directory (AD) for authentication (but not for Historian access permissions; these are still defined directly on the Historian Server). This is the recommended configuration path.

The above configuration options assume that you are using AD for authentication and that all users are on the same domain or on fully-trusted domains. If the Historian Server will be accessed by client applications across non-trusted domains, then these configurations might be difficult to implement. You can alternatively use local Windows security alone or in conjunction with AD. See Other Security Configurations (page 24) to determine your options.

For instructions on upgrades, see Configuring Security for Historian Server Upgrades (page 35).

Quick-Start Configuration

This configuration provides a quick implementation option that you can use while you are developing a more complete security plan. For very simple systems, you could use this configuration long term; in that case, consider making some adjustments to improve security and increase flexibility.

• About the Configuration (page 12) explains the configuration and how it works.

• How to Configure (page 12) explains how to set it up.

• Improve the Quick-Start Configuration (page 13) explains how you could improve the quick-start configuration to make it more usable for the long term.

Chapter 2

Configuring Security on a New Historian Server Installation


12

About the Configuration

In this configuration you assign two levels of access permissions that apply to all Historian Server resources: users either get read-write or read-only access to everything. In AD, your users should be grouped according to these two levels of Historian Server access. On the Historian Server itself, you need two identities, users, or groups on which to define access: one for read-only access and one for read-write access.

For this quick configuration, we take advantage of two built-in components that have preconfigured access permissions:

• piadmins: piadmins is a built-in PI group that is preconfigured with read-write access to all Historian Server resources. Because we use piadmins, we do not need to explicitly set access permissions for the read-write group. We simply create a mapping between piadmins and the AD group or groups that require read-write access.

Note: piadmins has read-write access to everything on new installations. Upgrades do not automatically reconfigure the access permissions for piadmins, so this configuration option does not work. See Configuring Security for Historian Server Upgrades (page 35).

• PIWorld: PIWorld is a built-in PI identity that is preconfigured with read access to most Historian Server resources. You cannot use PIWorld directly in a mapping. However all authenticated users on the Historian Server get at least PIWorld access. Map an AD group to any PI identity (or PI group or PI user). All the Windows users in that AD group will automatically get the access that is preconfigured for PIWorld. See The PIWorld Identity (page 9) for more on PIWorld.

Note: This configuration relies on PIWorld access. It does not work if you disable PIWorld.

How to Configure

In this very simple model, users either get read-only access to everything on the Historian Server or they get read/write access to everything on the Historian Server. You do not configure different access levels for different PI resources. In AD, your users should be grouped according to these two levels of //// access. (For AD configuration, your company's IT department is probably your best resource.)

Step 1. Configure Authentication:

1. Identify which AD group or groups will have administrator (read/write) privileges on the Historian Server. Identify which groups will have read-only access.

2. Map the AD group that represents Historian administrators to the built-in PI group called piadmins. You can map multiple AD groups to piadmins if needed. Because piadmins has predefined read/write access to all Historian Server configuration and data, all the Windows users in those AD groups will then get that level of access.

Note: Be sure to use the piadmins group and not the piadmin user.

Quick-Start Configuration


3. Map the AD group containing your read-only access users to the built-in PI group piusers. You can map multiple AD groups to piusers if needed. All the Windows users in those groups will be authenticated as piusers. Since all authenticated users get read access through the PIWorld identity, you do not need to explicitly configure access permissions for piusers.

Step 2. Configure Historian Interfaces. See Configure Historian Interface Connections (page 30).

Improve the Quick-Start Configuration

If you plan to base your long-term security configuration on the quick-start configuration, then consider these suggested improvements:

• To make the quick-start security configuration more flexible, you can add PI identities to represent different user categories. For example, you might want to grant IT administrators permission to perform backups. To do that, you create a PI identity and give it the necessary access permissions. Then create a mapping between AD group for the IT administrators and that PI identity.

• To make the quick-start security configuration more secure, you can explicitly set the access permissions for the piusers group, rather than relying on the PIWorld access permissions. In the quick-start configuration we relied on PIWorld in order to make the configuration process quicker and easier. However, it is a better practice to use explicitly-configured access permissions. If you rely on PIWorld, it becomes difficult over time to determine which users or applications are relying on that access.

The following examples demonstrate how to implement each of these suggested improvements.

Example 1. Configure Administrative Access Categories: This example demonstrates how to explicitly configure administrative access to run backups.

1. First create a PI identity called ITAdmins (How to Create a PI Identity (page 17)).

2. Start SMT and connect to the Historian Server as piadmins (for new installations only; for upgrades, connect as piadmin). Open the Database Security tool (select Security > Database Security).

3. In the Database Security tool, give the ITAdmins identity read-write access to the PIBACKUP entry.

Example 2. Configure Access Permissions for piusers. Start SMT and connect to the Historian Server as piadmins. Open the Database Security tool (select Security > Database Security).

1. For every entry in the Database Security tool, set the access permissions for piusers to read-only. See Set Permissions in the Database Security Tool (page 23).

2. Set permissions for built-in points. The Historian Server installation includes several default points. These are useful for test purposes. To explicitly grant read access to the piusers group, edit the points themselves. You can do this using Point Builder or Tag Configurator, both available in SMT (Set Permissions on Specific Points and Modules (page 23)).


14

When you create new points, the piusers group will automatically have read-only access. This is because new points automatically have the same access permissions as the PIPOINT entry in the Database Security tool. See Set Default Access for New Points and Modules (page 23) for instructions.

3. Set permissions for existing modules. At a minimum, the Historian Server installation includes the built-in module %OSI. Depending on what client applications you have installed, there might be others. To explicitly grant read access to the piusers group, edit the modules themselves. You can do this using the Module Database tool in SMT.

When you create new modules, the piusers group will automatically have read-only access. This is because new modules automatically have the same access permissions as the PIModules entry in the Database Security tool. See Set Default Access for New Points and Modules (page 23) for instructions.

Recommended Configuration

These instructions assume that you are using Microsoft Active Directory (AD) for authentication. You can use local Windows security instead, but it is not quite as secure and extra configuration is required. See Use Local Windows Security (page 25).

To configure Historian Server security with AD authentication (each step is explained in more detail in the following sections):

1. Configure User Authentication. In most cases this simply means creating a PI identity for each AD group that requires Historian access and creating a mapping between them.

a. Identify User Access Categories: Identify the users who need access to the Historian Server. Understand their roles, and the types of access they need. For example: who needs permission to create points? Who should be allowed to edit modules? Who will perform Historian Server Backups? See Identify User Access Categories (page 15).

a. Create PI Identities: On the Historian Server, create PI identities for each user category. See Create PI Identities (page 17).

b. Review Active Directory Groups: In Windows, identify Active Directory groups that represent your Historian Server users. In some cases you might need the help of your domain administrator in order to create new groups, nest existing groups, or adjust group memberships. See Review AD Configuration (page 17).

c. Map AD Groups to Identities: Once you have the necessary AD groups and PI identities, the next step is to set up a mapping between them. See Map AD Groups to PI Identities (page 20).

2. Configure Access Permissions. Give your PI identities access to the necessary Historian Server resources. The access permissions specify what tasks each PI identity is allowed to perform on the Historian Server. See Configure Access Permissions (page 21).

3. Configure Historian Interface (and Historian Client) access to the Historian Server.

a. Configure access for Historian Interfaces: You need to set up Trusts for interfaces that will connect to the Historian Server. Each trust is defined against a PI identity



that has the required access permissions for that interface. See Configure Historian Interface Connections (page 30) for instructions on creating Trusts for interfaces.

b. Configure access for client applications (optional): Client applications typically connect to the Historian Server using PI SDK. You need SDK 1.3.6 or later to use Windows authentication. Certain Historian client applications require a connection to a separate application server in addition to a Historian Server. These types of applications require additional configuration steps. See How Will FactoryTalk Historian 3.0 Affect My Clients and Interfaces? (page 61) for more information.

There are a number of things you can do to provide extra security for your Historian Server. See Tightening Security (page 53) for suggestions and instructions.

Configure Authentication

This section discusses the recommended approach to configuring your Historian Server authentication.

Note: If you already know which AD group or groups will have Historian Server access, then you can simply create a PI identity for each of these groups and map each AD group to the appropriate identity.

To configure Historian Server authentication, follow these steps:

• Identify User Access Categories (page 15)

• Create PI Identities (page 16)

• Review AD Configuration (page 17)

• Map AD Groups to PI Identities (page 20)

Identify User Access Categories The first step in the security configuration is to determine:

• Who needs to use the Historian Server?

• What Historian Server resources do they need to access?

• What level of access do they need for each resource? (Read access? Read/write access?)

Define categories of users that need the same set of access permissions. These will be your PI identities. You can have as many categories as you want. Typical Historian installations start from one of the following basic models:

• Two category model: operators/admins

Historian Server users are divided into two categories, which we refer to here as operators and administrators. The operator category gets read-only access to all Historian Server resources. The administrator category gets read/write access to all Historian Server resources.

• Three category model: operators/admins/ITadmins


16

This model adds a third category, which we will refer to as IT administrators. The IT administrator category has read-write access to only a subset of Historian Server resources. This model allows you to give separate access permissions to IT administrators for some tasks such as backups.

• Four category model: operators/admins/ITadmins/engineers

In this model, we add an engineers category. The engineers category gets read/write access to the point database and the module database, allowing them to create and delete modules and points. However, the engineers category does not get permissions for administrative tasks, such as managing identities, users, and groups.

These category models are presented as examples. You can adjust them to suit your needs or you can use your own strategy entirely. In some cases you might need a higher level of granularity in the access permissions. For example, different categories of users might need to be able to read from, write to, or configure different points.

Create PI Identities Once you have identified user categories, you designate a PI identity or group for each category. You can create your own PI identities, or you can use some of the built-in PI identities and groups that are included in the Historian Server installation (Built-in Identities, Users, and Groups (page 7)).

Most of these are sample identities, not configured with access permissions. However the piadmins group is preconfigured with read/write access to all Historian Server resources. Using piadmins for your main administrator category can save you some configuration time.

The following example shows you how you might use built-in PI identities for the four user categories described in Identify User Access Categories (page 15).

• Users: Use the built-in PI group called piusers. This group does not have any preconfigured access permissions, so you will have to set those manually. As a short-cut you could rely on the PIWorld access permissions, rather than explicitly setting permissions for piusers. However, this model is less secure. See The PIWorld Identity (page 9).

• Engineers: Use the built-in PI identity called PIEngineers. This identity does not have any preconfigured access permissions, so you will have to set those manually.

• Administrators: Use the built-in PI identity called piadmins. By default, this identity has read/write access to all Historian Server resources. You can adjust these access permissions as needed.

• IT Administrators: Create a PI identity called ITAdmins. You will need to set the access permissions manually.

Creating PI identities is just the first step. You also need to:

• Map each AD group to the appropriate PI identity (Map AD Groups to PI Identities (page 20)).

• Configure access permissions for each PI identity (Configure Access Permissions (page 21)).



How to Create a PI Identity To create a new PI identity in SMT:

1. Under Collectives and Servers, select a server.

2. Under System Management Tools, select Security > Identities, Users, & Groups.

3. Select the PI Identities tab.

4. Click the New Identity button to open the New Identity dialog box, where you can create and configure a new PI identity.

5. In Identity, type in a name for the new identity. This is the only field that is required to create a new identity. Note the following restrictions on identity names:

ο The name must be unique. ο The name cannot include the vertical pipe (|) character or the colon (:) character. ο The name cannot be a positive integer, although it can contain numbers. For example,

the name 407 is not valid, but the name Admins407 is valid. ο The name is not case sensitive.

If you try to create an identity with an invalid name, an error message appears and the identity is not created. Note that you can change an identity name any time after creation.

6. Select the appropriate server from the drop-down Server list. This list is populated from the selected servers under Collectives and Servers. Only version 3.0 and later Historian Servers appear in the list. Earlier versions of the Historian Server do not support PI identities.

7. Optionally, enter a brief description in Description. There are no restrictions on the contents of this field.

8. At the bottom of the dialog box, select the Identity cannot be deleted check box. This prevents the identity from being accidentally deleted. In order to delete this identity, you must first edit the identity and clear this check box.

9. Click Create. The new PI identity now appears in the PI Identities tab.

Review AD Configuration In most cases you can rely on existing AD groups and you will not need to do any AD configuration. Work with your Windows domain administrator to review existing groups and make any necessary adjustments.

Note: Although the Historian Server can use AD for authentication, it does not use Windows access permissions to determine Historian Server access levels. You still have to set access permissions explicitly on the Historian Server.

Follow these guidelines:

• Make sure you have appropriate AD groups for each type of Historian Server user. For each PI identity, you should ideally have a single corresponding AD group. Users that belong to more than one AD group get the cumulative access permissions for all the associated PI identities.


18

• Review your AD group memberships to ensure that all Windows users will get the appropriate Historian Server permissions (Historian Server Access Permissions and AD (page 18)).

• Establish a naming convention for PI identities and/or AD groups so that it is clear which group is mapped to which identity. Over time, you will be able to control user access to the Historian Server simply by editing group memberships in AD or Windows

Once you have a workable set of AD groups, you are ready to map AD groups to PI identities.

Note: If your current AD groups do not suffice and you cannot get your AD domain administrator's support, use a simple workaround: Create local Windows groups on your Historian Server and then place existing AD groups within the local groups. See Other Security Configurations (page 24) for more information.

Historian Server Access Permissions and AD Each user's access permissions are determined by the PI identities with which that user is associated. AD groups are mapped to PI identities. Windows users that belong to that group get the access permissions for that PI identity.

Look at the access needs for all your Windows users. Which AD groups does the user belong to? Which PI identities do those groups map to? Users that belong to more than one AD group get the cumulative access permissions for all the associated PI identities. For example, in the following illustration, the Windows user, Bob, belongs to both AD groups. Bob therefore gets the permissions configured for PI Identity1 and the permissions for PI



Identity2.

Similarly, users get the cumulative access permissions for all parent AD groups (for nested AD groups). For example, in the following illustration, Windows user, Bob, belongs to ADGroup2. Since ADGroup2 is nested inside ADGroup1, the users in ADGroup2 get all the access permissions of ADGroup1, as well as those of ADGroup2.


20

Note: Though you can map individual AD users to PI identities, it is not a recommended practice. Mappings based on AD users will prevent you from managing your Historian Server security access by manipulating group memberships.

Map AD Groups to PI Identities Once you have the necessary PI identities and AD groups, you need to create a mapping between each AD group and a PI identity. The mapping associates the specified AD group with the specified PI identity. The Historian Server will automatically authenticate members of that AD group as the specified PI identity.

To map a PI identity to a Windows group:

1. Open SMT.

2. Under Collectives and Servers, select the server.


4. Select the PI Identities tab.

5. Select the identity that you want to map.

6. In the toolbar, click the Properties button . The Properties dialog box opens.

7. In the Properties dialog box, click the Mappings and Trusts tab. The top portion of the dialog box shows all existing mappings for this PI identity. The bottom portion shows all existing Trusts for this PI identity.

8. Click the Add button under the mappings portion of the dialog box. (There is also an Add button under the trusts portion, so be sure to click the right button.) The Add New Mapping dialog box opens.

Note: The Add button is disabled if the selected PI identity is flagged as disabled or not usable in a mapping.

9. Enter the Windows account. This can be an AD principal or a local Windows group or user. To select the account either:

ο Click the browse button to browse for the account. ο Type in the account name. If you choose to type in the account name, click the

resolve SID button to verify that this is a valid account. If the account is valid, an SID appears in the field. Otherwise, a dialog box with an error message opens.

See Specifying AD Users and Groups (page 20) for more information.

Specifying AD Users and Groups To explicitly specify an AD principal, you can use any of the following:

• Fully-qualified account name: domain_name\principal_name

• Fully-qualified DNS name: my_domain.com\principal_name



• User Principal Name (UPN): principal_name@my_domain.com

• SID: S-1-5-21-nnnnnnnnnn-…-nnnn

Note: For local Windows users or groups, you can use only the fully-qualified account name (computer_name\principal_name) or SID formats.

To find the security identifier (SID) or to check the validity of a domain principal, you can use the psgetsid utility. This utility is part of a set of command-line tools called PsTools, that are available on the Microsoft TechNet Web site. If you run the utility from the Historian Server, the SID that psgetsid returns is guaranteed to be valid for the mapping.

For example, after installing psgetsid, you could type the following from a command window on the Historian Server:

psgetsid.exe domain\somegroup

The psgetsid utility returns something like the following: PsGetSid v1.43 - Translates SIDs to names and vice versa Copyright (C) 1999-2006 Mark Russinovich Sysinternals - www.sysinternals.com SID for domain\somegroup: S-1-5-21-1234567890-1234567890-1234567890-4321

Configure Access Permissions

Once you define the mappings between AD groups and PI identities, configure access permissions so that each PI identity is authorized to perform the appropriate tasks on the Historian Server.

• About Access Permissions on the Historian Server (page 21)

• How to Configure Access Permissions (page 22)

About Access Permissions on the Historian Server The Historian Server has a variety of resources to which you can control access. These resources include points, modules, archive configuration, backups, batches, audit trails, and so on. We refer to those PI resources for which you can set access permissions as secure objects.

Each secure object can be configured to have access permissions for an unlimited number of PI identities, as the following illustration shows.


22

The Historian Server stores the settings for each object in an access control list (ACL). Each secure object on the Historian Server has an ACL that defines access permissions for that object. (Points have two ACLs: one for the point data and one for the point configuration.) The ACL contains an entry for each identity (or user or group) for which access permissions are set on that object. The ACL for the TEST_POINT data in the illustration above would look like this:

Identity1:A(r,w) | Identity2:A(r,w) | Identity3:A(r) | IdentityN:A(r,w)

Access permissions for each PI identity are separated by the pipe (|) symbol. Each entry is called an access control entry (ACE) and consists of the PI identity name, then a colon (:) followed by the access privileges, which are defined in the format: A(r,w). The A in this notation stands for Allow and "r,w" indicates the allowed access privileges – read and write, in this example.

The possible types of access privileges are read and write. The possible unique privilege combinations are "r" for read only, "w" for write only, "r,w" for read and write, and "" (empty) for none.

Note: Unlike Windows, the Historian Server does not allow you to explicitly deny access privileges.

Access Permissions: Out-of-the-Box Configuration The Historian Server has an identity, a user, and a group that come preconfigured with access permissions:

• The PIWorld identity has read-only access to most PI resources. If the PIWorld identity is not disabled, then all authenticated users get at least PIWorld access.

• For new installations, the piadmins group has read/write access to all Historian Server resources. On Historian Servers that are upgraded from an earlier version, the piadmins group has no preconfigured access permissions.

• The piadmin user is the super-user account. It has guaranteed read/write access to all Historian Server resources, regardless of security settings.

The Historian Server also includes the Historian Operators, Historian Engineers, and Historian Supervisors identities. These sample identities have no preconfigured access permissions, so they do not really do anything. However, you can use them as a starting point. These sample PI identities are completely configurable and can be deleted.

How to Configure Access Permissions The basic steps for setting access permissions on new Historian Server installations are as follows:

• Set default access permissions for new points and modules. After you do this, all new points and modules that you create will automatically have these default settings. See Set Default Access for New Points and Modules (page 23).



• Set top-level access permissions in the SMT Database Security tool. These include permissions to configure archives, view the audit trail, change tuning parameters, run backups, and so on. See Set Permissions in the Database Security Tool (page 23).

• Configure access permissions for individual points and modules by editing the objects themselves. The Historian Server installation includes tools for doing this. See Set Permissions on Specific Points and Modules (page 23).

Set Default Access for New Points and Modules You can set default access permissions for points and modules. When you create a new point or module without explicitly setting access permissions, the point or module gets the default access permissions.

• Default access permissions for all new points (both point data and point configuration) match the access permissions for the point database (PIPOINT). You can set permissions for PIPOINT in the Database Security tool.

• Similarly, default access permissions for root modules match the access permissions for the module database (PIModules). You can set permissions for PIModules in the Database Security tool. New modules below the root level inherit from their parent.

Set Permissions in the Database Security Tool The Database Security tool controls access to most Historian Server resources. The exception is that permissions for specific points and modules are configured on the objects themselves.

To set access permissions in the Database Security tool:

1. Open SMT.


3. Under System Management Tools, select Security > Database Security. The Database Security tool appears.

4. Double-click the table for which you want to set access (see below). The Properties dialog box opens.

5. Select the PI identity, PI user, or PI group for which you want to modify access permissions. If the PI identity, user, or group does not appear in the list, click the Add button to add it.

6. Check the appropriate boxes to assign read and/or write access to that PI identity.

For a complete list of Historian Server tasks and associated access permissions, see Task-Based Access Permissions Reference (page 67).

Set Permissions on Specific Points and Modules You configure access permissions for individual points and modules by editing the object itself. The Historian Server installation includes tools for editing these objects. You can access all of these tools from the System Management Tools (SMT). You can locate some under System Management Tools and you can locate the others from the Tools menu.


24

To Control Access on:

Use:

Point Point Builder (SMT tool), Tag Configurator (access from the SMT Tools menu)

Module Module Database tool (SMT tool) or Module Database Builder (access from the SMT Tools menu)

PIUnit Module Database tool (SMT tool) or Module Database Builder (access from the SMT Tools menu)

Administrative tasks

Database Security tool (SMT tool)

For information about what access privileges are necessary for specific tasks, see Task-Based Access Permissions Reference (page 67).

Permissions for Typical Administrative Tasks The following table lists some basic Historian Server administration tasks and tells you which tables in the Database Security tool control access to that task.

Administration Task Which Entries Control the Task

Managing archives

PIARCADMIN (basic archive administration tasks: archive creation, registration and shifts" ) and PIARCDATA (archive data that is not tag-specific, such as listing the archives; archive trouble-shooting tasks)

Managing backups PIBACKUP

Managing identities, users, and groups

PIUSER

Manage mappings PIMAPPING

Managing trusts PITRUST

Managing auditing PIAUDIT

Creating/deleting points PIPOINT

Creating/deleting modules PIModules

Editing the database security table

PIDBSEC

Managing firewall table, tuning parameters

PITUNING

Managing message logs PIMSGSS

Managing Historian Collectives

PIReplication, PIBACKUP

For a more complete list, see Task-Based Access Permissions Reference (page 67).

Other Security Configurations

If you do not have access to AD or if your access is limited in some way, then you have the following options for configuring authentication:



• Use Local Windows Security: You can use local Windows security for authentication, rather than AD. There are two disadvantages to this: ο Local Windows security uses NTLM for authentication, which is not as secure as

Kerberos (AD uses Kerberos). ο Extra configuration is required. The Windows user accounts on the Historian Server

must exactly match the accounts on each client workstation. If you have a lot of client workstations with a lot of users, then Windows authentication might not be a good choice for you.

However, authenticating through local Windows security is still far more secure than authenticating through Trusts or PI user accounts. See Use Local Windows Security (page 25).

• Use a Combination of Local Windows Security and AD: If you want to use AD for authentication but are not able to configure AD groups to meet your needs, then consider this workaround. You can use local Windows groups to organize AD users. Then map the local groups to your PI identities. See Use Local Windows Security with AD (page 28).

• Use Historian Password Authentication: If you cannot use local Windows security or AD for authentication, only two authentication methods are available: Historian Server user accounts/passwords and Trusts. Typically you configure user authentication through PI user accounts. Use PI groups to group the users so that you do not need to define access permissions for each individual user. See Use PI Users and Groups (page 28).

Use Local Windows Security

You can use local Windows security to grant access to the Historian Server and its resources if AD is not available. Using local Windows security requires significant maintenance. The account names and passwords must be identical on the Historian Server and all client machines. When a password changes or a user is added or deleted, you must make that change on the Historian Server and all participating client machines (this is actually a Windows requirement).

Note: If the Historian Server is part of a Historian Collective, please refer to Security for Historian Collectives (page 47) before using local Windows groups.

To configure security with local Windows authentication:

1. Identify user access categories. Identify the users who need access to the Historian Server. Understand their roles, and the types of access they need. For example: who needs permission to create points? Who should be allowed to edit modules? Who will perform Historian Server Backups? See Identify User Access Categories (page 15).

2. Create PI identities. On the Historian Server, create PI identities for people with similar access needs. See Create PI Identities (page 17).

3. Configure local Windows groups. In Windows, identify the Windows groups that represent your Historian Server roles. See Configure Windows Groups (page 26).

4. Map Windows groups to identities. See Create Mappings (page 27).


26

5. Grant Historian access permissions. Give your PI identities access to the necessary Historian Server resources. The access permissions specify what tasks each PI identity is allowed to do on the Historian Server. See Configure Access Permissions (page 21).

6. Configure access for client applications. Client applications typically connect to the Historian Server using PI SDK. You need SDK 1.3.6 or later to use Windows authentication. Certain Historian client applications require a connection to a separate application server in addition to a Historian Server (for example, Historian DLES and Historian WebParts). These types of applications require additional configuration steps. See How Will FactoryTalk Historian 3.0 Affect My Clients and Interfaces? (page 61) for more information.

7. Configure access for interfaces. You need to set up trusts for the interfaces that will connect to the Historian Server. Each trust is based on a PI identity. See Configure Historian Interface Connections (page 30).

There are a number of things you can do to provide extra security for your Historian Server. See Tightening Security (page 53) for suggestions and instructions.

Configure Windows Groups To use Windows groups for Historian Server authentication:

1. Configure user accounts on client and server workstations. In order to use Windows users and groups, the Windows user accounts on the Historian Server must exactly match the accounts on each client workstation. The account names and passwords must be identical.

2. Configure Windows groups and PI identities so that you have a 1:1 relationship between them. Follow these guidelines:

ο Map each Windows group to a PI identity. ο Establish a naming convention for PI identities and/or Windows groups so that it is

clear which group is mapped to which identity. ο Manage group membership using Windows. Note that you cannot nest local

Windows groups, as you can AD groups.

3. Review your Windows groups to ensure that all Windows users can get the appropriate Historian Server permissions (Managing User Access Permissions with Windows Groups (page 26)).

Managing User Access Permissions with Windows Groups The access permissions for each Windows user are determined by the PI identities that user is associated with. Each Windows group is mapped to a PI identity. Windows users that belong to that Windows group get the access permissions for that PI identity.



Windows users that belong to more than one Windows group get the cumulative access permissions for all the associated PI identities. For example, in the following illustration, the Windows user, Bob, belongs to both Windows groups. Bob, therefore, gets the permissions configured for PI Identity1 and PI Identity2.

Look at the access needs for all your Windows users. Which Windows groups do the users belong to? Which PI identities do those Windows groups map to? Make sure that each Windows user belongs to the appropriate Windows groups.

Create Mappings Once you have the necessary PI identities and Windows groups, you need to map each Windows group to a PI identity. The mapping associates the specified PI identity with the specified Windows group. Members of that Windows group will be authenticated automatically on the Historian Server as the specified PI identity.

To map a Windows group to a PI identity:

1. Open SMT.



4. Select the PI Identities tab. (If you do not see the PI Identities tab, verify that you are connected to a FactoryTalk Historian 3.0 or later. This tab does not appear in SMT with earlier versions of the Historian Server.)

5. Double-click the identity to open the Properties dialog box.

6. Click the Mappings and Trusts tab. The top portion of the dialog box shows all existing mappings for this PI identity. The bottom portion shows all existing Trusts for this PI identity.


28

7. Click the Add button under the mappings portion of the dialog box to open the Add New Mapping dialog box. (There is also an Add button under the trusts portion, so be sure to click the right button.)

Note: The Add button is disabled if the selected PI identity is flagged as disabled or not usable in a mapping.

8. In Windows Account, enter the Windows group. To select the account either:



9. Enter a description of the mapping (optional). There are no restrictions on the contents of this field.

10. Click OK. The new mapping appears under Mappings.

Use Local Windows Security with AD

If you want to use AD authentication but you are not able to configure AD groups, then you can use local Windows groups to organize AD groups and users. You are essentially using local Windows groups on the Historian Server computer as a configuration tool to organize existing AD principals. Create local Windows groups on your Historian Server and map them to the appropriate PI identities (Create Mappings (page 27)). Then place existing AD groups and users within the local Windows groups. In this configuration, AD still handles user authentication.

Use PI Users and Groups

If Windows authentication is not a viable option for you, you can use Historian password authentication (explicit logins) to authenticate your users. With this method of authentication, you create user accounts on the Historian Server and assign each user a PI user name and password to log on. You can create PI groups to group users into meaningful access categories. Using Historian password authentication is not as secure as using Windows authentication or Trusts.

To configure Historian password authentication on Historian Server:

1. Identify user access categories. Identify the users who need access to the Historian Server. Understand the types of access they need. For example: who needs permission to create points? Who should be allowed to edit modules? Who will perform Historian Server Backups? See Identify User Access Categories (page 15).

2. Create PI groups: On the Historian Server, create a PI group for each user category. See Create a PI Group (page 29).



3. Grant Historian access permissions. Give each PI groups access to the necessary Historian Server resources. The access permissions specify what tasks each PI group can do on the Historian Server. See Configure Access Permissions (page 21).

4. Create Historian Server user accounts. Each user who needs access to the Historian Server should have an associated account. See Create a New PI User (page 29). If you allow multiple users to share a single Historian Server account, then you will not have any way to know who made what changes on the Historian Server.

5. Configure group memberships. Add each PI user to the appropriate PI group or groups.

6. Configure access for interfaces. Set up trusts for the interfaces that will connect to the Historian Server. Each trust is based on a PI user, a PI group, or a PI identity. See Configure Historian Interface Connections (page 30).

7. Upgrade administrative client applications. If you have existing client computers that will connect to this Historian Server, upgrade any applications that configure access permissions (Administrative Client Applications (page 62)).

Create a New PI User To create a new PI user:



3. Select the PI Users tab.

4. Click the New button to open the New User dialog box.

5. In Username, type the a name of the new PI user. This field is required. Note the following restrictions:

ο Names must be unique. They cannot match an existing PI user, PI group, or PI identity.

ο Names cannot include the vertical pipe (|) character or the colon (:) character. ο Names cannot be a positive integer, although they can contain numbers. For example,

the name 329 is not valid, but the name Admins329 is valid. ο Names are not case sensitive.

Note that you can change a PI user name any time after creation.

6. Select the appropriate server from the drop-down Server list. This list shows the servers selected under Collectives and Servers.

7. Optionally, enter a brief description in Description. There are no restrictions on the contents of this field.

8. In Password, enter a password for the PI user.

Click Create. The new PI user now appears in the PI Users tab.

Create a PI Group To create a new PI group:


30



3. Select the PI Groups tab.

4. Click the New button to open the New Group dialog box.

5. In Group, type the name for the new PI group. This field is required. Note the following restrictions on group names:

ο Names must be unique. They cannot match the name of an existing PI user, PI group, or PI identity.

ο Names cannot include the vertical pipe (|) character or the colon (:) character. ο Names cannot be a positive integer, although they can contain numbers. For example,

the name 329 is not valid, but the name Admins329 is valid. ο Names are not case sensitive.

Note that you can change a PI group name any time after creation.

6. In Server, select the appropriate server. This list shows the servers selected under Collectives and Servers.

7. In Description, enter a brief description, if desired. There are no restrictions on the contents of this field.

8. Click Create to create the new PI group.

Configure Historian Interface Connections

To configure your Historian Server to provide access for Historian Interfaces:

1. Identify all the Historian Interfaces that need access to the Historian Server.

2. Consult the documentation for each interface and gather the information you need to configure the Trust. You need to know the connection type (Connection Types (page 32)). The type of connection determines what information you can use to define the trust. You will also need to specify at least one of the following:

ο The correct application name to use when defining the trust (The Application Name (page 32))

ο IP information for the connecting computer (IP Information (page 33)) ο For SDK connections only, you have the option to specify Windows account

information, but this is not recommended (Windows Account Information (page 33))

3. Decide how many Trusts you will create. You can create explicit individual trusts for each Historian interface or you can group them according to subnet, host machine, or username. A group of Historian Interfaces can share the same privileges.

4. For each Trust, create a PI identity. See How to Create a PI Identity (page 17).

5. Give that PI identity all the access permissions required by the Trust. See Product Access Permissions Reference and Configuration Issues (page 71) as well as the documentation for the interface.



6. Create a trust based on that PI identity. See How to Create a Trust (page 31).

About Trusts

Trusts allow applications to access the Historian Server without explicitly logging onto Windows (or onto the Historian Server). Typically, you use trusts for Historian Interfaces, which run unattended.

Each Trust is defined against a PI identity, a PI group, or a PI user. The trust gives the interface the same access permissions as the associated identity, group, or user. Trust authentication works by comparing the connection credentials of the connecting application to the trust records in the trust database. Human intervention is not required at the time of connection.

How to Create a Trust

To create a new Trust in SMT:


2. Under System Management Tools, select Security > Mappings & Trusts. The Mappings & Trusts tool appears.

3. Select the Trusts tab.

4. Click the New button to open the Add Trust Wizard.

5. Select the Historian Server name and type in a name for the trust (and, optionally, a description). Click Next.

6. Select the type of trust to add:

ο Historian-API application (this is the right choice for most Historian Interfaces) ο Historian-SDK application on a Windows NT based OS

7. Click Next. The next screens allow you to define optional information for the Trust. If you leave a field blank, then that information is not checked for the trust authentication. When you fill in fields, then only applications with matching information can authenticate against this Trust.

ο Application Name: This is slightly different for API and SDK connections. − API: Connecting PI API applications send an identifier called an application

process name, or procname. This is a four-character string with an E appended (for example, the procname for the Perfmon interface is: PIPeE).

− SDK: This is the full name of the connecting application, including the extension, but not the path (for example: PI-ICU.exe).

ο Network Path: Fully-qualified domain name of the interface node (for example my_laptop.my_company.com).

ο IP Address: The IP address of the interface node. ο Net Mask: The net mask for the interface node (for example, 255.255.255.255). ο For SDK connections only, you also have the following optional fields:


32

− Windows Domain: the Windows domain of the user who runs the application (for example: osi).

− Windows Account: the Windows user name of the user who runs the application (for example: my_account).

8. Select the PI identity that you want to use for this trust. Applications authenticated through this trust will have all the access permissions granted to this PI identity. Alternatively, you can select a PI group or a PI user for this step.

Connection Types When you configure a Trust, you need to know the type of connection the trust will be used for. There are two different Historian Server connection types. Each Historian interface and client application is configured to use one or the other. (There are also a few interfaces that use both.) The two mechanisms are:

• PI API Connection: Most Historian Interfaces use the PI API to connect to the Historian Server. PI API does not support Windows authentication. Trusts are the standard way to authenticate PI API connections.

• PI SDK Connection: Most client applications use the PI SDK to connect to the Historian Server. PI SDK versions 1.3.6 and later support Windows authentication, so use Windows authentication for these connections if possible. Windows authentication is the most secure authentication method available for the Historian Server.

Note: In previous releases of the Historian Server, PI API connections that failed would typically still get world access to Historian Server resources. In FactoryTalk Historian 3.0 and later, this loophole is closed. See Check for Unauthenticated API Connections (page 62) for more information.

The Application Name A Trust can require a specific application name. When you specify an application name in a trust, you have to use the appropriate format for the connection type (page 32):

• Applications that connect through the API send an identifier called an application process name, or procname. This is a four-character string with an E appended. For example, the procname for the Perfmon interface is: PIPeE

Note: PI API versions before 1.6.0 always send a five-character string: 4 characters plus a capital E. For PI API versions 1.6.0 and later, up to 8 characters may be specified as the procname, if configured to do so (in this case, there is no longer an E appended to the procname).

• For applications that connect through the SDK, use the full name of the connecting application, including the extension, but not the path. For example, the application name for ICU is: PI-ICU.exe



If you are running the same Historian interface on another Historian Server, then you can use SMT to determine the correct application name. Select Operation > Network Manager Statistics. Find the interface in the list. The application name is listed under Name.

IP Information A Trust can specify IP information about the computer running the Historian interface or client application for which you are defining the trust. To collect this information, you can run pidiag -host on the computer where the interface or client application runs. This returns the connection credentials as retrieved from the local operating system.

Note: Using pidiag -host is helpful, but it is not a guarantee of getting the right information, depending on many factors, including the type of interface, the version of the SDK (if SDK-based), and whether there are firewalls / NAT devices in between the interface computer and the Historian Server computer. If you have difficulty configuring the trust, contact Rockwell Automation Technical Support.

• Network Path. The fully-qualified domain name. For PI API, this should match what the Historian Server thinks based on a reverse-name lookup using the interface's IP address. For PI SDK (1.3.6.x and later), this should match what the client thinks, based on the Windows configuration (you can use pidiag –host on the client to see this information). For example, my_laptop.my_company.com

• IP Address.

• Netmask. If you specify an IP address, you must also explicitly provide a netmask value. Failure to do so will generate an error. If you require an exact match on an IP address, specify the netmask as 255.255.255.255. If you specify a class C subnet, specify the netmask as 255.255.255.0 and the fourth field of the IP address as 0.

Note: When applications run on machines with multiple network cards, you cannot predict which credentials the application will send to the Historian Server for the trust authorization. Rockwell Automation thus recommends that you either avoid such configurations, or create a Trust for every IP address on the machine where the application runs.

Windows Account Information For SDK connections only, you can specify Windows account information as part of the Trust. This type of trust is not needed in the new security model because a PI mapping serves the same purpose as a trust based on OS user name and Windows domain membership.

• Windows Domain: the Windows domain of the user who runs the application.

• Windows Account: the Windows user name of the user who runs the application.


When you upgrade from a pre-3 version of the Historian Server to FactoryTalk Historian 3.0 or later, you get access to a variety of new features and components. If you are upgrading from an older version of the Historian Server, this section discusses what you need to know:

• What is in the New Security Model? (page 35)

• Why a New Security Model? (page 36)

• Your Upgrade Options (page 36)

What is in the New Security Model?

The new security model introduces a number of changes to the Historian Server:

• Windows Authentication. Previous versions of the Historian Server had two methods of authentication: Trusts and Historian password authentication (typing in PI user name and password). FactoryTalk Historian 3.0 adds a third method: Windows authentication. This method is more secure than the other two and is now the recommended method for authenticating users.

• New Access Permissions Model. The owner/group/world model of access permissions has been replaced with access control lists that allow you to define permissions for as many different purposes as you need. You are no longer restricted to one owner, one group, and everyone else.

• PI Identities. The old model had only PI users and PI groups. This model was based on the necessity for managing user accounts on the Historian Server. The new model provides PI identities. The PI identity is essentially an abstraction layer. It allows you to map Windows groups or users to categories of access on the Historian Server.

• Mappings. Mappings are the mechanism for associating Windows users or groups with PI identities. You can also create mappings to existing PI users and PI groups.

• New Version of SMT. SMT has changed to support the new security model. A new Backup tool is included, as well as a Security Settings tool and a Firewall tool. See New in SMT (page 99) for more.

Note: Previous versions of the Historian Server had a built-in PI user and a built-in PI group that were both named piadmin. The name of the PI group called piadmin has been changed to piadmins (plural) for consistency. Similarly, previous versions of the Historian Server had a built-in PI user and a built-in PI group that were both named piuser.

Chapter 3

Configuring Security for Historian Server Upgrades


36

Why a New Security Model?

The new Historian Server security model has the following major benefits:

• Improves Security. You can now use Windows authentication to control user access to the Historian Server. Historian password authentication (typing in a PI user name and password) are nowhere near as secure as Windows authentication. If you configure your Historian Server for Windows authentication, you will greatly improve security. Windows AD is preferable because it uses the more secure Kerberos protocol. However, you can use local Windows authentication if necessary.

• Simplifies Server Administration. If you use Windows for authentication, then you do not need to manage individual PI users or PI groups. You can simplify your Historian Server configuration by maintaining a much smaller set of PI identities. Each PI identity should define a unique set of access permissions on the Historian Server. Both the audit trail and last change information preserve the Windows user ID, so you can keep a record of who is doing what on the Historian Server.

• Provides Single Sign-on. If you use Windows for authentication, your users no longer need to separately log onto the Historian Server.

Your Upgrade Options

You can choose how soon and to what extent you want to take advantage of these new security features. Eventually, your goal should be to move the Historian Server to the new model, but you are not required to do that. Here are your options:

• Option 1: Migrate over time. If you choose this option, you immediately switch to Windows authentication, but you continue to use some components of your existing configuration. You can replace these components over time. See Migrate Over Time (page 38) for instructions. This is the recommended path for most Historian Server installations.

• Option 2: Quick-start migration. If your existing configuration is very simple (you use only a handful of PI users and PI groups) then you can start with a quick upgrade configuration. You can keep this configuration indefinitely, or you can use it as a starting point for a slow migration to the new model. See Quick-Start Security Migration (page 37) for instructions.

• Option 3: Implement from scratch. You can implement an entirely new security configuration to take advantage of the new security model. The disadvantage is that this could be disruptive to existing users. See Implement a New Configuration (page 46) for instructions.

• Option 4: Keep existing configuration. You have the option to continue to use your existing security configuration for as long as you choose. See Keep Existing Configuration (page 46) for tips and concerns.



Quick-Start Security Migration

Many Historian Servers use only the piadmin account and the pidemo account for authentication. In a few simple steps, you can convert this piadmin/pidemo configuration to use Windows authentication. This greatly improves your Historian Server security.

Although these instructions assume you are using the piadmin and pidemo accounts, note that you can apply the same method to any Historian Server that relies on a very small number of PI users or PI groups for security.

Note: These instructions assume you are using Windows Active Directory (AD) because AD provides the most secure authentication. If you use local Windows groups instead of AD groups, then you need to do some additional configuration on client computers. See Use Local Windows Security (page 25) for more information.

To set up this security configuration:

1. Configure authentication for piadmin. Map a Windows group to the piadmin account. All the Windows users that are a member of this Windows group will then get piadmin access permissions simply by logging on to Windows.

a. In Windows AD, identify the Windows group that will get administrative privileges on the Historian Server. If the appropriate group does not exist, ask your domain administrator to set one up for you. If your domain administrator will not help, try the workaround described in Use Local Windows Security with AD (page 28).

b. Create a mapping between that AD group and the piadmin account. Now all users in that AD group have the same privileges as piadmin.

2. Configure authentication for pidemo.

a. In Windows AD, identify the Windows group that will get the pidemo access permissions on the Historian Server.

b. Create a mapping between that AD group and the pidemo account. Now all users in that AD group have the same privileges as pidemo.

This completes the basic configuration on the Historian Server. As soon as possible, consider these additional steps for further securing your Historian Server:

• The biggest security hole in this quick-start plan is that pidemo and piadmin are still accessible through PI user passwords. PI user passwords are not especially secure. To fix, disable explicit logins (typing in a PI user name and password) for the pidemo and piadmin accounts. Then the Historian Server disallows user-name and password access for those accounts and only provides access through the mappings you created or through Trusts. See Disable Explicit Logins for Individual User Accounts (page 56) for instructions.

• Review the follow-up steps, which include upgrading the SDK on client workstations, upgrading administrative applications, and so on. You can choose if and when to complete each step. See Follow-up Steps (page 45).


38

Migrate over Time

You can migrate to the new security model over time. Exactly how and when you do this is up to you. These instructions are divided into two categories:

• Initial Configuration Steps: Perform these basic steps to set up a Historian Server security configuration that uses Windows authentication. See Initial Configuration Steps (page 38).

• Follow-up Steps: Perform these follow-up steps over time. See Follow-up Steps (page 45).

If your existing configuration relies on very few PI users or PI groups, the Quick-Start Security Migration (page 37) might work better for you.

Initial Configuration Steps When you migrate your Historian Server to the new security model, you need to create an initial configuration that authenticates Windows users and grants them the appropriate access permissions on the Historian Server. You can use components of your existing configuration, which you can replace over time.

To create an initial configuration:

1. Review Existing Access Permissions. Export the access permissions for all existing points and modules and for all the entries in the SMT Database Security tool. See Review Access Permissions (page 38).

2. Create a List of Unique Access Strings. You will use this list to determine the needed sets of access permissions. See Create List of Access Strings (page 39).

3. Create a Configuration Plan. Identify which PI groups you will keep and which are redundant. If you have any sets of access permissions that are not covered by existing PI groups, determine how you will fill those gaps. See Create a Configuration Plan (page 41).

4. Create New Identities to Fill Gaps. If you decided to create new PI identities to fill configuration gaps, create them now. See Create PI Identities to Fill Gaps (page 43).

5. Review AD Groups. Determine how your AD groups correspond with your configuration plan. You might need to create new AD groups or adjust group membership. See Review AD Groups (page 43).

6. Create the Mappings. Set up mappings between AD groups and PI groups and identities. See Create Mappings (page 44).

7. Verify Initial Configuration. Check your new security configuration to make sure that everyone is getting the correct level of access. See Verify Initial Configuration (page 44).

Step 1. Review Access Permissions When you move to the new security model, typically the goal is to preserve the access permissions for your existing users. To do that, you first need to identify the existing access permissions. You need to look at the permissions for all the modules and points (data and configuration access), as well as for all items listed in the Database Security tool in SMT.



Note: If you do not need to preserve existing access permissions, then you can implement a new security configuration instead (Configuring Security on a New Historian Server Installation (page 11)).

When you export the existing data access permissions, each object will have an associated access control list (ACL). This is different from the old owner/group model. For example, in earlier versions of the Historian Server, the access permissions for the sinusoid point might look like this:

Tag dataaccess datagroup dataowner

sinusoid o:rw g:rw w:r pi_users bob

When you upgrade the Historian Server, those access permissions are converted to the new model and would look like this:

Tag datasecurity

sinusoid pi_users:A(r,w) | bob:A(r,w) | PIWorld:A(r)

See About Access Permissions on the Historian Server (page 21) for more information on the ACL.

CREATE AN ACCESS PERMISSIONS SPREADSHEET

To create a spreadsheet that contains all the existing access permissions on your Historian Server, create the following three separate spreadsheets and merge them together:

• Point Data and Point Configuration: Use Tag Configurator to import all your point security information into an Excel spreadsheet. Do this for all point classes. Which attributes you need to import depends on which version of the Historian Server you are using. ο For FactoryTalk Historian 3.0 and later, import the ptsecurity and datasecurity

attributes (these attributes are new in FactoryTalk Historian 3.0). ο On earlier versions of the Historian Server import the dataowner, datagroup,

ptowner, ptgroup, dataaccess, and ptaccess attributes.

• Modules: Use Module Database Builder to export all module security information into a spreadsheet.

• Database Security: Open the Database Security tool in SMT. Click the Export To File button to export the list into a .csv file. Open that file in Excel.

Step 2. Create List of Unique Access Strings Examine the spreadsheet containing the access permissions for the Historian Server. Collapse all the items that have the same access. This should give you a list of unique access strings. If you are compiling this list before upgrading to 3, then the access strings will be in the owner/group/world format. If you compile the list after upgrading, it will be in the new format.

For example, the following table contains the data security for a set of points on a Historian Server that uses the old security model. Notice that the access permissions are exactly the same for most of the tags.


40

point dataaccess datagroup dataowner

tag1 o:rw g:r w:r pi_ops bob



tag4 o:rw g:rw w:r pi_eng nancy


The following table shows what the same access permissions look like after upgrading to Historian Server version 3.0.

point datasecurity

tag1 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)



tag4 nancy: A(r,w) | pi_eng: A(r,w) | PIWorld: A(r)




What we want to do is collapse these access permissions into a set of unique access strings. It does not matter whether we use the owner/group/word notation or the ACL strings. We will use ACLs for the rest of this example.

We would then have the following:

point datasecurity

datasecurity for tag4 nancy: A(r,w) | pi_eng: A(r,w) | PIWorld: A(r)

datasecurity for: tag1, tag2, tag3, tag5

bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)

In this manner, reduce all your access permissions to a set of unique access strings. The next step is to determine what PI groups you need, based on this list.

Step 3. Create a Configuration Plan We want to identify the smallest set of existing PI groups that can define our existing access permissions. Ideally we want to retire all PI user accounts. To see how this works, look at the list of unique access strings we identified in the previous example:


42

Points datasecurity

tag4 nancy: A(r,w) | pi_eng: A(r,w) | PIWorld: A(r)

tag1, tag2, tag3, tag5 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)

We need to distill our list down into the smallest number of access permission sets and we need to keep track of who currently has that level of access. Another way to look at our current access permissions is as follows:

Who? What Access?

bob read/write access to tag1, tag2, tag3, tag5

pi_eng read/write access to tag 4

nancy read/write access to tag 4

pi_ops read only access to tag1, tag2, tag3, tag5

PIWorld read only access to all tags

Looking at the above table, notice the following:

• If we are not going to disable PIWorld, then the pi_ops access permissions are not needed. For the purposes of this example, assume we will continue to rely on PIWorld.

• The PI user nancy and the PI group pi_eng have identical access permissions. Since these access permissions are already defined for pi_eng, we will leave this PI group in place. We need to create a mapping between pi_eng and a Windows group that contains the following users: ο Windows users represented by the PI user members of pi_eng ο Windows user represented by the PI user nancy

We can retire the PI user called nancy.

• The PI user bob has unique access permissions. We have two choices: ο We can keep the PI user bob and create a mapping between the corresponding

Windows user and PI user bob. This gives us Windows authentication, which is much more secure than PI user accounts. We can continue to use the access permissions defined for bob.

ο Another solution would be to create a new PI identity, grant it the same access permissions as bob then map a Windows group containing the corresponding Windows user to this new PI identity.



We choose to continue using bob for now, but we plan to create a new PI identity and retire the PI user bob in the future.

The following table summarizes our new security configuration:

Keep: Type: Mapping:

pi_eng PI group Windows group containing the users represented by the PI user pi_eng; Windows user represented by the PI User nancy.

bob PI user Windows user represented by the PI User bob.

PIWorld PI identity All authenticated users automatically get PIWorld access.

The next step is to create the required mappings and then disable the PI group pi_ops and the PI user nancy.

Step 4. Create PI Identities to Fill Gaps Some of your old PI users might have access permissions that do not match the access permissions of any of your PI groups. Ideally you should create a PI identity for each set of access permissions that you need. You then need to set the access permissions for each new PI identity. See Create PI Identities (page 16).

If you decide to keep PI user and PI groups for some period of time, you should at least create mappings for them. Windows authentication is much more secure than Historian password authentication.

Step 5. Review AD Groups Ideally, you want one AD group for each PI group and PI identity on your Historian Server. When you determined the needed sets of access permissions, you also compiled a list of PI users and PI groups that required those access permissions.

Hopefully, your AD configuration includes groups that somewhat match these required sets of access permissions. If not, work with your domain administrator to create or reconfigure AD groups for the Historian Server. You need an AD group for each set of access permissions.


44

Each set of access permissions are associated with a PI identity, PI group, or PI user on the server. The ideal configuration is a one-to-one mapping between an AD group and a PI identity or a PI group.

The goal is for all of your users to get the same access permissions that they had before the upgrade. In most cases this should not be difficult. However, if you have a large number of users with different access permissions, then you are probably going to have some gaps on your first pass.

During this configuration period, you can rely on the access permissions for piadmin and the built-in PIWorld identity. You can create a mapping between an AD group representing your administrators and the PI user piadmin. All authenticated users get the access permissions defined for PIWorld. By default, PIWorld has read-only access to most Historian Server resources.

Note: If your domain administrator is unwilling to reconfigure AD, you can nest existing AD groups inside local Windows groups. See Use Local Windows Security with AD (page 28).

Step 6. Create Mappings To create a mapping in SMT:


2. Under System Management Tools, select Security > Mappings and Trusts.

3. Select the Mappings tab.

4. In the toolbar, click the New button .

The Add New Mapping dialog box opens.

5. In Windows Account, enter an AD principal or a local Windows group or user. To select the account either:



See Specifying AD Users and Groups (page 20) for more information.

Step 7. Verify Initial Configuration After you complete your initial Historian Server security configuration, deploy to a small number of test clients. Verify that the connections are working. Exercise all the mappings from this small set of clients and verify with test applications that you get proper authentication and proper access permissions through your mappings.



Follow-up Steps After you have an initial Historian Server configuration, you can continue to transition to the new model over time. This section discusses some measures that you should take.

• Check Custom API Applications. A security loophole in earlier versions of the Historian Server allowed world access to API connections, even if the authentication failed. You could disable that access explicitly but if you did not disable it, then you might currently have API applications that rely on this loophole. Current versions of the Historian Server permanently disable that access and any applications that rely on that access will no longer have access to the Historian Server. You will need to configure authentication for these applications. (This is typically only a problem for custom API applications.) See Check for Unauthenticated API Connections (page 62).

• Limit Use of piadmin. Explicitly configure administrative permissions for a different PI identity; map the appropriate Windows group to that PI identity. Do not use the piadmin account for routine administrative tasks (see Protect piadmin (page 53)).

• Upgrade the SDK on Client Computers. On computers running client applications, upgrade PI SDK to version 1.3.6 or later. Earlier versions of the SDK do not support Windows authentication.

• Configure Application Server Clients. If you are using applications where the client is accessing the Historian Server through an application server, then you might need to take additional steps to complete your security configuration. See Products that Connect to an Application Server (page 62) for more information.

• Upgrade Administrative Applications. If you are using older versions of administrative applications, they might not handle new access permissions properly. See Administrative Client Applications (page 62) for more information.

• Disable Explicit Logins. Explicit logins are logins in which the user actually types in a PI user name and passwords (also called Historian password authentication). This is the least secure Historian Server authentication method and it is best to disable it entirely or at least partially. See Disable Historian Password Authentication (Explicit Logins) (page 54) for more information.

Note: Remember that Windows authentication requires SDK 1.3.6 or later. If you are replacing explicit logins with Windows authentication, then be sure to upgrade the SDK on all client workstations before you disable explicit logins.

• Replace SDK Trusts. After you upgrade SDK on your client workstations, replace PI SDK trusts with PI mappings. Windows authentication is more secure than authentication through Trusts. In most cases, the Historian Server will no longer use existing trusts anyway (see Retire SDK Trusts (page 56)).

• Retire PI Users and PI Groups. This is a cleanup step. PI users and PI groups still work. However, they imply management of users and groups on the Historian Server itself. This could cause confusion over time. (A handful of built-in PI users and PI groups will remain (piadmin and piadmins for example) but these have well-defined roles on the Historian Server). Additionally, PI users have associated passwords that are not secure. Ideally, you should plan to replace your PI users and PI groups with descriptively-named PI identities.


46

To further improve security, see Tightening Security (page 53).

Implement a New Configuration

To set up a new security configuration using Windows for authentication, configure security as you would for a new Historian Server installation. See Configuring Security on a New Historian Server Installation (page 11). As soon as possible, review the follow-up steps, which include upgrading the SDK on client workstations, upgrading administrative applications, and so on. See Follow-up Steps (page 45). You can choose if and when to complete each step.

Keep Existing Configuration

You can continue to use your existing Historian Server security configuration for as long as you choose. There are a couple of things you should do immediately:

• Check Custom API Applications. A security loophole in earlier versions of the Historian Server allowed world access to API connections, even if the authentication failed. That loophole is now closed. If you have API applications that rely on this loophole, they will no longer get access. This is typically only a problem for custom API applications. See Check for Unauthenticated API Connections (page 62).

• Protect the piadmin account with a password. The piadmin PI user is the Historian Server super-user account. This powerful account should be protected and should not be used regularly. If you have not already done this, be sure to at least protect piadmin with a password. See Protect piadmin (page 53) for more information on protecting piadmin.

• Require passwords for all PI Users. Do not allow blank passwords. Disable logins for accounts with blank passwords. See Disable Explicit Logins with Blank Passwords (page 55).

Plan to migrate to the new security model. You can do this gradually over time. See Migrate Over Time (page 38). Even before you begin configuration on the Historian Server, you can gradually perform many of the steps listed in Follow-up Steps (page 45).


This section discusses security configuration when you enable Historian Server high availability (HA) features by configuring a Historian Collective. Topics include:

• Overview of Security in Historian Collectives (page 47)

• Custom Security Configurations (page 48)

• How to Enable the Lookup-Failure Tuning Parameter (page 48)

Creation of Mappings with a SID (page 49)

Overview of Security in Historian Collectives

Rockwell Automation designed Historian Collectives to fully support Windows authentication. In a standard configuration, a collective replicates the Historian security mappings defined on the primary server across all collective members. In non-homogeneous security environments or environments without Microsoft Active Directory (AD), PI mappings on a specific collective member will reference Windows users or groups that are not valid on other collective members. In this case, the replication process will fail. Therefore, you cannot simply replicate mappings: you must use a custom configuration.

In a standard configuration—one where all collective members are in the same security environment and you are using AD—you configure security on the collective’s primary server just as you would configure a single Historian Server. The collective’s Historian Server Replication service copies the configuration to all secondary servers in the collective. This replication process requires that all collective members be on a single domain or part of fully-trusted domains.

You must use a custom security configuration if:

• Collective members are not contained in a homogeneous security environment, such as when members are on different non-trusted domains, or when one or more members are on no domain.

• You do not have access to AD and must configure authentication through local Windows security on the primary and secondary servers.

Custom configuration in collective servers can affect FactoryTalk Historian applications and users when accessing Historian Server information. If the same mappings are not available on all collective members, applications might fail to connect or might receive different permissions on failovers. Rockwell Automation recommends avoiding custom configurations whenever possible. Custom configurations are more complex. To set up and maintain a custom configuration, you must consider who needs access to each collective member, and who will need to fail over. Consult Rockwell Automation Technical Support if you need help.

Chapter 4

Security for Historian Collectives


48

Custom Security Configurations

To use a custom security configuration in a Historian Collective, you must configure the Historian Server to accept unresolvable security mappings during replication. The Historian Server includes a lookup-failure tuning parameter that tells it to ignore unresolvable mappings during replication. (Collectives do not replicate tuning parameters.) With this tuning parameter enabled, you can create mappings on one collective member that other collective members cannot resolve, but replication between collective members will succeed. For information on enabling the tuning parameter, see How to Enable the Lookup-Failure Tuning Parameter (page 48).

For example, suppose the primary server is in the domain where you want to create mappings and you have a secondary server that is not part of that domain. If you create mappings on the primary server with domain accounts, the replication of these mappings will fail on the secondary server (because that domain does not exist for the secondary server). Replication will stop and the secondary server will fall out of synchronization. If you enable the tuning parameter on the secondary server, the server will accept the mappings and replication will succeed.

Similarly, suppose the primary server defines a mapping against a local Windows group. Because secondary servers do not know about that local group, the mappings will cause replication to fail. If you enable the tuning parameter on the secondary servers, they will accept the mappings and replication will succeed. In this case, you might also need to define mappings against local Windows groups on the secondary servers. Therefore, you must also enable the tuning parameter on the primary server.

After you enable the lookup-failure tuning parameter, you must use a group’s Windows Security ID (SID) instead of its name when configuring a mapping for a local Windows group. Because you cannot use SMT to create mappings based on SIDs, you must use piconfig. See Creation of Mappings with a SID (page 49).

How to Enable the Lookup-Failure Tuning Parameter

You must enable the lookup-failure tuning parameter on any secondary Historian Server in a Historian Collective that cannot resolve security mappings from the primary server. You must also enable the lookup-failure tuning parameter on the primary server in the Historian Collective if you define mappings valid only on secondary servers.

To enable the lookup-failure tuning parameter on a Historian Server: 1. Open SMT.

Click Start > All Programs > Rockwell Software > FactoryTalk Historian SE > System Management Tools.

2. Under Collectives and Servers, select the Historian Server where you want to enable the tuning parameter.

3. Under System Management Tools, select Operation > Tuning Parameters.

Creation of Mappings with a Windows Security ID (SID)


4. Click the New Parameter button.

5. In Parameter name, type: Base_AllowSIDLookupFailureForMapping

6. In Value, type: 1

7. Click OK.

8. Restart the server’s Historian Base Subsystem.

Note: Collectives do no replicate this setting (like any tuning parameter).


After you enable the lookup-failure tuning parameter, you must use a group’s SID instead of its name when you configure a mapping for a local Windows group. Use SMT to determine the SID, and use piconfig to create the mapping based on that SID.

Rockwell Automation recommends enabling the lookup-failure tuning parameter only when creating mappings. After you create mappings and the primary server replicates the mappings to the Historian Collective, you can disable the parameter to protect against the accidental creation of invalid mappings.

To determine a SID: 1. Open SMT.

Click Start > All Programs > Rockwell Software > FactoryTalk Historian SE > System Management Tools.

2. Under Collectives and Servers, select the secondary server that needs the security mapping.

3. Under System Management Tools, select Security > Mappings and Trusts.

4. Find the SID on the Mappings tab.

If a mapping based on the desired Windows group already exists:

ο Right-click the mapping and choose Properties. ο Note the Windows SID on the Mapping Properties dialog box.

If a mapping based on the desired Windows group does not exist:

ο Click New to open the Add New Mapping dialog box. ο In Windows Account, specify the Windows group. ο Note the SID inserted in Windows SID. ο Click Cancel.


50

To create a mapping based on a SID: 1. Open the piconfig utility.

a. Open a command window.

b. Navigate to the ..\PI\adm directory.

c. Type: piconfig

The piconfig command prompt appears.

2. Update the PI Identity Mapping table (PIIDENTMAP).

You must set at least three attributes:

ο IdentMap — Name of the PI identity mapping ο PIIdent — Name of the PI identity that you want to map to a local Windows group ο Principal — SID of the Windows group you want to map to the specified PI identity

You can also specify other table attributes, if desired.

For example, to create a new mapping called My_Mapping, which maps the Windows group specified by SID S-1-5-21-1234567890-1234567890-1234567890-12345 to the PI group, piadmins, you would enter the following commands at the piconfig prompts: @table PIIdentmap @mode create @istr IdentMap,Principal,PIIdent My_Mapping,S-1-5-21-1234567890-1234567890-1234567890-12345,piadmins

The following table lists all attributes in the PIIDENTMAP table. You can specify any of these attributes when you create a mapping.

Attribute Description

IdentMap The name of the PI mapping. This must be unique, but is not case-sensitive. This field is required to create a new mapping.

Desc Optional text describing the mapping. There are no restrictions on the contents of this field.

Flags Bit flags that specify optional behavior for the mapping. There are two options: 0x01 = Mapping is inactive and will not be used during authentication. 0x00 = (Default value). Mapping is active and will be used during authentication after initial setup.

IdentMapID A unique integer corresponding to the identity mapping. The system will automatically generate the value upon creation. Value will not change for the life of the identity mapping.

PIIdent Name of the PI identity to which the security principal specified by Principal will be mapped. The contents of this field must match Ident in an existing entry in the PIIDENT table. The target identity must not be flagged as Disabled or MappingDisabled. Multiple IdentMap entries can map to the same PIIdent entry. This field is required to create a new identity mapping



Attribute Description

Principal The name of the security principal (domain user or group) that is to be mapped to the identity named in PIIdent. This field is required to create a new identity mapping. For principals defined in an Active Directory domain, the format of input to this field can be any of the following: Fully qualified account name (my_domain\principal_name) Fully qualified DNS name (my_domain.com\principal_name) User principal name (UPN) (principal_name@my_domain.com) SID (S-1-5-21-nnnnnnnnnn-…-nnnn) For security principals defined as local users or groups, only the fully qualified account name (computer_name\principal_name) or SID formats may be used. Output from piconfig for this field will always be in SID format, regardless of which input format was used.

PrincipalDisp User-friendly rendering of the principal specified by Principal. This is an output-only field. The principal name will be displayed in the fully-qualified account name format.

Type This is a reserved field indicating the type of the mapping. In this release, this attribute is always set to 1.


This section discusses how you can improve the security on your Historian Server.

• Protect piadmin (page 53)

• Disable Historian Password Authentication (Explicit Logins) (page 54)

• Secure piconfig Utility (page 56)

• Retire SDK Trusts (page 56)

• Configure Historian Firewall (page 58)

• Disable PIWorld (page 59)

Protect piadmin

The piadmin PI user is the Historian Server super-user account. Take the following basic measures to protect this powerful account:

• Disable explicit logins for the piadmin account (Disable Explicit Logins for piadmin (page 53)). Explicit logins (also called password authentication) on the Historian Server are not nearly as secure as Windows authentication or Trusts. Instead, control access to this account through Windows authentication.

• If you cannot disable explicit logins for the piadmin account, then at least make sure that the piadmin account does not have a blank password. New Historian Server installations require a password for piadmin. While this is not mandatory for upgrades, it is strongly recommended.

• Restrict piadmin access to a small group of trusted administrators.

Note: Do not use piadmin for normal administrative tasks. See The piadmin User (page 8) for more information.

Disable Explicit Logins for piadmin

When you disable explicit logins for piadmin, users cannot access the Historian Server by typing in the username and password. However, mappings and trusts can still use piadmin.

To disable explicit logins for piadmin:

1. In SMT, open the Identities, Users, & Groups tool (under System Management Tools, select Security > Identities, Users, & Groups).

Chapter 5

Tightening Security

Tightening Security

54

2. Click the PI Users tab.

3. Double-click the piadmin entry.

The Properties dialog box opens.

4. On the General tab, select the User cannot be used for an explicit login check box.

5. Click OK.

Disable Historian Password Authentication (Explicit Logins)

When a user logs onto the Historian Server by typing in a PI user name and password, this is called an explicit login (or password authentication). Explicit logins on the Historian Server are the least secure authentication method available to you. A good security practice is to disable all explicit logins on the Historian Server. However, this is not always possible. You can alternatively disable explicit logins for some accounts. Here are your basic options:

• Disable All Explicit Logins (page 54). This is the most secure option, but if your current configuration requires users to log into PI user accounts, then you are not ready for this move.

• Disable Explicit Logins with Blank Passwords (page 55). If it is not possible for you to disable explicit logins, then you should disable explicit logins for all PI users with a blank password. Before doing so, give your users an opportunity to create passwords for their PI user accounts.

• Disable Explicit Logins for Individual User Accounts (page 56). As you begin to configure Windows authentication for your users, you can disable explicit logins for these accounts.

Disable All Explicit Logins

In SMT you can use the Security Settings tool to disable all explicit logins:

1. Under System Management Tools, select Security > Security Settings. The Security Settings tool opens.

2. Under Collectives and Servers, select the server. You can change settings for only one Historian Server at a time and only for Historian Servers running version 3.0 or later.

3. Move the slider to the Explicit login disabled option.

Disable Historian Password Authentication (Explicit Logins)


4. Click Save.

5. Stop and restart Historian Base Subsystem:

a. Under System Management Tools, select Operation > PI Services.

b. Right-click the PI Base Subsystem entry and choose Stop Service.

6. After the subsystem stops, right-click on the PI Base Subsystem entry again and choose Start Service.

Disable Explicit Logins with Blank Passwords

In SMT you can use the Security Settings tool to disable explicit logins for PI user accounts that do not have passwords:



3. Move the slider to the Blank password not allowed option.

4. Click Save.




Tightening Security

56

c. After the subsystem stops, right-click the PI Base Subsystem entry again and choose Start Service.

Disable Explicit Logins for Individual User Accounts

To disable explicit logins for a PI user account:

1. In SMT, open the Identities, Users, & Groups tool (Under System Management Tools, select Security > Identities, Users, & Groups).

2. Click the PI Users tab.

3. Double-click the username for the PI user.

4. The Properties dialog box for that PI user opens.

5. On the General tab, select the User cannot be used for an explicit login check box.

6. Click OK.

To re-enable explicit logins for a PI user account, clear the same check box.

Secure piconfig Utility

System managers who have physical access to the Historian Server computer and to the directory containing the Historian Server files are able to run all Historian Server management utilities as piadmin, without a prompt for a password. You can configure the Historian Server to force an explicit login in order to use piconfig and other command-line utilities. When you do this, the Historian Server requires administrators to type in a user name and password when they use these utilities.

To require explicit logins for utilities:

1. In SMT, select Operation > Tuning Parameters.

2. Click the Security tab.

3. In the list of parameters, double-click CheckUtilityLogin.

4. In Value, type: 1

5. Click OK.

Retire SDK Trusts

The PI SDK (version 1.3.6 and later) supports Windows authentication, so you can almost always use a mapping rather than a trust. You should do that for two reasons:

• Though more secure than explicit logins, Trusts are not as secure as Windows authentication.

Retire SDK Trusts


• If you create a trust, application users might still be authenticated through Windows and not the trust (When Both a Mapping and a Trust Apply (page 57)). This means that their access permissions will be dictated through Windows, rather than the trust.

After you replace your SDK trusts by Windows authentication, you can further secure the Historian Server by disabling SDK trusts altogether.

When Both a Mapping and a Trust Apply

If a Windows user running an SDK application has access to the Historian Server through Windows authentication (PI mappings and PI identities), then that user will be authenticated through Windows, rather than through the trust. This is because newer versions of the SDK try Windows authentication first.

This means that their access permissions will be dictated through the mappings, rather than the trust. It is best to retire SDK trusts wherever possible, and rely on the Windows authentication instead.

Note: You can configure to SDK to attempt the trust authentication first (Configure SDK Authentication Protocols (page 57)).

Configure SDK Authentication Protocols

When an SDK application tries to connect to the Historian Server, it tries all available authentication methods until it succeeds. You can configure the order in which it tries the authentication methods. The possible methods are:

• Windows Security. If a valid PI mapping exists for the Windows user (or for any group to which the user belongs) then the user is authenticated as the PI identity, PI user, or PI group defined for that mapping.

• Trust. If the connection request matches an existing Trust, then the user is authenticated as the PI identity, PI user, or PI group defined for that trust.

• Default User. A default PI user account.

The first method that succeeds defines the access permissions granted to the connecting application. Once one authentication method succeeds, no other methods are tried. By default the SDK (1.3.6 and later) tries to authenticate first through Windows.

You can configure which methods the SDK tries first. To do this from SMT:

1. Select File > Connections to open Connection Manager.

2. Select Tools > Options to open the Connection Option dialog box.

3. Under Specify Authentication Procedure, specify which protocols to allow and in which order to try them in Protocol order.

Note: You can also access Connection Manager from the About PI-SDK application. Select File > Connections.

Tightening Security

58

Disable SDK Trusts

In SMT you can use the Security Settings tool to disable access to the Historian Server through SDK trusts:



3. Move the slider to the SDK trusts are disabled option.

4. Click Save.




c. After the subsystem stops, right-click the PI Base Subsystem entry again and choose Start Service.

Configure Historian Firewall

For all incoming connections, the Historian Server first checks the PIFIREWALL table for partial or complete IP host names or addresses. If there is no entry in the table that allows the incoming connection, the Historian Server terminates the connection immediately.

By default, the PIFIREWALL table allows all connections. Edit the table to allow connections only from the subnets defined for your community of users. You can change settings for the table with the SMT Firewall tool, which you can access by choosing Security > Firewall. Historian Collectives do not replicate the Historian PIFIREWALL table.

Note: In order to change settings in the PIFIREWALL table, you need read/write access to the PITUNING entry in the Database Security tool. To access the Database Security tool, open SMT, choose Security > Database Security.

Disable PIWorld


Disable PIWorld

You can disable the PIWorld identity. This improves your control over access to the Historian Server. All users get only the access that is explicitly configured for them and no more. The decision to disable PIWorld should not be taken lightly.

• For Historian Server upgrades, or for new installations that are part of an existing configuration of Historian Interfaces and client applications, disabling PIWorld is a dangerous measure that could unintentionally lock down areas of access. It is very difficult to determine in advance which users or applications are relying on PIWorld access. If you need to disable PIWorld in these situations, consult technical support to help you form a plan.

• If this is a completely new installation, with no pre-existing Historian interface nodes or client applications, then you should definitely consider disabling PIWorld.


In most cases, the new security model does not affect Historian client applications. Additional security configuration steps might be necessary for:

• Products that Connect to an Application Server (page 62)

• Products That Connect Through a Trust (page 61) (most will work fine; some custom applications might need reconfiguring)

Unless a client meets one of the above criteria, it should work with the FactoryTalk Historian 3.0 without any extra configuration. If you want to use new Historian Server security features, you need to:

• Upgrade the PI SDK to version 1.3.6 or later. Nearly all functionality for the new Windows security on the client side resides within the PI SDK.

• Upgrade Administrative Client Applications (page 62) (applications that can set access permissions)

Note: PI API does not support Windows authentication. API-based applications can authenticate only through a Trust or explicit login. Most interfaces are Historian-API-based.

Products That Connect Through a Trust

Most interfaces connect to Historian using a Trust. Client applications can also connect through a Trust. When you upgrade to FactoryTalk Historian 3.0, your existing Trusts continue to work. The exception is that custom applications might have been accessing the Historian Server through wrongly-configured trusts and might no longer be able to connect. See Check for Unauthenticated API Connections (page 62) for more information.

If you have trusts defined against the piadmin super-user account, it is a good security practice to migrate these to a different PI identity, PI user, or PI group. See Protect piadmin (page 53). You will need to configure appropriate access permissions. Typically, for all relevant points, a Historian interface needs:

• Write access for point data

• Read access for point configuration

• Read access to PIPOINT in the Database Security tool, unless the interface supports point creation, in which case it needs read/write access

Chapter 6

How Will FactoryTalk Historian 3.0 Affect My Clients and Interfaces?


62

Note: In previous versions of the Historian Server, you could not define a Trust against a PI group. This restriction no longer applies. For FactoryTalk Historian 3.0 and later, you can define a Trust against a PI identity, a PI user, or a PI group.

If you are implementing a new FactoryTalk Historian System using FactoryTalk Historian 3.0, we recommend that you follow the instructions in Configure Historian Interface Connections (page 30).

Check for Unauthenticated API Connections

Previous versions of the Historian Server allowed unauthenticated API applications to connect to the Historian Server with world access. In previous versions of the Historian Server, you could explicitly close this security hole by using the DefaultUserAccess tuning parameter. FactoryTalk Historian 3.0 completely closes this security hole, and thus the DefaultUserAccess parameter no longer exists. Applications that do not successfully authenticate cannot be given any access on the Historian Server.

In most cases, the closing of this security hole should not cause you a problem. Since world access is usually read-only, your Historian Interfaces are unlikely to be relying on this access. However, if you have custom API applications, you might find that they were not configured properly and now no longer have access. You must configure valid Trusts for those applications.

To identify API applications that are not connecting properly, check the message log. Look for the following types of messages:

• Message ID = 7054, which contains text "No trust established for: <identifyingString>. Explicit login is required for access "

• Message ID = 7140, which contains text "Timeout expired for unauthenticated API Connection"

You can filter these unique message IDs in the SMT Message Logs tool.

Products that Connect to an Application Server

Certain Historian client applications require a connection to a separate application server in addition to a Historian Server.

Note: If you do not reconfigure security and connection settings to use the new security features, you see no change in your application servers. Upgrading to FactoryTalk Historian 3.0 does not require that you use its new security features.

Administrative Client Applications

Administrative applications are applications that allow you to configure access permissions. Examples are SMT, Point Builder, Module Database Builder, and so on. When you upgrade



to FactoryTalk Historian 3.0, your existing access permissions are converted to the new model. New versions of most administrative tools can display access permissions for either the old or the new model, depending on the version of the connected Historian Server.

Older versions of administrative applications cannot interpret new-model access permissions unless the access permissions are compatible with the old model. The display of incompatible access permissions depends on the specific client tool. Typically the tool will show:

owner: PIUserIncompatible group: PIGroupIncompatible

PIUserIncompatible and PIGroupIncompatible are built-in PI identities included in the FactoryTalk Historian 3.0 installation.

Which Administrative Tools are Compatible with FactoryTalk Historian 3.0

Older versions of administrative tools cannot properly display access permissions unless they follow the owner/group/world model. To work with new-model permissions, you need to run SDK 1.3.6 or later and you need a tool version that supports the new model. Here are the required versions for common administrative tools:

• SMT version 3.3.1.3 or later (includes Point Builder, Module Database tool, and Database Security tool)

• Tag Configurator version 2.1.3 or later

• Module Database Builder version 1.2.1.3 or later

• ICU 1.4.7 or later

• APS 1.2.5.0 or later

How to Maintain Backwards-Compatible Access Permissions

On previous versions of the Historian Server you could set permissions only for one owner, one group, and for world access (everyone else). If you plan to continue using an old-model security configuration, then you should continue to use the owner/group/world paradigm. This is to maintain backwards-compatibility with older client tools, which cannot interpret the new access permissions. For this to work, each PI resource must have assigned permissions for:

• One (and only one) PI user

• One (and only one) PI group

• PIWorld identity

If any of these conditions is not met, then the Historian Server cannot determine an owner and group. It will use the PIUserIncompatible and PIGroupIncompatible identities for the owner and group. Older versions of client tools will try to display an owner and group even when connected to new-model servers. If the access permissions are incompatible, then these tools will display the PIUserIncompatible and PIGroupIncompatible identity names.


64

Change PIUserIncompatible and PIGroupIncompatible Names

Older administrative applications that cannot interpret new-model access permissions display PIUserIncompatible and PIGroupIncompatible as the owner and group.

By default, PIUserIncompatible and PIGroupIncompatible are not displayed in the SMT Identities, Users, & Groups tool. To see them, click the Options button and then select the Show the incompatible PI User and PI Group check box. PIUserIncompatible and PIGroupIncompatible now appear in the Identities, Users, & Groups tool. You can change their names as you would any other PI user and PI group.


On FactoryTalk Historian 3.0 and later, Historian Module Database (MDB) is automatically synchronized with Historian Asset Framework (AF). If MDB is enabled, this synchronization is mandatory. FactoryTalk Historian 3.0 includes a new subsystem (the AF Link Subsystem) that performs the synchronization.

Both AF and the Historian Server leverage Windows for implementing security, but the extent and mechanism of the implementations are different. Because of these implementation differences, it is possible for the security configuration in MDB to diverge from that in AF, potentially causing access problems for users. A new guide, the Historian MDB to AF Transition Guide, provides details about synchronization.

To minimize security synchronization problems, follow these guidelines:

• The Historian Server and AF Server must either be in the same domain, in trusted domains, or in a trusted forest.

• Make sure the access permissions on PIModules in FactoryTalk Historian database security are the same as the access permissions on the Historian Server element in AF. You can edit the access permissions on PIModules using the Database Security tool in SMT (Security > Database Security).

• Use Windows authentication on the Historian Server for all MDB access. All the PI identities, users, and groups that have access to Modules must have explicit mappings. Furthermore, the Windows accounts from these mappings must be used directly in the AF permissions.

For example, suppose the Windows user Bob belongs to a group BobGroup, and BobGroup is mapped to a PI identity called ModuleAccessIdentity. ModuleAccessIdentity has access to a Module on the Historian Server. When modifying the security of the corresponding Element in AF, you should use BobGroup – not Bob itself – because BobGroup is the Windows account specified in the mapping.

• Do not delete mappings that are needed by module security. If you delete a Mapping that is needed by a module, then the access permissions for AF and MDB will no longer be synchronized, and you will not be able to edit the security of the affected Module.

• Make sure that no users rely on PIWorld for MDB access. PIWorld cannot be mapped, and access permissions defined for PIWorld are not reflected to AF.

• Make sure that no users rely on piadmin for MDB access. The piadmin PI user has unrestricted read and write access to everything on the Historian Server. Thus, Rockwell Automation recommends that you do not map piadmin and do not use it for routine access to the Historian Server. Reserve piadmin exclusively for the very few and rarely executed administrative tasks that no other PI identity can perform.

Chapter 7

MDB to AF Security Synchronization Considerations

MDB to AF Security Synchronization Considerations

66

• In AF, do not use deny access for any AF Element under the Historian Server element. AF allows you to explicitly deny access, but the Historian Server does not. If you use deny on an element in AF, then everyone except piadmin will lose all access to the corresponding module.


The following table lists the required access permissions for tasks on the Historian Server.

Task Database Security permissions

Other Permissions

Archives: Backing up PIBACKUP (r,w)

Archives: Create / Register / Unregister, Force Shift

PIARCADMIN (w)

Archives: Listing, Activity Grid, General Stats, Cache Stats

PIARCDATA (r)

Archives: Cache Control PIARCDATA (w)

Auditing: Enable PITUNING (r,w)

Auditing: View records PIAUDIT (r)

Backups: Perform Backups PIBACKUP (r,w)

Batch Database: Create / Edit / Delete / View PIUnit

A PIUnit is a module; see corresponding tasks for modules

Batch Database: Create / Edit / Delete PIUnitBatch, PISubBatch

PIModules (r) PIUnit (r*,w)

Batch Database: Create / Edit / Delete PIBatch

PIBatch (r,w)

Batch Database: Create / Edit / Delete PICampaign

PICampaign (r,w)

Batch Database: Create / Edit / Delete PITransferRecord

PITransferRecords (r,w) If src / dest is type PIBatch, also need permissions for task batch database: View PIBatch

If src / dest is type PIUnitBatch, also need permissions for task batch database: View PIUnitBatch, PISubBatch

If src / dest is type module, also need permissions for task modules: View

Batch Database: Insert / Remove PIUnitBatch into / from PIBatch

PIBatch (r,w) PIUnit (r*,w)

Batch Database: Insert / Remove PIBatch into / from PICampaign

PICampaign (r,w) PIBatch (r,w)

Appendix A

Task-Based Access Permissions Reference


68


Other Permissions

Batch Database: View PIUnitBatch, PISubBatch

PIModules (r) PIUnit (r1,w)

Batch Database: View PIBatch PIBatch (r) If contains PIUnitBatches, also need permissions for task batch database: View PIUnitBatch, PISubBatch

Batch Database: View PICampaign PICampaign (r) If contains PIBatches, also need permissions for task batch database: View PIBatch

Batch Database: View PITransferRecords

PITransferRecords (r)

If src / dest is type PIBatch, also need permissions for task batch database: View PIBatch

If src / dest is type PIUnitBatch, also need permissions for task batch database: View PIUnitBatch, PISubBatch

If src / dest is type module, also need permissions for task modules: View

Batch Subsystem: Create / Edit / Delete units and batches

PIBATCHLEGACY (r,w) unit (r,w)

Batch Subsystem: Create / Edit / Delete aliases

PIBATCHLEGACY (r,w) Permissions for task points: View attributes

Batch Subsystem: View units and batches

PIBATCHLEGACY (r) unit (r,w)

Batch Subsystem: View aliases PIBATCHLEGACY (r) Permissions for task points: View attributes

Database Security Table: Edit PIDBSEC (r,w) database security (w)

Database Security Table: View PIDBSEC (r)

Digital State Sets: Create / Edit / Delete digital sets or states

PIDS (r**,w)

Digital State Sets: View digital sets or states

PIDS (r**)

Event Queue: Configure PITUNING (r,w)

Firewall: Configure PITUNING (r,w)

HA: Create / Configure a Historian Collective

PIREPLICATION (r,w) PIBACKUP (r,w)

Heading Sets: Create / Edit / Delete heading set

PIHeadingSets (r***,w) heading set (r,w)




Other Permissions

Heading Sets: Create / Edit / Delete heading

PIHeadingSets (r***,w) heading set (r,w) heading (r,w)

Heading Sets: View heading set PIHeadingSets (r***) heading set (r)

Heading Sets: View heading PIHeadingSets (r***) heading set (r) heading (r)

Identities, Users, and Groups: Create / Edit / Delete

PIUSER (r,w)

Identities, Users, and Groups: View PIUSER (r)

Mappings: Create / Edit / Delete PIMAPPING (r,w)

Mappings: View PIMAPPING (r)

Message Log: Write messages PIMSGSS (w)

Message Log: View messages PIMSGSS (r)

Modules: Create PIModules (r,w)

parent module (r*,w)

Modules: Delete PIModules (r,w)

parent module (r*,w)

module (r1,w)

Modules: Edit PIModules (r)

module (r*,w)

Modules: Edit – Link / Unlink PIModules (r)

new parent module (r*,w)

module (r*,w)

Modules: Edit – Add / Remove alias PIModules (r)

module (r*,w) permissions for Task Point: View attributes

Modules: Edit – Add / Remove heading

PIModules (r) module (r*,w) permissions for Task Heading Sets: View heading

Modules: View PIModules (r) module (r*)

Points: Create PIPOINT (r,w)

Points: Delete PIPOINT (r,w) PtSecurity (r,w)

Points: Edit attributes PIPOINT (r) PtSecurity (r,w)

Points: Edit DataSecurity attribute PIPOINT (r) PtSecurity (r,w) DataSecurity (w)

Points: Add / Edit / Remove data PIPOINT (r) PtSecurity (r) DataSecurity (r,w)

Points: View attributes PIPOINT(r) PtSecurity (r)


70


Other Permissions

Points: View data PIPOINT(r) PtSecurity (r) DataSecurity (r)

Trusts: Create / Edit / Delete PITRUST (r,w)

Trusts: View PITRUST (r)

Tuning Parameters (Timeout Table): Create / Edit / Delete

PITUNING (r,w)

Tuning Parameters (Timeout Table): View

PITUNING (r)

*module (r) / PIUnit (r) also assumes (r) for all modules along the hierarchy path above it **PIDS (r) is implicitly granted by PIPOINT (r) ***PIHeadingSets (r) is implicitly granted by PIModules (r)


This section provides a product-by-product table reference that allows you to quickly determine what access permissions you might need given the presence of certain Historian clients, data access products, and/or interfaces.

In some cases, these product permission tables are followed by additional information regarding related configuration issues.

Appendix B

Product Access Permissions Reference and Configuration Issues


72

AF 2.x Client

Database Security Permission Notes

PIDS r

PIPOINT r,w

Point Database Permission Notes

PtSecurity r,w w: only necessary for autocreate option of Historian PointData Reference

DataSecurity r,w w: only if writing data to Historian

AF 1.3 Server


AF 1.3 Server


PIDS r

PIModules r,w

PIPOINT r,w not required for SQL backend


PtSecurity r,w not required for SQL backend

DataSecurity r,w not required for SQL backend

Module Database Permission Notes

Module Security* r,w both SQL and non-SQL backends require access

* Generic Client application permissions that can operate on any module


74

AF 1.3 Client


PIDS r

PIModules r

PIPOINT r,w w: only necessary for autocreate option of Historian PointData Reference


PtSecurity r,w w: only necessary for autocreate option of Historian PointData Reference

DataSecurity r,w w: only if writing to Historian


Module Security* r

* Generic Client application permissions that can operate on any module

ACE


ACE


PIModules r1,w2,3,4

PIPoint r1,w5

PIDS r

PIMSGSS r1,w2

PIDBSec r2,3,4,5


PtSecurity r1,w5

DataSecurity r1,w2


Module Security* r1,w2,3,4

* Generic client application permissions that can operate on any module 1 In order for ACE Manager to look at ACE configuration, read permission is required for PIPoint and PIModules, as well as on the Module Database. 2 ACE schedulers/hosts have two types of connection to the Historian Server: PI SDK and PI API.

The PI SDK connections need read/write permission to the PIModules containing the ACE configuration. PI SDK connections also need read permission for all data source points and digital states.

The PI API connection needs read/write permission for all output points for the ACE modules. Typically, a Trust has to be setup for the PI API connection while the PI SDK connection can be mapped to a Windows user. If ACE scheduler/host is running on a Historian Server, it needs read/write permission to the PIMSGSS to log messages. 3 Users of ACE Manager that configure and manage ACE calculations need read/write permission to PIModules. Most of the tasks in ACE Manager only require read permission to the PIPoint table. Item 5 below describes the exception. 4 Users developing ACE calculations using the ACE wizard in a MS Visual Studio environment need read/write permission to PIModules, and read permission to the data source tags, including the PIDS table. 5 ACE wizard includes the option to configure/create tags. To use this option, you need read/write permission to the PIPoint table and read permission to PIDBSec.


76

FactoryTalk Historian DataLink


PIModules r

PIPOINT r


PtSecurity r

DataSecurity r,w w: only necessary for users that write data to Historian


Module Security* r

* Generic client application permissions that can operate on any module

DataSheet Control


DataSheet Control


PIUSER r

PIBatch r,w w: to create PIBatches, and to insert PIUnitBatches into PIBatches

PIModules r

PIPoint r


PtSecurity r

DataSecurity r,w w: to edit point data


Module Security* r,w w: for PIUnits to create PIUnitBatches and insert PIUnitBatches into PIBatches



78

PI Groups and DataSheet Control

Some features of the DataSheet Control are tied to PI groups. Specifically, some regulatory features let you limit the ability to commit and confirm manually entered data to a user-specified PI group. You can limit commit functionality to one PI group, and limit confirm functionality to a different PI group. Users who do not belong to the specified regulatory user groups within the DataSheet Control receive an error that indicates they do not have the required permissions to commit or confirm data. See the DataSheet Control User Guide for more information.

FactoryTalk Historian 3.0 continues to support PI groups for backwards compatibility. See What About PI Users and PI Groups? (page 5) for more information.

DataSheet Control


FactoryTalk Historian BatchView


PIBatch r r: to execute PIBatch queries, retrieve anchored PIBatch records, and detect updates to PIBatch records

PIDS r r: to display tag data in the batch trend

PIModules r r: required for all of the following: + to access the unit properties associated with the PIUnitBatch. Both the Gantt and Results require read access to show unit name and heading properties. + to resolve aliases to a tag (for the trend). + to execute queries for PIUnitBatch records on a particular unit + to detect updates to PIUnitBatch and PISubBatch records (to reflect on the results, Gantt and Trend)

PIPOINT r r: to show any traces on the Batch Trend


PtSecurity r

DataSecurity r


Module Security* r same as for PIModules Database Security



80

Configuring Security for FactoryTalk Historian BatchView

Point Database Security Read access is required to DataSecurity and PtSecurity for all tags used by FactoryTalk Historian BatchView. This includes all tags associated with aliases in the PIUnit and any additional tags displayed in the batch trend.

Without read access to an alias in the PIUnit, a warning will appear on the trend indicating that the alias could not be resolved. Access to a tag's time series data (including its annotations) and point attributes (such as description) are all controlled by the tag's DataSecurity and PtSecurity, respectively.

PIUnitBatch records are stored in a special tag corresponding to the PIUnit. The name of this tag is the same as the Unique ID of the PIUnit's module. Without read access to the DataSecurity for this tag, PIUnitBatch records cannot be retrieved (by either a batch query or anchored) and updates will not be detected, which may be indicated by an error for the batch group symbol (if a specific unit path is used).

Caution: The Historian Server will automatically edit the security of the underlying tag based on changes to the security of the PIUnit's module. Thus, the tag's security attributes should never be modified directly to ensure they do not get out of sync with the PIUnit's module. Only the security of the PIUnit's module should be edited.

Module Database Security Read access is required for the PIUnit's module associated with any PIUnitBatch records used by FactoryTalk Historian BatchView. Read access is required to perform the same actions as identified in the PIModules Database Security section above.

Read access for the PIUnit's sub-modules is optional. Without read access, the sub-module and any aliases are not visible to FactoryTalk Historian BatchView. This may be desirable since the Historian Batch Generator Interface places a sub-module under the unit to store configuration information (identified by the Configuration Module Name of the Batch Generator configuration). These sub-modules should be visible to the identity used by the Historian Batch Generator Interface.

Read access is required for all the PIUnit's parent modules. Without read access on the parent, the PIUnit cannot be found when a specific unit path is specified in a PIBatch or PIUnitBatch search (such as \\piserver\parent\reactor).

Historian Notifications


Historian Notifications


PIDS r1

PIPOINT r1,w2

PIMSGSS r,w2


PtSecurity r1,w2

DataSecurity r1,w2

1 Read permission for Historian Notification client (e.g. FactoryTalk Historian System Explorer) is required to the PIDS and PIPoint tables as well as to the data source tags and notification history tags. 2 Historian Notification schedulers/processors have two types of connection to the Historian Server: PI SDK and PI API.

The PI API connection needs read/write permission for notification history tags so that the processor can create and edit these tags. Typically, you need a Trust for the PI API connection while the PI SDK connection can be mapped to a Windows user. If the Historian Notification scheduler and processors are running on a Historian Server, then they also need read/write permission to PIMSGSS for error message logging.


82

Historian OLEDB


PIBatch r,w r,w: to query pibatch..pibatch or pibatch..pibatchproperty tables

PICampaign r,w r,w: to query pibatch.. picampaign or pibatch.. picampaignproperty tables

PIDS r,w

PIHeadingSets r,w

PIModules r,w

PIPOINT r,w r,w: to connect to Historian OLEDB

PITransferRecords r,w r,w: to query pibatch..pitransfer or pibatch..pitransferproperty tables

PIUSER r,w r,w: to query any table in the piuser catalog


PtSecurity r,w

DataSecurity r,w


Module Security* r,w


FactoryTalk Historian ProcessBook


FactoryTalk Historian ProcessBook


PIBatch r

PICampaign r

PIDBSEC r

PIDS r

PIHeadingSets r

PIModules r

PIPOINT r,w1 r,w: to use the annotation feature of the FactoryTalk Historian ProcessBook Details add-in

PITransferRecords r

PIUSER r


PtSecurity r

DataSecurity r,w r,w: the annotation feature requires write access to the point being annotated


Module Security* r

* Generic client application permissions that can operate on any module 1 Write access not required if you have PI SDK 1.4 or later installed

Note: FactoryTalk Historian ProcessBook Displays that contain custom VBA code might require additional security configuration depending on what PI SDK calls are invoked.

RtAlerts


PIDS r


84


PIModules r,w

PIPOINT r


PtSecurity r

DataSecurity r




Historian data Services


Historian data Services


PIBatch r

PIDBSEC r

PIHeadingSets r

PIModules r,w r: for FactoryTalk Historian data Services ProcessID w: for an administrator UserID to make configuration changes

PIPOINT r

PIUSER r


PtSecurity r

DataSecurity r,w w: for the UserID only if data writes are performed by RtPM Business package


Module Security* r,w r: for FactoryTalk Historian data Services ProcessID w: for an administrator UserID to make configuration changes



86

Configuring Security for FactoryTalk Historian data Access Products

Security for the Data Access Web Services, or other products that use the FactoryTalk Historian data Services component, requires configuration of two user accounts:

• UserID, or user mapping, used when connecting the client machine to the Web server to ensure that queries for FactoryTalk Historian System data use the identity of the end user who makes the request.

• ProcessID, or process mapping, used in the Web server connection to the Historian Server to allow the Web server to process all updates to data and configuration on behalf of all end users.

To identify the UserID and ProcessID used in a given session:

• If you are using Web Services, open IIS Manager and select the Application Pools node to view the Windows identity that is used. Then, use SMT to inspect the PI identity to which the Windows identity is mapped.

To take advantage of Windows Integrated Security:

• Both the UserID and the ProcessID need to be valid Active Directory users with at least one mapping between a PI identity and a Windows identity. Rockwell Automation recommends that you map the UserID and the ProcessID to two different PI identities, but this is not mandatory.

• Kerberos delegation must be configured between the Web server and Historian Server if you are using Web Services, or between the SharePoint Server and Historian Server.

• The client machine must belong to the same Active Directory forest.

Note: If membership in an AD group used in a PI mapping is modified, or if a relevant PI mapping itself is modified, you might need to restart IIS.


Interfaces

Interfaces that Create Points


PIPOINT r,w1 r,w: for any interface that creates or deletes points


PtSecurity r,w

DataSecurity r,w

1 Interfaces with separate utilities that create points (for example, Historian-Perfmon, Historian-Ping, SNMP, etc.) and run from SMT only require that you have read access for PIPOINT.


88

Historian to Historian TCP/IP Interface

Database Security Source Historian Server

Receiving Historian Server

Notes

PIPOINT r r

Point Database Source Historian Tags

Receiving Historian Tags

Notes

PtSecurity r r

DataSecurity r r,w

Interfaces


Historian OPC DA/Historian OPC HDA Interfaces


PIPOINT r


PtSecurity r

DataSecurity r,w


90

Configuring Security for OPC Server The OPC Server connects to a Historian Server using both the PI SDK and PI API. The PI SDK is used to read data from the Historian Server, and the PI API is used to write data to the Historian Server.

The following connection options are available for the OPC Server:

• [recommended] Connect to the Historian Server via a Trust set up with a PI identity. This will allow both the PI SDK and the PI API to connect. With this method you can have read and write access permissions granted to that PI identity. See How to Create a Trust (page 31) for more details.

• Connect to the Historian Server via Windows Security with a PI identity. Because the PI API does not support Windows Security, this option only allows the PI SDK to connect; therefore, the OPC Server will only have read access to the Historian Server.

• [recommended] Connect to Historian Server using both a Trust and Windows Security. Set up a trust for the PI API connection and use Windows Security for the PI SDK connection. This option is recommended, but slightly more complicated to set up.

Interfaces


APS

Database Security APS Configuration Utility

Sync Engine

Sync Trigger PItoPI_APS

PIDS None for read-only mode; r,w: to interactively create or edit digital sets/states(for digital points)

r,w: for automatic set/state creation and edits (for digital points); r: for non-automatic modes

r

PIModules r: to review APS configuration; r,w: to change APS configuration

r,w r,w

PIPOINT None for read-only mode; r,w: to interactively create or delete points

r,w: for automatic point creation; r: for non-automatic modes

r

Point Database APS Configuration Utility

Sync Engine±

Sync Trigger²

PItoPI_APS³

PtSecurity r: to display existing interface points; r,w: to interactively edit or delete interface points

r,w: to automatically edit or delete points; r: for non automatic modes

r

DataSecurity

Module Database APS Configuration Utility

Sync Engine

Sync Trigger PItoPI_APS

Module Security* r: to review APS configuration r,w: to change APS configuration

r,w r,w



92

1 The Synchronization Engine runs as a service and therefore requires some form of automatic log on (either a Trust or new PI mapping).

² Synchronization Trigger is also a service and therefore requires some form of automatic log on. Without write permission for the Module Database, Synchronization Trigger is non-functional. Synchronization Trigger only uses the Module Database (no point access).

³ The PItoPI_APS Connector requires read permission to points on the source Historian Server. Since APS Connectors run inside the Synchronization Engine process, which is a service, some form of automatic log on to the source Historian Server is required. That is, the Synchronization Engine that is running the PItoPI_APS Connector requires automatic log on to two Historian Servers: the target Historian Server and the source Historian Server. The method of connection and the access rights granted do not need to be the same for both Historian Servers. The Synchronization Engine only needs read access to the PIPOINT and PIDS tables on the source Historian Server for the PItoPI_APS Connector to function. However, the Synchronization Engine requires read and write access to the PIPOINT and PIDS tables for automatic point creation on the target Historian Server. For non-automatic modes, only read access is needed (on the target Historian Server).

Interfaces


Configuring Security for APS In order to run APS, you must configure the Historian Server to allow connections from the APS Configuration Utility, APS Synchronization Engine, and APS Synchronization Trigger service. This section discusses the information that you need to configure:

• connection methods for the APS programs, and

• Historian Server security to grant the required access rights to these connections.

Note: A copy of APS on the Historian Server node does not require any security configuration in the Historian Server, however Rockwell Automation discourages using APS on the Historian Server node except to synchronize points for Historian COM Connectors.

The APS Synchronization Engine and APS Synchronization Trigger service are both Windows services. You need to set up either a Trust or a PI mapping to connect each of them to the Historian Server. The APS Configuration Utility is an interactive application, so you can use either a Trust, a PI mapping, or an explicit login to a Historian Server User account. PI mappings are the most secure option; explicit logins are the least secure. Use PI mappings where possible (PI mappings require Historian Server version 3.0 and PI SDK 1.3.6 or later).

PI Mappings for Windows Services By default, APS services log on as the Local System account, which cannot be used for PI mappings on a remote Historian Server. In order to create a PI mapping, you must first change the APS services to log on as Windows accounts (e.g. domain accounts) that are configured with sufficient privileges to access the local Windows registry and files.

Module Database Permissions The APS Configuration Utility creates the module AutoPointSync under the %OSI module. APS configuration settings are stored in a hierarchy of modules under this module. Other information also is stored in the modules used by APS. For example, the last synchronization time (stored by the APS Synchronization Engine) and the SyncImmediately flag (set by the APS Synchronization Trigger service or APS Configuration Utility) are stored in the AutoPointSync hierarchy.

The APS Configuration Utility requires:

• Write access for the PIModules table (Database Security) in order to create modules

• Write access for the %OSI module in order to create the AutoPointSync module

• Write access for the AutoPointSync hierarchy to register interface instances with APS, to change configuration settings, or to manually initiate a synchronization scan. Read access is sufficient to view configuration settings.

The APS Synchronization Engine and APS Synchronization Trigger service require write access for modules in the AutoPointSync hierarchy for normal operation.


94

Point Database Permissions To create or delete points, the APS Synchronization Engine or APS Configuration Utility requires write access for the Historian Server PIPOINT table. To edit points, the APS Synchronization Engine or APS Configuration Utility requires write access for individual points.

The APS Synchronization Trigger service does not access the Historian Server point database.

Historian Points have two sets of security attributes: one set controls access to the point attributes and the other set controls access to the point data. APS needs write access for point attributes of the points that are associated with interface instances registered for synchronization.

APS does not access point data.

Digital State Table Permissions To create digital sets, the APS Synchronization Engine or APS Configuration Utility requires write access for the Historian Server digital state table (PIDS in Database Security). The APS Synchronization Trigger service does not access the Historian Server digital state table.

Interfaces


ICU


PIDS r,w w: to create "InterfaceStatus" digital set if it does not exist

PIModules r,w

PIPOINT r,w w: to create or delete Perfmon Performance Counter Points, UniInt Performance Points, or UniInt Health Points


PtSecurity r, w





96

Configuring ICU When ICU is installed on an interface node, the ICU obtains permissions to access Historian Server objects by logging on with some form of credentials. The Historian Server authenticates these credentials and establishes a security context for each client program. The security context is specific to the credentials used to log on. Each securable Historian Server object has access control information. Authorization for a client program to access a securable Historian Server object is determined by comparing information in the security context with the access control information for the object.

Several methods are available for logging on:

• Explicit login

• Trust

• PI mapping (requires Historian Server version 3.0 or later and PI SDK 1.3.6 or later)

The ICU is an interactive application and all the methods for logging on to the Historian Server can be used.

If the Historian Server is version 3.0 or later, Rockwell Automation recommends using Windows security through PI mappings. Windows security provides the strongest authentication and full Windows account traceability in the Historian Server log and audit trail records.

Module Database Permission The ICU creates the module interfaces under the %OSI module. ICU configuration settings are stored in a hierarchy of modules under the interfaces module.

The ICU requires the following:

• Write access for the PIModules table (Database Security) in order to create modules

• Write access for the %OSI module in order to create the interfaces module

• Write access for the interfaces hierarchy to register interface instances with ICU and to change configuration settings

Digital State Table Permissions When ICU starts, it checks for the existence of a digital set named InterfaceStatus. If this digital set does not exist, ICU requires write access for the Historian Server digital state table (PIDS in Database Security) to create the InterfaceStatus digital set.

When UniInt Failover is configured for an interface instance, ICU checks for the existence of a digital set that is used by special UniInt Failover digital points. If this digital set does not exist, ICU requires write access for the Historian Server digital state table (PIDS).

The ICU controls for some interfaces can create specific digital sets that the interface needs. Since ICU controls run inside the ICU process, ICU requires write access to the Historian Server digital state table for an ICU control to create digital sets. See the ICU control section of the interface user guide for more detail.

Interfaces


Point Database Permissions ICU can create, edit, or delete the following types of points that are common to UniInt-based interfaces:

• Historian Perfmon Performance Counter Points

• UniInt Performance Points

• UniInt Health Points

To create or delete these types of points, ICU requires write access for the Historian Server PIPOINT table (Database Security).

To edit or delete individual points of these types, ICU requires write access for each point. Historian Points have two sets of security attributes: one set controls access to the point attributes and the other set controls access to the point data. ICU needs write access for point attributes of these types of points. ICU does not access point data.

The ICU Controls for some interfaces have the ability to create interface-specific points. Consult the user guide for each interface that ICU manages. Since ICU Controls run inside the ICU process, the ICU requires write access for the Historian Server PIPOINT table for an ICU Control to create points.


Here are the highlights of the latest version of SMT:

Useful New Features:

How am I connected? (What users, groups, and identities?)

SMT now tells you exactly how you are connected to each Historian Server (whether through a trust, a mapping, or an explicit login). The lower left corner contains an information panel with this information. Click for more complete information.

How can I connect as a specific PI User?

You can now connect as a specific user: Right-click a Historian Server under Collectives and Servers and choose Connect As. (This will not work if explicit logins are disabled.)

New Tools

Backup tool Allows you to view backup history and run quick backups (not for scheduling regular backups)

Security Settings tool Allows you to choose a security level for Historian Servers (for Historian Server versions 3.0 and later only)

Firewall tool Allows you to configure the Historian Server firewall

Tool Changes:

Users and Groups tool The Users and Groups tool becomes the Identities, Users, & Groups tool. When connected to a Historian Server version 3.0 and later, it includes a PI Identities tab. The PI Identities tab does not appear unless you are connected to at least one appropriately versioned Historian Server.

Trusts tool The Trusts tool becomes the Mappings and Trusts tool. When connected to a Historian Server version 3.0 and later, it includes a Mappings tab. The Mappings tab does not appear unless you are connected to at least one appropriately versioned Historian Server.

Message Log tool The Message Log viewer has been greatly enhanced with new filtering and searching options and fields.

Appendix C

New SMT Highlights


This table lists the basic steps for configuring an upgraded Historian Server for Windows authentication.

Step Notes

Review existing access permissions See Step 1. Review Access Permissions (page 38)

Create a list of unique access strings See Step 2. Create List of Unique Access Strings (page 39)

Identify PI groups and PI users that will be retained

See Step 3. Create a Configuration Plan (page 41)

Create new identities to fill gaps See Step 4. Create PI Identities to Fill Gaps (page 43)

If using AD, determine which AD groups are needed and which identities to map them to

(AD only) See Step 5. Review AD Group (page 43)

If using local Windows security, determine which local Windows groups are needed and which identities to map them to

(only if using local Windows security)

If using local Windows security, configure matching Windows user accounts and passwords on Historian Server and client workstations

(only if using local Windows security)

Create mappings See Step 6. Create Mappings (page 44)

Verify configuration See Step 7. Verify Initial Configuration (page 44)

Check custom API applications, if any (if any) See Check for Unauthenticated API Connections (page 62)

Upgrade the SDK to 1.3.6 or later on client computers

(required for Windows authentication)

Configure clients that connect through an application server (for example, Historian DLES and PI WebParts)

(if any) See Products that Connect to an Application Server (page 62)

Upgrade administrative applications: SMT version 3.3.1.3 or later Tag Configurator version 2.1.3 or later Module Database Builder version 1.2.1.3 or

later ICU 1.4.7 or later PI APS 1.2.5.0 or later

See Administrative Client Applications (page 62)

Appendix D

Checklist: Configure Windows Authentication for Upgrades

Checklist: Configure Windows Authentication for Upgrades

102

Disable explicit logins (Optional) See Disable PI Password Authentication (Explicit Logins) (page 54)

Replace SDK trusts with PI mappings (Optional) Retire SDK Trusts (page 56)

Retire obsolete PI users and PI groups (Optional)


This table lists the basic steps for configuring a new Historian Server for Windows authentication.

Step Notes

Identify user access categories Identify User Access Categories (page 15)

Create a PI identity for each access category (you can also use built-in identities, users, or groups, such as piadmins)

Create PI Identities (page 17)

If using AD, determine which AD groups are needed and which identities to map them to

(if using AD) See Review AD Configuration (page 17)

If using local Windows security, determine which local Windows groups are needed and which identities to map them to

(only if using local Windows security) See Configure Windows Groups (page 26)

If using local Windows security, configure matching Windows user accounts and passwords on PI Server and client workstations

(only if using local Windows security) See Use Local Windows Security (page 21)

Create the mappings for AD: Map AD Groups to PI Identities (page 20) for local Windows security: Create Mappings (page 27)

Configure access permissions Configure Access Permissions (page 21)

Configure authentication for interfaces Configure PI Interface Connections (page 30)

Check custom API applications, if any (only for installations with existing clients & interfaces) See Check for Unauthenticated API Connections (page 62)

Upgrade the SDK on client computers to 1.3.6 or later

(only for installations with existing clients & interfaces; required for Windows authentication)

Configure clients that connect through an application server (for example, PI DLES and PI WebParts)

(if any) See Products that Connect to an Application Server (page 62)

Upgrade administrative applications: SMT version 3.3.1.3 or later Tag Configurator version 2.1.3 or later Module Database Builder version 1.2.1.3 or

later PI ICU 1.4.7 or later PI APS 1.2.5.0 or later

(only for installations with existing clients & interfaces) See Administrative Client Applications (page 62)

Disable explicit logins (Optional) See Disable PI Password Authentication (Explicit Logins) (page 54)

Appendix E

Checklist: Configure Windows Authentication for New Installations

Rockwell provides dedicated technical support internationally, 24 hours a day, 7 days a week.

You can read complete information about technical support options, and access all of the following resources at the Rockwell Automation Support Web site:

http://www.rockwellautomation.com/support/

Before You Call or Write for Help

When you contact Rockwell Technical Support, please provide:

• Product name, version, and/or build numbers

• Computer platform (CPU type, operating system, and version number)

• The time that the difficulty started

• The message log(s) at that time

Help Desk and Telephone Support

Telephone support is available 24 hours a day, 7 days a week.

• North America: 1-440-646-3434

• Outside of North America: http://www.rockwellautomation.com/locations/

Knowledgebase

The KnowledgeBase provides a searchable library of documentation and technical data, as well as a special collection of resources for system managers.

http://www.rockwellautomation.com/knowledgebase/

Find the Version and Build Numbers

To find version and build numbers for each Historian Server subsystem (which vary depending on installed upgrades, updates or patches) use either of the following methods:

If you have System Management Tools (SMT) installed, choose Start > Programs > Rockwell Software > FactoryTalk Historian SE > System Management Tools. In SMT, select the server name, then under System Management Plug-Ins, open Operation > PI Version. The Version tree lists all versions.

If you do not have SMT installed, open a command prompt, change to the pi\adm directory, and enter piversion -v. To see individual version numbers for each

Technical Support and Resources

Copyright © 2013 Rockwell Automation, Inc. All rights reserved. Printed in the U.S.A.

Rockwell Automation Support Rockwell Automation provides technical information on the Web to assist you in using its products. At http://www.rockwellautomation.com/support/, you can find technical manuals, a knowledge base of FAQs, technical and application notes, sample code and links to software service packs, and a MySupport feature that you can customize to make the best use of these tools. For an additional level of technical phone support for installation, configuration, and troubleshooting, we offer TechConnect support programs. For more information, contact your local distributor or Rockwell Automation representative, or visit http://www.rockwellautomation.com/support/.

Installation Assistance

If you experience a problem within the first 24 hours of installation, review the information that is contained in this manual. You can contact Customer Support for initial help in getting your product up and running. United States or Canada 1.440.646.3434 Outside United States or Canada

Use the Worldwide Locator at http://www.rockwellautomation.com/support/americas/phone_en.html, or contact your local Rockwell Automation representative.

New Product Satisfaction Return

Rockwell Automation tests all of its products to ensure that they are fully operational when shipped from the manufacturing facility. However, if your product is not functioning and needs to be returned, follow these procedures. United States Contact your distributor. You must provide a Customer Support case number (call the phone number above to obtain

one) to your distributor to complete the return process. Outside United States Please contact your local Rockwell Automation representative for the return procedure.

Documentation Feedback

Your comments will help us serve your documentation needs better. If you have any suggestions on how to improve this document, complete this form, publication RA-DU002, available at http://www.rockwellautomation.com/literature/.



http://www.rockwellautomation.com/support/americas/phone_en.html

http://www.rockwellautomation.com/literature/

configuring factorytalk historian se...

Documents