Configuring FT Historian SE Security

CONFIGURING FACTORYTALK HISTORIAN SE SECURITY
Rockwell Automation Publication HSECHS-UM031A-EN-ESeptember 2013

Supersedes Publication HSECHS-UM030A-EN-E
Contacting Rockwell
Customer Support Telephone 1.440.646.3434

Online Support http://www.rockwellautomation.com/support/overview.page
Copyright Notice
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.
Trademark Notices
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.
Other Trademarks
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.
Warranty
This product is warranted in accordance with the product license. The products 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 products 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.
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
Configuring FactoryTalk Historian SE Security
iii
Table of Contents
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
iv
New SMT Highlights ..................................................................................................................... 99

Checklist: Configure Windows Authentication for Upgrades ................................................101
Checklist: Configure Windows Authentication for New Installations ...................................103
Chapter 1
Introduction to Historian Server Security

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)
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.
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.
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.
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
8
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 nonexplicit 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
security automatically reflects these changes. You also get complete traceability of the
specific Windows account in the Historian Server log and audit trail records.
10
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.
Chapter 2
Configuring Security on a New Historian Server

Installation
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.
11
Configuring Security on a New Historian Server Installation
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.
12
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 explicitlyconfigured 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)).
13
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
14
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
15
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:
16
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.
17
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
18
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.
19
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
to verify that this is a valid account. If the account is valid, an
resolve SID button
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:
20
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.
21
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:
22
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 TaskBased 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.
23
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:
24
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).
25
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.
26
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.
27
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:

resolve SID button
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).
28
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,
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
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:
29

3. Select the PI Groups tab.
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,
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
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.
30
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.
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:
31
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).
32
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.
33
Chapter 3
Configuring Security for Historian Server

Upgrades
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.
35
Configuring Security for Historian Server Upgrades
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:
36
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).
37
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.
38
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.
39
point
dataaccess
datagroup
dataowner
tag1
o:rw g:r w:r
pi_ops
bob
tag2
o:rw g:r w:r
pi_ops
bob
tag3
o:rw g:r w:r
pi_ops
bob
tag4
o:rw g:rw w:r
pi_eng
nancy
tag5
o:rw g:r w:r
pi_ops
bob
The following table shows what the same access permissions look like after upgrading to
Historian Server version 3.0.
40
point
datasecurity
tag1
bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)
tag2
tag3
tag4
nancy: A(r,w) | pi_eng: A(r,w) | PIWorld: A(r)
tag5
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
datasecurity for: tag1, tag2,

tag3, tag5
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:
41
Points
datasecurity
tag4
tag1, tag2, tag3, tag5
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.
42
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.
43
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:

resolve SID button
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.
44
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 descriptivelynamed PI identities.
45
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).
46
Chapter 4
Security for Historian Collectives

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 configurationone where all collective members are in the same security
environment and you are using ADyou configure security on the collectives primary
server just as you would configure a single Historian Server. The collectives 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.
47
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 groups 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.
48
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 servers 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 groups 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.
49
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-123456789012345,piadmins
The following table lists all attributes in the PIIDENTMAP table. You can specify any of
these attributes when you create a mapping.
50
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 outputonly 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.
51
Chapter 5
Tightening Security
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).
53
Tightening Security
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.
54
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.
55
Tightening Security
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:
56
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.
57
Tightening Security
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.
58
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.
59
Chapter 6
How Will FactoryTalk Historian 3.0 Affect My

Clients and Interfaces?
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 HistorianAPI-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
61
How Will FactoryTalk Historian 3.0 Affect My Clients and Interfaces?
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
62
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.
63
How Will FactoryTalk Historian 3.0 Affect My Clients and Interfaces?
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.
64
Chapter 7
MDB to AF Security Synchronization

Considerations
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.
65
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.
Appendix A
Task-Based Access Permissions Reference

The following table lists the required access permissions for tasks on the Historian Server.
Task
Database Security
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
Other Permissions
A PIUnit is a module; see

corresponding tasks for
modules
PIUnit (r*,w)

Delete PIUnitBatch, PISubBatch
PIModules (r)

Delete PIBatch
PIBatch (r,w)

Delete PICampaign
PICampaign (r,w)

Delete PITransferRecord
PITransferRecords (r,w)
If src / dest is type

PIBatch, also need
permissions for task
batch database: View
PIBatch
PIUnitBatch, also need
PIUnitBatch,
PISubBatch
module, also need
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)
67
68
Task
Database Security
permissions
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)

PIBatch, also need
PIBatch
PIUnitBatch, also need
PIUnitBatch,
PISubBatch
module, also need
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)
Task
Database Security
permissions
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)
69
Task
Database Security
permissions
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)
70
Appendix B
Product Access Permissions Reference and

Configuration Issues
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.
71
Product Access Permissions Reference and Configuration Issues
AF 2.x Client
72
Database Security
Permission
Notes
PIDS
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
Database Security
Permission
Notes
PIDS
PIModules
r,w
PIPOINT
r,w
not required for

SQL backend
Point Database
Permission
Notes
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
73
AF 1.3 Client
Database Security
Permission
Notes
PIDS
PIModules
PIPOINT
r,w
w: only
necessary for
autocreate
option of
Historian
PointData
Reference
Point Database
Permission
Notes
PtSecurity
r,w
w: only
necessary for
autocreate
option of
Historian
PointData
Reference
DataSecurity
r,w
w: only if writing
to Historian
Module Database
Permission
Notes
Module Security*
* Generic Client application permissions that can operate on any module
74
ACE
ACE
Database Security
Permission
PIModules
r1,w2,3,4
PIPoint
r1,w5
PIDS
PIMSGSS
r1,w2
PIDBSec
r2,3,4,5
Point Database
Permission
PtSecurity
r1,w5
DataSecurity
r1,w2
Module Database
Permission
Module Security*
r1,w2,3,4
Notes
Notes
Notes
* 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.
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.
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.
75
FactoryTalk Historian DataLink

Database Security
Permission
Notes
PIModules
PIPOINT
Point Database
Permission
PtSecurity
DataSecurity
r,w
w: only
necessary for
users that write
data to
Historian
Module Database
Permission
Notes
Module Security*
Notes
76
DataSheet Control
DataSheet Control
Database Security
Permission
Notes
PIUSER
PIBatch
r,w
PIModules
PIPoint
Point Database
Permission
PtSecurity
DataSecurity
r,w
w: to edit point data
Module Database
Permission
Notes
Module Security*
r,w
w: for PIUnits to create

PIUnitBatches and
insert PIUnitBatches
into PIBatches
w: to create PIBatches,
and to insert
PIUnitBatches into
PIBatches
Notes
77
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 userspecified 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.
78
DataSheet Control
FactoryTalk Historian BatchView

Database Security
Permission
Notes
PIBatch
r: to execute PIBatch queries,

retrieve anchored PIBatch
records, and detect updates to
PIBatch records
PIDS
r: to display tag data in the

batch trend
PIModules
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: to show any traces on the

Batch Trend
Point Database
Permission
Notes
PtSecurity
DataSecurity
Module Database
Permission
Notes
Module Security*
same as for PIModules

Database Security
79
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).
80
Historian Notifications
Historian Notifications
Database Security
Permission
PIDS
r1
PIPOINT
r1,w2
PIMSGSS
r,w2
Point Database
Permission
PtSecurity
r1,w2
DataSecurity
r1,w2
Notes
Notes
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.
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.
81
Historian OLEDB
Database Security
Permission
Notes
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
Point Database
Permission
Notes
PtSecurity
r,w
DataSecurity
r,w
Module Database
Permission
Module Security*
r,w
Notes
82
FactoryTalk Historian ProcessBook
FactoryTalk Historian ProcessBook

Database Security
Permission
Notes
PIBatch
PICampaign
PIDBSEC
PIDS
PIHeadingSets
PIModules
PIPOINT
r,w1
PITransferRecords
PIUSER
Point Database
Permission
PtSecurity
DataSecurity
r,w
r,w: the annotation feature

requires write access to the
point being annotated
Module Database
Permission
Notes
Module Security*
r,w: to use the annotation

feature of the FactoryTalk
Historian ProcessBook
Details add-in
Notes

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
Database Security
Permission
PIDS
Notes
83
Database Security
Permission
PIModules
r,w
PIPOINT
Point Database
Permission
PtSecurity
DataSecurity
Module Database
Permission
Module Security*
r,w
Notes
Notes
Notes
84
Historian data Services

Database Security
Permission
Notes
PIBatch
PIDBSEC
PIHeadingSets
PIModules
r,w
PIPOINT
PIUSER
Point Database
Permission
PtSecurity
DataSecurity
r,w
w: for the UserID only if

data writes are performed
by RtPM Business
package
Module Database
Permission
Notes
Module Security*
r,w
r: for FactoryTalk
ProcessID
w: for an administrator
UserID to make
configuration changes
r: for FactoryTalk
ProcessID
w: for an administrator
UserID to make
configuration changes
Notes
85
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.
86
Interfaces
Interfaces that Create Points
Database Security
Permission
Notes
PIPOINT
r,w1
r,w: for any

interface that
creates or deletes
points
Point Database
Permission
Notes
PtSecurity
r,w
DataSecurity
r,w
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.
87
Historian to Historian TCP/IP Interface
88
Database Security
Source
Historian
Server
Receiving
Historian Server
PIPOINT
Point Database
Source
Historian Tags
Receiving
Historian Tags
PtSecurity
DataSecurity
r,w
Notes
Notes
Interfaces
Historian OPC DA/Historian OPC HDA Interfaces

Database Security
Permission
PIPOINT
Point Database
Permission
PtSecurity
DataSecurity
r,w
Notes
Notes
89
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:
90
[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
PIDS
None for readonly 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 nonautomatic
modes
PIModules
r: to review APS
configuration;
r,w: to change
APS
configuration
r,w
PIPOINT
None for readonly mode;

r,w: to
interactively
create or delete
points
r,w: for
automatic
point
creation;
r: for nonautomatic
modes
Point Database
APS
Configuration
Utility
Sync
Engine
PtSecurity
r: to display
existing
interface points;
r,w: to
interactively edit
or delete
interface points
r,w: to
automatical
ly edit or
delete
points;
r: for non
automatic
modes
Module Database
APS
Configuration
Utility
Sync
Engine
Sync Trigger
Module Security*
r: to review APS
configuration
r,w: to change
APS
configuration
r,w
r,w
PItoPI_APS
r,w
Sync
Trigger
PItoPI_APS
DataSecurity
PItoPI_APS

91
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 nonfunctional. 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).
92
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.
93
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.
94
Interfaces
ICU
Database Security
Permission
Notes
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
Point Database
Permission
Notes
PtSecurity
r, w
Module Database
Permission
Module Security*
r,w
Notes
95
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.
96
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.
97
Appendix C
New SMT Highlights

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.
99
Appendix D
Checklist: Configure Windows Authentication for

Upgrades
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
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)
101
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)
Appendix E
Checklist: Configure Windows Authentication for

New Installations
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 (only for installations with existing clients &
later
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
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)
103
Technical Support and Resources

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
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
Outside United States or
Canada
1.440.646.3434
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
Outside 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.
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/.
Copyright 2013 Rockwell Automation, Inc. All rights reserved. Printed in the U.S.A.

Configuring FT Historian SE Security

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuring FT Historian SE Security

Uploaded by

Copyright:

Available Formats

CONFIGURING FACTORYTALK HISTORIAN SE SECURITY

Rockwell Automation Publication HSECHS-UM031A-EN-ESeptember 2013

Customer Support Telephone 1.440.646.3434

Disable Explicit Logins for piadmin ........................................................................ 53

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

Configuring FactoryTalk Historian SE Security

Introduction to Historian Server Security

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)

A Brief Look at Historian Server Security

How the Security Model Has Changed

Configuring FactoryTalk Historian SE Security

Introduction to Historian Server Security

Users connecting to Historian Server through client applications were typically

A Brief Look at Historian Server Security

Configuring FactoryTalk Historian SE Security

Introduction to Historian Server Security

What are PI Identities and PI Mappings?

A Brief Look at Historian Server Security

What about PI Users and PI Groups?

Configuring FactoryTalk Historian SE Security

Introduction to Historian Server Security

Managing Identities and PI Mappings

A Brief Look at Historian Server Security

Built-in PI Identities, Users, and Groups

piadmin A PI user with super-user access

piadmins A PI group with administrative access

PIWorld A PI identity with general access

A PI group intended to represent Historian Server administrators. You can

Sample identities that have no preconfigured access permissions. These

Configuring FactoryTalk Historian SE Security

Introduction to Historian Server Security

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

A PI identity with default access permissions for read-only access to most

The piadmin User

Why Use Windows Integrated Security?

All database security entries (in SMT)

All existing points and modules.

The PIWorld Identity

Why Use Windows Integrated Security?

Configuring FactoryTalk Historian SE Security

Introduction to Historian Server Security

Configuring Security on a New Historian Server

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

Configuring FactoryTalk Historian SE Security

Configuring Security on a New Historian Server Installation

About the Configuration

piadmins: piadmins is a built-in PI group that is preconfigured with read-write access to

Improve the Quick-Start Configuration

The following examples demonstrate how to implement each of these suggested

Configuring FactoryTalk Historian SE Security

Configuring Security on a New Historian Server Installation

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

Who needs to use the Historian Server?

What Historian Server resources do they need to access?

Two category model: operators/admins

Three category model: operators/admins/ITadmins

Configuring FactoryTalk Historian SE Security