PI Data Archive 2018 SP3 Security Configuration Guide EN

PI Data Archive
Security Configuration Guide
Included with PI Server 2018 SP3

OSIsoft, LLC
1600 Alvarado Street
San Leandro, CA 94577 USA
Tel: (01) 510-297-5800
Fax: (01) 510-357-8136
Web: http://www.osisoft.com
PI Data Archive Security Configuration Guide

© 2009-2019 by OSIsoft, LLC. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or
by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission
of OSIsoft, LLC.
OSIsoft, the OSIsoft logo and logotype, Managed PI, OSIsoft Advanced Services, OSIsoft Cloud Services,
OSIsoft Connected Services, PI ACE, PI Advanced Computing Engine, PI AF SDK, PI API,
PI Asset Framework, PI Audit Viewer, PI Builder, PI Cloud Connect, PI Connectors, PI Data Archive,
PI DataLink, PI DataLink Server, PI Developers Club, PI Integrator for Business Analytics, PI Interfaces,
PI JDBC Driver, PI Manual Logger, PI Notifications, PI ODBC Driver, PI OLEDB Enterprise,
PI OLEDB Provider, PI OPC DA Server, PI OPC HDA Server, PI ProcessBook, PI SDK, PI Server, PI Square,
PI System, PI System Access, PI Vision, PI Visualization Suite, PI Web API, PI WebParts, PI Web Services,
RLINK, and RtReports are all trademarks of OSIsoft, LLC. All other trademarks or trade names used herein
are the property of their respective owners.
U.S. GOVERNMENT RIGHTS
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC
license agreement and as provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12-212, FAR
52.227-19, or their successors, as applicable. OSIsoft, LLC.
Version: 3.4.430
Published: 23 August 2019
Contents
Security configuration................................................................................................ 1
Introduction to PI Data Archive security...................................................................... 3

A brief look at PI Data Archive security............................................................................................................ 3
How the security model has changed...........................................................................................................3
What are PI identities and mappings?..........................................................................................................6
Why use Windows Integrated Security?......................................................................................................... 11
Configuring security on a new PI Data Archive installation...........................................13

Quick-start configuration............................................................................................................................... 13
About the configuration.............................................................................................................................14
Implement the quick-start security configuration.......................................................................................14
Improve the quick-start configuration........................................................................................................ 15
Recommended configuration........................................................................................................................ 16
Configure authentication........................................................................................................................... 17
Configure access permissions.....................................................................................................................23
Other security configurations........................................................................................................................ 27
Use local Windows security....................................................................................................................... 28
Use local Windows security with AD...........................................................................................................31
Use PI users and PI groups..........................................................................................................................31
PI interface connections through PI API..................................................................... 35

PI API 2016 for Windows Integrated Security................................................................................................. 35
Configure PI interface connections using PI mappings................................................................................37
Installing and upgrading PI API 2016 for Windows Integrated Security...................................................... 44
Uninstalling PI API 2016 for Windows Integrated Security......................................................................... 45
Configure PI interface connections using PI trusts......................................................................................... 45
About PI trusts...........................................................................................................................................46
Create a trust.............................................................................................................................................46
Configuring security for PI Data Archive upgrades.......................................................51

What is in the new security model?................................................................................................................ 51
Why a new security model?........................................................................................................................... 52
Your upgrade options.................................................................................................................................... 52
Quick-start security migration....................................................................................................................53
Migrate over time...................................................................................................................................... 54
Set up a new security configuration........................................................................................................... 61
Keep existing configuration....................................................................................................................... 61
Security for PI Data Archive collectives...................................................................... 63

Overview of security in PI Data Archive collectives........................................................................................ 63
Mapping unresolved users............................................................................................................................. 63
Enable the lookup-failure tuning parameter.................................................................................................. 64
Creation of mappings with a Windows Security ID (SID)................................................................................ 65
Tightening security.................................................................................................. 67
Upgrade PI API.............................................................................................................................................. 67
PI Data Archive Security Configuration Guide iii

Contents
Retire PI trusts............................................................................................................................................... 67
Protect piadmin in PI SMT............................................................................................................................. 68
Disable explicit logins for piadmin............................................................................................................. 68
Disable PI password authentication (explicit logins)...................................................................................... 69
Disable all explicit logins............................................................................................................................69
Disable explicit logins with blank passwords.............................................................................................. 70
Disable explicit logins for individual user accounts..................................................................................... 70
Retire SDK trusts........................................................................................................................................... 71
Windows authentication versus SDK trusts................................................................................................ 71
Configure SDK authentication protocols in SMT........................................................................................ 71
Disable SDK trusts..................................................................................................................................... 72
Configure PI Firewall...................................................................................................................................... 73
Disable PIWorld............................................................................................................................................. 73
How will PI Server 3.4.380 affect my clients and interfaces?......................................... 75

Products that connect through a trust............................................................................................................75
Check for unauthenticated PI API connections...........................................................................................76
Products that connect to an application server.............................................................................................. 76
Administrative client applications.................................................................................................................. 77
Which administrative tools are compatible with PI Data Archive................................................................ 77
How to maintain backwards-compatible access permissions......................................................................77
How will PI API 2016 for Windows Integrated Security affect clients and interfaces?......79
MDB to AF security synchronization considerations....................................................81
Permissions required for tasks...................................................................................83
Product access permissions reference and configuration issues....................................87

AF 2.x Client.................................................................................................................................................. 87
AF 1.3 Server..................................................................................................................................................87
AF 1.3 Client.................................................................................................................................................. 88
DataSheet Control........................................................................................................................................ 88
PI groups and DataSheet Control...............................................................................................................88
PI ACE........................................................................................................................................................... 89
PI BatchView................................................................................................................................................. 90
Security configuration for PI BatchView.................................................................................................... 90
PI DataLink....................................................................................................................................................91
PI DataLink Server (PI DLES)......................................................................................................................... 92
Security configuration for PI DLS...............................................................................................................92
PI Manual Logger.......................................................................................................................................... 92
Configuring security for PI Manual Logger................................................................................................. 93
PI Notifications.............................................................................................................................................. 93
Developer Technologies................................................................................................................................ 94
PI OLEDB Provider.................................................................................................................................... 94
Configuring security for PI OPC DA Server.................................................................................................94
Configuring security for PI OPC HDA Server.............................................................................................. 95
PI ProcessBook............................................................................................................................................. 96
RtAlerts.........................................................................................................................................................96
RtReports Server (to PI Data Archive)............................................................................................................ 97
RtReports Editor (to PI Data Archive).............................................................................................................97
Configuring security for RtReports.............................................................................................................98
iv PI Data Archive Security Configuration Guide

Contents
PI WebParts and PI Web Services.................................................................................................................. 98

Configuring security for PI WebParts and PI Web Services ........................................................................ 99
Interfaces.................................................................................................................................................... 100
Interfaces that create points.................................................................................................................... 100
PI to PI TCP/IP Interface........................................................................................................................... 100
PI Interface for OPC DA........................................................................................................................... 100
PI Interface for OPC HDA......................................................................................................................... 101
PI APS...................................................................................................................................................... 101
PI ICU.......................................................................................................................................................104
Checklist: Configure Windows authentication for upgrades....................................... 107
Checklist: Configure Windows authentication for new installations............................ 109
Technical support and other resources..................................................................... 111
PI Data Archive Security Configuration Guide v

Contents
vi PI Data Archive Security Configuration Guide

Security configuration
This documentation explains how to set up Windows Integrated Security on PI Data Archive
servers, how and when to create PI Mappings and trusts, and how to improve PI Data Archive
security. It discusses built-in PI Data Archive Identities, such as piadmin, piadmins, and
PIWorld. It provides a table of access permissions required for performing different PI Data
Archive tasks, as well as access permissions required by specific PI products.
PI Data Archive Security Configuration Guide 1

Security configuration
2 PI Data Archive Security Configuration Guide

Introduction to PI Data Archive security
PI Server 3.4.380 introduced Windows integrated security for the PI Data Archive server,
allowing you to manage PI Data Archive authentication through Windows and Microsoft Active
Directory (AD). This new security model improves PI Data Archive security, reduces your
management workload, and provides users a single-sign on experience.
Note:
The PI Data Archive server continues to support previous PI Data Archive 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. However, although the
password mechanism performs as designed, weakness exists due to the use of a
proprietary cypher developed in the 1990s that has not been modified to keep up with
modern cryptographic advances. In short, the explicit login as an authentication method
is not secure from malicious actors. In addition, similar to explicit login authentication, PI
trust authentication is a weak form of authentication and should be avoided unless
technically required for application compatibility.
Topics in this section

• A brief look at PI Data Archive security
• Why use Windows Integrated Security?
A brief look at PI Data Archive 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 PI 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
• What are PI identities and mappings?
How the security model has changed

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

• Authentication
• Authorization

Authentication
Before the PI Server 3.4.380 release, two methods of authentication were available: PI trusts
and PI password authentication (also called explicit logins). Starting with PI Server 3.4.380, a
third, and the most secure method of authentication becomes available: Windows
authentication.
The three models for authentication on a PI Data Archive are:
• Windows authentication
Windows authentication allows users to log onto their Windows accounts and automatically
become authenticated on the PI Data Archive server. Rather than requiring individual user
accounts on the PI Data Archive server, in the new model you define user categories, called
PI identities, on the PI Data Archive server. You then create mappings from groups of
Windows users to the relevant user categories. PI identities and PI mappings are new objects
in PI Server 3.4.380.
This authentication model provides single sign-on for PI users, requires less maintenance
for PI administrators, and significantly increases security over the previous model. Both PI
trusts and explicit logins remain as authentication mechanisms on the PI Data Archive
server. However, the use of PI trusts and explicit logins progressively disabled except for
backward compatibility with clients lacking support for Windows authentication. For
example, a deployment scenario where an Interface node is located on a control system
network which doesn't support Windows authentication.
Starting with the with the release of PI API 2016 for Windows Integrated Security, support
for Windows authentication is extended to all PI API-based client applications, such as PI
interfaces. Before this release, Windows authentication was not available for PI interfaces,
even though PI Data Archive supported it as an authentication model for its users. With PI
API 2016 for Windows Integrated Security and PI Server 3.4.380 or later, Windows
authentication extends across the PI system to the PI interface node or any other PI API-
based application connecting to PI Server 3.4.380 or later, in the following deployment
scenarios:
◦ Interface node and PI Data Archive on the same computer

◦ Interface node and PI Data Archive on the same domain
◦ Interface node and PI Data Archive on different but trusted domains

◦ Interface node and PI Data Archive on untrusted domains

◦ Interface node or PI Data Archive or both in a workgroup
OSIsoft recommends upgrading your authentication model to Windows authentication from
PI trusts or explicit logins for interfaces and other PI API-based client applications for PI
Data Archive to take advantage of the most secure communication method available.
• PI trusts
Prior to the availability for Windows authentication on PI API enabled by the release of PI
API 2016 for Windows Integrated Security, PI trusts were typically used to authenticate PI
API-based client applications that ran unattended, such as PI interfaces. 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.
PI trust authentication is a weak form of authentication due to potential for fake credentials.
Windows authentication offers more defenses and is the recommended approach for
assuring PI Data Archive connections are legitimate.
PI trusts are still available as a method for authenticating PI interfaces, or any other PI API-
based client application. However, the use of PI trusts for interfaces should be reserved to
cases where Windows authentication cannot be used.
Caution:
PI API 2016 for Windows Integrated Security does not support PI trusts or explicit
logins. Before upgrade, PI Mappings to a Windows logon or service account must be
configured on the PI Data Archive to avoid any potential data loss.
• Explicit logins

Users connecting to PI Data Archive through client applications were typically authenticated
through explicit logins, which means that the user logs on to PI Data Archive 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 PI Data Archive; they require system managers to
maintain separate user accounts for every user on PI Data Archive; and they are not
especially secure.
Although the password mechanism performs as designed, public vulnerability disclosure
CVE-2009-0209 is a weakness due to the use of a proprietary cypher developed in the
1990s that has been deprecated in favor of industry standard cryptography and password
management policy enforcement by the Windows operating system. In short, explicit login
as an authentication method is not secure from malicious actors.
Authorization
The new security model includes a much more flexible model for access permissions. In
previous versions of the PI Data Archive server you could set permissions only for one owner,
one user group, and for world access (everyone else). With the new security model, each PI
Data Archive object can have read and/or write permissions defined for any number of PI
identities.
What are PI identities and mappings?

PI identities and PI mappings are the central components of the security model for PI Data
Archive. They determine which Windows users are authenticated on the PI Data Archive 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 PI Data Archive 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 PI Data Archive 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 PI Data Archive 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 PI Data Archive server keeps track of the
specific Windows user ID both in the audit trail and in the last change information.
Note:
Although the PI Data Archive server can use Windows security for authentication, you
still need to define access permissions explicitly on the PI Data Archive server. See
Configure access permissions.

• What about PI users and PI groups?
• Managing identities and PI mappings
• Built-in PI identities, users, and groups
What about PI users and PI groups?

Previous versions of the PI Data Archive 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 PI Data Archive 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 PI Data Archive
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 PI Data Archive servers
upgraded to version 3.4.380 to keep their existing security configurations. It also provides an
alternate authentication mechanism if Windows authentication is not a viable option for you.
However, although the password mechanism performs as designed, weakness exists due to the
use of a proprietary cypher developed in the 1990s that has not been modified to keep up with
modern cryptographic advances. In short, the explicit login as an authentication method is not
secure from malicious actors. In addition, similar to explicit login authentication, PI trust

authentication is a weak form of authentication and should be avoided unless technically

required for application compatibility. OSIsoft recommends upgrading security around PI Data
Archive to Windows Integrated Security.
On PI Server 3.4.380 and later, PI groups and PI users are implemented as special types of PI
identities. The Users and Groups tool in PI 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 PI Data Archive server.
Managing identities and PI mappings

PI System Management Tools (SMT) provides tools for configuring and managing PI identities
and PI mappings, as well as for other security components. Every PI Data Archive installation
includes PI SMT.
To manage PI identities, use the Identities, Users, & Groups tool in PI 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 PI Server 3.4.380 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 PI 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 PI Data
Archive server through a mapping.

To manage PI mappings in PI SMT, use the Mappings & Trusts tool. Click the Mappings tab to
see all the PI mappings defined for all connected PI Data Archive.
Note:
The Mappings tab appears only if you are connected to at least one PI Server 3.4.380 or
later. If not, then only the Trusts tab appears.
Built-in PI identities, users, and groups

PI Data Archive includes several built-in PI identities, users, and groups. The most important
are:
• piadmin — A PI user with super-user access
Note:
To maintain a secure environment, OSIsoft does not recommend use of piadmin.
• piadmins — A PI group with administrative access
• PIWorld — A PI identity with general access
PI users, groups, and Description
identities
piadmin user A PI user with super privileges. The piadmin user has complete read/
write access to all PI Data Archive resources. You cannot modify the
access permissions for piadmin. In most cases, do not map piadmin to
any AD group or user. At most, map piadmin to a small group of
administrators. Though you cannot delete the piadmin user, you can
disable it to varying degrees.
piadmins group A PI group intended to represent PI Data Archive administrators. Use
piadmins for all routine administrative tasks.
This pre-configured group has read and write access to all PI Data
Archive resources and default points.
You can map piadmins to the AD group that represents your PI Data
Archive system administrators and you can adjust the piadmins access
permissions to meet your needs. You cannot delete the piadmins group.
piusers group A built-in PI group with no pre-configured access permissions.

PI users, groups, and Description

identities
PIOperators, PIEngineers, Sample identities that have no pre-configured access permissions. You
and PISupervisors identities can configure or delete these PI identities.
PIWorld identity 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 PI Data
Archive databases and objects. All authenticated PI Data Archive users
are given at least PIWorld privileges.
You can rename and change the access permissions of the PIWorld
identity. You cannot delete PIWorld. You cannot map PIWorld to an AD
group or use PIWorld in a trust.
Note:
There is also a hidden user and a hidden group: PIUserIncompatible and
PIGroupIncompatible. PI Data Archive 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.
The piadmin user

The piadmin user is the built-in PI Data Archive super-user account. As piadmin you have
complete access to all objects and operations on the PI Data Archive server, regardless of the
security specification. You cannot delete or disable this powerful account.
Previous versions of the PI Data Archive 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.4.380 and later, the PI Server 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.
You should take further steps to protect the piadmin account, if possible. See Protect piadmin
in PI SMT.
The piadmins group

The piadmins group is a built-in PI group intended to represent PI Data Archive administrators.
OSIsoft recommends that you use piadmins, rather than the super-user account (piadmin) for
common administrative tasks.
On new installations of PI Data Archive 3.4.380 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 PI Data Archive server did not grant piadmins administrative access by
default and upgrade installations do not change the access permissions for piadmins. On
upgraded PI Data Archive servers the piadmins group has whatever access you granted it. You

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 PI SMT)

• All existing points and modules.
See How to configure access permissions for more information. You can then map piadmins to
the Windows users and/or groups that represent your PI Data Archive system administrators.
Note:
The piadmins PI group was called piadmin on previous versions of the PI Data Archive
server. This meant that PI Data Archive 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 PI
Server 3.4.380 release, in order to prevent conflict with the piadmin user account.
The PIWorld identity

PI Data Archive 3.4.380 introduces a special built-in PI identity, called PIWorld. The PIWorld
identity represents the Everyone concept of Windows; it specifies the rights of non-explicit
users or groups. All authenticated PI Data Archive 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.
The PIWorld identity replaces the world access of earlier versions of the PI Data Archive server;
world access was always granted to all authenticated users, but there was no explicit world
user account. On PI Server 3.4.380 and later, the previously implied world access is now made
explicit with the PIWorld identity.
By default, PIWorld is granted read access to most PI Data Archive 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 PI Data Archive administrators

You no longer need to create and manage individual user accounts on the PI Data Archive
server. When a user enters, leaves, or changes roles, you only need to modify the Windows
configuration. PI Data Archive security automatically reflects these changes. You also get
complete traceability of the specific Windows account in the PI Data Archive log and audit
trail records.

• Single-sign on for users

Users need only log on to their Windows account. PI clients will automatically authenticate
through the PI SDK. No additional PI Data Archive 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 PI Data Archive 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 PI Data Archive 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 PI Data Archive server you could set permissions only for one
owner, one user group, and for world access (everyone else). With the new security model,
each PI Data Archive resource can have read and/or write permissions defined for any
number of PI identities.

Configuring security on a new PI Data Archive
installation
This section discusses how to configure security for new PI Data Archive installations. If you
implement one of these configurations now, you are free to make changes at any time.
• Option 1:
Quick-start configuration 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 explains how to create and implement a custom PI Data
Archive security configuration that uses Microsoft Active Directory (AD) for authentication
(but not for PI access permissions; these are still defined directly on the PI Data Archive
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 PI Data Archive 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 to determine your options.
For instructions on upgrades, see Configuring security for PI Data Archive upgrades.

• Quick-start configuration
• Recommended configuration
• Other security configurations
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
• Implement the quick-start security configuration
• Improve the quick-start configuration

Configuring security on a new PI Data Archive installation
About the configuration

In this configuration you assign two levels of access permissions that apply to all PI Data
Archive 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 PI Data Archive access. On the PI Data
Archive 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 PI Data
Archive 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 PI Data Archive upgrades.
• PIWorld:
PIWorld is a built-in PI identity that is preconfigured with read access to most PI Data
Archive resources. You cannot use PIWorld directly in a mapping. However all authenticated
users on the PI Data Archive 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 for more on
PIWorld.
Note:
This configuration relies on PIWorld access. It does not work if you disable PIWorld.
Implement the quick-start security configuration

In this very simple model, users either get read-only access to everything on the PI Data
Archive server or they get read/write access to everything on the PI Data Archive 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 PI Data Archive access. (For AD configuration, your
company's IT department is probably your best resource.)
Procedure
1. Identify which AD group or groups will have administrator (read/write) privileges on the PI
Data Archive server. Identify which groups will have read-only access.
2. Map the AD group that represents PI 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 PI Data Archive 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.
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.
After you finish

Configure PI interfaces. See Configure PI interface connections using PI trusts.
Improve the quick-start configuration

If you plan to base your long-term security configuration on the quick-start configuration, then
consider these suggested improvements:
• To make the quick-start security configuration more flexible, you can add PI identities to
represent different user categories. For example, you might want to grant IT administrators
permission to perform backups. To do that, you create a PI identity and give it the necessary
access permissions. Then create a mapping between AD group for the IT administrators and
that PI identity.
• To make the quick-start security configuration more secure, you can explicitly set the access
permissions for the piusers group, rather than relying on the PIWorld access permissions. In
the quick-start configuration we relied on PIWorld in order to make the configuration
process quicker and easier. However, it is a better practice to use explicitly-configured
access permissions. If you rely on PIWorld, it becomes difficult over time to determine
which users or applications are relying on that access.
The following examples demonstrate how to implement each of these suggested
improvements.
Example 1. Configure Administrative Access Categories

This example demonstrates how to explicitly configure administrative access to run backups.
1. First create a PI identity called ITAdmins (Create a PI identity).
2. Start PI SMT and connect to the PI Data Archive server as piadmins (for new installations
only; for upgrades, connect as piadmin).
3. Open the Database Security tool (select Security > Database Security).
4. In the Database Security tool, give the ITAdmins identity read-write access to the PIBACKUP
entry.
Example 2. Configure Access Permissions for piusers

Start PI SMT and connect to the PI Data Archive 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.
2. Set permissions for built-in points. The PI Data Archive 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 (for a small number of
points) or PI Builder (for many points). See Set permissions on specific points and modules.
3. Set permissions for existing modules. At a minimum, the PI Data Archive 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 PI 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 Default access for new points and
modules 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.
Procedure
1. Configure user authentication.
In most cases this simply means creating a PI identity for each AD group that requires PI
access and creating a mapping between them.
a. Identify user access categories.

Identify the users who need access to the PI Data Archive 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 PI Data Archive backups? See
Identify user access categories.
b. Create PI identities.
On the PI Data Archive server, create PI identities for each user category. See Create a PI
identity.
c. Review Active Directory groups.
In Windows, identify Active Directory groups that represent your PI Data Archive 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.
d. 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.
2. Configure access permissions.

Give your PI identities access to the necessary PI Data Archive resources. The access
permissions specify what tasks each PI identity is allowed to perform on the PI Data Archive
server. See Configure access permissions.
3. Configure PI Interface (and PI Client) access to the PI Data Archive server.
a. Configure access for PI interfaces.
Similar to configuring user authentication earlier in Step 1, you need to set up PI
mapping between the Windows AD group or users and PI identity on interfaces that will
connect to the PI Data Archive server. This process involves identifying the Windows AD
users or group for that PI interface, identifying a PI identity for that interface, and
mapping the users or group to the PI identity to grant the required access permissions
for that interface. See Configure PI interface connections using PI trusts for instructions
on creating PI mappings for interfaces.
b. Configure access for client applications (optional).
Client applications typically connect to the PI Data Archive server using PI SDK. You need
SDK 1.3.6 or later to use Windows authentication. You need PI SDK 2016 or later to
utilize transport security. Certain PI client applications require a connection to a separate
application server in addition to a PI Data Archive server (for example, PI DataLink for
Excel Services (DLES) and PI WebParts). These types of applications require additional
configuration steps. See How will PI Server 3.4.380 affect my clients and interfaces? for
more information.
After you finish

There are a number of things you can do to provide extra security for your PI Data Archive. See
Tightening security for suggestions and instructions.

• Configure authentication
• Configure access permissions
Configure authentication
This section discusses the recommended approach to configuring your PI Data Archive
authentication.
Note:
If you already know which AD group or groups will have PI Data Archive 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 PI Data Archive authentication, follow these steps.
Procedure
1. Identify user access categories.
2. Create PI identities.
3. Review AD configuration.
4. Map AD groups to PI identities.

Identify user access categories

The first step in the security configuration is to determine:
• Who needs to use the PI Data Archive server?

• What PI Data Archive 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 PI installations start from one
of the following basic models:
• Two-category model: operators/admins

PI Data Archive users are divided into two categories, which we refer to here as operators
and administrators. The operator category gets read-only access to all PI Data Archive
resources. The administrator category gets read/write access to all PI Data Archive
resources.
• Three-category model: operators/admins/ITadmins

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 PI Data Archive 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 PI Data Archive installation.
Most of these are sample identities, not configured with access permissions. However the
piadmins group is preconfigured with read/write access to all PI Data Archive 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.
• 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.
• 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 PI Data Archive resources. You can adjust these access permissions as needed.
• IT Administrators:
Create a PI identity called ITAdmins. You will need to set the access permissions manually.
Creating PI identities is just the first step. You also need to:
• Map each AD group to the appropriate PI identity (Map AD groups to PI identities).

• Configure access permissions for each PI identity (Configure access permissions).
Create a PI identity
When you create a new identity, the identity name is required. 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.
Procedure
1. Under the Servers panel (or if you have a collective deployment, 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 field is required. 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 Servers (or if you have a collective
deployment, Collectives and Servers). Only PI Server versions 3.4.380 and later appear in the
list.

7. Optional: Enter a brief description in Description.

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 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 PI Data Archive server can use AD for authentication, it does not use
Windows access permissions to determine PI Data Archive access levels. You still have to
set access permissions explicitly on the PI Data Archive server.
Follow these guidelines:
• Make sure you have appropriate AD groups for each type of PI Data Archive 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.
• Review your AD group memberships to ensure that all Windows users will get the
appropriate PI Data Archive permissions (PI Data Archive access permissions and AD).
• 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
PI Data Archive 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
PI Data Archive server and then place existing AD groups within the local groups.
PI Data Archive access permissions and AD

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

Look at the access needs for all your Windows users. Which AD groups does the user belong
to? Which PI identities do those groups map to? Users that belong to more than one AD group
get the cumulative access permissions for all the associated PI identities. For example, in the
following illustration, the Windows user, Bob, belongs to both AD groups. Bob therefore gets
the permissions configured for PI Identity1 and the permissions for PI Identity2.
Similarly, users get the cumulative access permissions for all parent AD groups (for nested AD
groups). For example, in the following illustration, Windows user, Bob, belongs to ADGroup2.
Since ADGroup2 is nested inside ADGroup1, the users in ADGroup2 get all the access
permissions of ADGroup1, as well as those of ADGroup2.

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 PI Data
Archive 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 PI Data Archive server will automatically authenticate members of
that AD group as the specified PI identity.
Procedure
1. Open PI SMT.
2. Under Collectives and Servers, select the server. Note that if you have a collective
deployment, this PI SMT panel will appear as Collectives and Servers.
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 PI 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.

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

9. Enter the Windows account.
This can be an AD principal or a local Windows group or user. To select the account either:
◦ Click the browse button to browse for the account.
◦ Type in the account name. If you choose to type in the account name, click the resolve SID
button to verify that this is a valid account. If the account is valid, an SID appears in
the field. Otherwise, a dialog box with an error message opens.
See Specifying AD users and groups for more information.
Specifying AD users and groups

To explicitly specify an AD principal, you can use any of the following:
• Fully-qualified account name: domain_name\principal_name

• Fully-qualified DNS name: my_domain.com\principal_name
• User Principal Name (UPN): principal_name@my_domain.com
• SID: S-1-5-21-nnnnnnnnnn-…-nnnn
Note:
For local Windows users or groups, you can use only the fully-qualified account name
(computer_name\principal_name) or SID formats.
To find the security identifier (SID) or to check the validity of a domain principal, you can use
the psgetsid utility. This utility is part of a set of command-line tools called PsTools, that are
available on the Microsoft TechNet Web site. If you run the utility from the PI Data Archive
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 PI Data Archive 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 PI
Data Archive server.


• About access permissions on the PI Data Archive server
• How to configure access permissions
About access permissions on the PI Data Archive server

The PI Data Archive 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.
The PI Data Archive server stores the settings for each object in an access control list (ACL).
Each secure object on the PI Data Archive 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 PI Data Archive server does not allow you to explicitly deny access
privileges.
Access permissions: Default configuration

The PI Data Archive 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 PI Data Archive
resources. On PI Data Archive 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 PI
Data Archive resources, regardless of security settings.
The PI Data Archive server also includes the PI Operators, PI Engineers, and PI 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 PI Data Archive installations are as
follows:
• Set default access permissions for new points and modules. After you do this, all new points
and modules that you create will automatically have these default settings. See Default
access for new points and modules.
• Set top-level access permissions in the PI 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.
• Configure access permissions for individual points and modules by editing the points
themselves. The PI Data Archive installation includes tools for doing this. See Set
permissions on specific points and modules.

• Default access for new points and modules
• Set permissions in the Database Security tool
• Set permissions on specific points and modules
• Access control for basic PI Data Archive admin tasks
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 using the Database Security plug-in for PI SMT.
• 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 plug-in for PI SMT controls access to most PI Data Archive resources.
The exception is that permissions for specific points and modules are configured on the objects
themselves.
For a complete list of PI Data Archive tasks and associated access permissions, see Permissions
required for tasks.
Procedure
1. Open PI SMT.
2. Under Collectives and Servers, select the server. Note that if you have a collective
deployment, this PI SMT panel will appear as Collectives and Servers.
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).
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.
Set permissions on specific points and modules

You configure access permissions for individual points and modules by editing the object itself.
The PI Data Archive installation includes tools for editing these objects. You can access all of
these tools from the PI System Management Tools (SMT). You can locate some under System
Management Tools and you can locate the others from the Tools menu.
To Control Access on: Use:
Point Point Builder (PI SMT tool) or PI Builder
(Microsoft Excel add-in)
Module Module Database tool (PI SMT tool) or Module
Database Builder (access from the PI SMT Tools
menu)
PIUnit Module Database tool (PI SMT tool) or Module
Database Builder (access from the PI SMT Tools
menu)
Administrative tasks Database Security tool (PI SMT tool)
For information about what access privileges are necessary for specific tasks, see Review
access permissions.
Access control for basic PI Data Archive admin tasks

The following table lists basic PI Data Archive administration tasks and which tables in the
Database Security tool control access to each task.

Administration task Table that controls the task

Managing archives PIARCADMIN (basic archive administration tasks:
archive creation, registration, shifts, and online
reprocessing) and PIARCDATA (archive data that is
not tag-specific, such as listing the archives;
archive troubleshooting 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 PI Data Archive collectives PIReplication and PIBACKUP
Other security configurations

If you do not have access to AD or if your access is limited in some way, then you have the
following options for configuring authentication:
• Use Local Windows Security: You can use local Windows security for authentication, rather
than AD. There are two disadvantages to this:
◦ Local Windows security uses NTLM for authentication, which is not as secure as
Kerberos (AD uses Kerberos).
◦ Extra configuration is required. The Windows user accounts on the PI Data Archive 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 PI trusts or PI user accounts. See Use local Windows security.
• 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.
• Use Windows Credential Manager: Consider using this option for scenarios where one
machine is in one domain and the other machine is in another domain. You can still use a
combination of local account and AD for this scenario. See Windows Credential Manager.
• Use PI Password Authentication: If you cannot use local Windows security or AD for
authentication, only two authentication methods are available: PI Data Archive user
accounts/passwords and PI 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 PI groups.

Note:
Increasing number of OSIsoft client applications require Windows authentication and
PI mappings, and are not viable with PI password authentication.

• Use local Windows security
• Use local Windows security with AD
• Use PI users and PI groups
Use local Windows security

You can use local Windows security to grant access to the PI Data Archive 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 PI Data Archive server and all
client machines.
Note:
Identical user accounts and passwords is a form of credential reuse. Verify identical
accounts are consistent with your IT policies.
When a password changes or a user is added or deleted, you must make that change on the PI
Data Archive server and all participating client machines (this is actually a Windows
requirement).
Note:
If the PI Data Archive server is part of a PI Data Archive collective, please refer to Security
for PI Data Archive collectives before using local Windows groups.
Alternatively, use Windows credential manager as the safest way to configure local
Windows security.
Procedure
Identify the users who need access to the PI Data Archive 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 PI Data Archive backups? See Identify
user access categories.
2. Create PI identities.
On the PI Data Archive server, create PI identities for people with similar access needs. See
Create a PI identity.
3. Configure local Windows groups.
In Windows, identify the Windows groups that represent your PI Data Archive roles. See
Configure Windows groups.
4. Map Windows groups to identities.
See Create mappings.
5. Grant PI access permissions.

Give your PI identities access to the necessary PI Data Archive resources. The access
permissions specify what tasks each PI identity is allowed to do on the PI Data Archive
server. See Configure access permissions.
6. Configure access for client applications.
Client applications typically connect to the PI Data Archive using PI SDK. You need SDK 1.3.6
or later to use Windows authentication. You need PI SDK 2016 or later to utilize transport
security. Certain PI client applications require a connection to a separate application server
in addition to a PI Data Archive server (for example, PI DLES and PI WebParts). These types
of applications require additional configuration steps. See How will PI Server 3.4.380 affect
my clients and interfaces? for more information.
7. Configure access for interfaces.
You need to set up a mapping for the interfaces that will connect to the PI Data Archive
server. Each mapping is based on a PI identity. See Configure PI interface connections using
PI trusts.
After you finish

There are a number of things you can do to provide extra security for your PI Data Archive
server. See Tightening security for suggestions and instructions.

• Configure Windows groups
• Create mappings
Configure Windows groups

Use Windows groups for PI Data Archive authentication.
Procedure
1. Configure user accounts on client and server workstations.
To use Windows users and groups, the Windows user accounts on the PI Data Archive
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 PI
Data Archive permissions.
(See Managing user access permissions with Windows groups).

Managing user access permissions with Windows groups

The access permissions for each Windows user are determined by the PI identities that user is
associated with. Each Windows group is mapped to a PI identity. Windows users that belong to
that Windows group get the access permissions for that PI identity.
Windows users that belong to more than one Windows group get the cumulative access
permissions for all the associated PI identities. For example, in the following illustration, the
Windows user, Bob, belongs to both Windows groups. Bob, therefore, gets the permissions
configured for PI Identity1 and PI Identity2.
Look at the access needs for all your Windows users. Which Windows groups do the users
belong to? Which PI identities do those Windows groups map to? Make sure that each
Windows user belongs to the appropriate Windows groups.
Create mappings
Once you have the necessary PI identities and Windows groups, you need to map each
Windows group to a PI identity. The mapping associates the specified PI identity with the
specified Windows group. Members of that Windows group will be authenticated automatically
on the PI Data Archive server as the specified PI identity.
Procedure
1. Open PI SMT.
2. Under Collectives and Servers, select the server.
If you do not see the PI Identities tab, verify that you are connected to a PI Server 3.4.380 or
later. This tab does not appear in PI SMT with earlier versions of the PI Data Archive 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 PI trusts for this PI identity.

7. Click the Add button under the mappings portion of the dialog box to open the Add New
Mapping dialog box.
There is also an Add button under the trusts portion, so be sure to click the right button.
Note:
The Add button is disabled if the selected PI identity is flagged as disabled or not
usable in a mapping.
8. In Windows Account, enter the Windows group.

To select the account either:
9. Enter a description of the mapping (optional).
There are no restrictions on the contents of this field.
10. Click OK.
The new mapping appears under Mappings.
Use local Windows security with AD

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

If Windows authentication is not a viable option for you, you can use PI password
authentication (explicit logins) to authenticate your users. With this method of authentication,
you create user accounts on the PI Data Archive 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 PI password authentication is not as secure as using Windows authentication or PI
trusts.
Note:
Increasing number of OSIsoft client applications require Windows authentication and PI
mappings, and are not viable with PI password authentication.
Configure PI password authentication on the PI Data Archive server.
Procedure

Identify the users who need access to the PI Data Archive 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 PI Data Archive backups? See Identify user
access categories.
2. Create PI groups:
On the PI Data Archive server, create a PI group for each user category. See Create a new PI
group.
3. Grant PI access permissions.
Give each PI groups access to the necessary PI Data Archive resources. The access
permissions specify what tasks each PI group can do on the PI Data Archive server. See
Configure access permissions.
4. Create PI Data Archive user accounts.
Each user who needs access to the PI Data Archive server should have an associated
account. See Create a new PI user. If you allow multiple users to share a single PI Data
Archive account, then you will not have any way to know who made what changes on the PI
Data Archive server.
5. Configure group memberships.
Add each PI user to the appropriate PI group or groups.
6. Configure access for interfaces.
Set up mappings for the interfaces that will connect to the PI Data Archive server. Each
mapping is based on a PI user, a PI group, or a PI identity. See Configure PI interface
connections using PI trusts.
7. Upgrade administrative client applications.
If you have existing client computers that will connect to this PI Data Archive server,
upgrade any applications that configure access permissions (Administrative client
applications).

• Create a new PI user
• Create a new PI group
Create a new PI user

Note the following restrictions on user group names:
• Names must be unique. They cannot match the name of an existing PI user, PI group, or PI
identity.
• Names cannot include the vertical pipe (|) character or the colon (:) character.
• Names cannot be a positive integer, although they can contain numbers. For example, the
• Names are not case sensitive.
You can change a PI user or group name any time after creation.

Procedure
1. Under Collectives and Servers, select the server or collective.
2. In the System Management Tools pane, select Security > Identities, Users, & Groups.
3. Click 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.
6. Select the appropriate server from the drop-down Server list. This list shows the servers
selected under Collectives and Servers.
7. Optionally, enter a brief description in Description. There are no restrictions on the contents
of this field.
8. In Password, enter a password for the PI user.
9. Click Create. The new PI user now appears in the PI Users tab.
Create a new PI group

Note the following restrictions on user group names:
• Names must be unique. They cannot match the name of an existing PI user, PI group, or PI
identity.
• Names cannot include the vertical pipe (|) character or the colon (:) character.
• Names cannot be a positive integer, although they can contain numbers. For example, the
• Names are not case sensitive.
You can change a PI group name any time after creation.
Procedure
1. Under Collectives and Servers, select the server or collective.
2. In the System Management Tools pane, select Security > Identities, Users, & Groups.
3. Click the PI Groups tab.
4. Click the New button to open the New Group dialog box.
5. In Group, type the name for the new PI group. This field is required.
6. In Server, select the appropriate server. This list shows the servers selected under
Collectives and Servers.
7. In Description, enter a brief description, if desired. There are no restrictions on the contents
of this field.
8. Click Create to create the new PI group.


PI interface connections through PI API
The PI Application Programming Interface (PI API) allows for transport security for
applications built with the PI API versions. The PI API is a library of functions that read and
write values to and from PI Data Archive, and also let you retrieve point configuration
information. OSIsoft uses the PI API to create interfaces that run on a variety of platforms. The
PI API provides a framework for connecting PI Data Archive to PI interfaces, or any other PI
API-based client application.
For more information on the PI API, refer to the PI API Programmer's Help. You can access this
from PI SDK Help.

• PI API 2016 for Windows Integrated Security
• Configure PI interface connections using PI trusts
PI API 2016 for Windows Integrated Security

Starting with the release of PI API 2016 for Windows Integrated Security, PI API-based client
applications support Windows authentication and improved transport security. Windows
security encompasses more than just authenticating identity. Transport security improves
message integrity and privacy. The PI System uses the Windows logon security context to
protect integrity and privacy of data communications. Activated protections include session
keys, confidentiality, and integrity (with replay and sequence detection). Prior to this PI API
update, PI trusts were used to configure authentication on the connection between PI Data
Archive and PI interfaces (or other PI API-based application). With this update to PI API,
Windows authentication support is extended on the PI interface node or any other PI API-
based application connecting to PI Data Archive.
PI API 2016 for Windows Integrated Security brings significant security enhancements for PI
Data Archive client applications, as well as reducing overall risk to the PI system in general. The
security enhancements consist of the following:
• Windows Integrated Security

Previous versions of PI API rely upon PI trusts or explicit logins for authentication. With PI
API 2016 for Windows Integrated Security, Windows authentication becomes the supported
authentication model for PI API-based client applications, such as PI interfaces. Windows
Integrated Security is a more secure authentication model than PI trusts for authenticating
users.
With PI API 2016 for Windows Integrated Security, Windows Integrated Security is enforced
as the only security model to all applications using PI API functions. Implementation of
Windows authentication across the entire PI system deployment offers a familiar
administrative experience, in addition to modern defenses provided by the operating
system. In addition, PI identities allow you to map Windows groups or users to categories of
access permissions. PI mappings are the mechanism for associating Windows users or
groups with PI identities.
Windows Integrated Security is supported on PI Server 3.4.380 or later. As such, PI API
2016 for Windows Integrated Security requires PI Server 3.4.380 or later.

Caution:
PI API 2016 for Windows Integrated Security does not support PI trusts or explicit
logins. If you require PI trusts for authentication, do not upgrade to PI API for
Windows Integrated Security to avoid any potential data loss
• Transport Security
Transport security improves message integrity and privacy. PI API 2016 for Windows
Integrated Security internally routes messages to the local PI Network Manager, which
manages transport security with the PI Data Archive server.
Data integrity provides increased security against malicious attacks and intrusions into
your data infrastructure. Transport security provides an additional layer of defense
essential to protecting against data breaches, injection attacks, unauthorized
eavesdropping, etc. Transport security not only protects your deployment, but the
confidentiality of any secondary infrastructure or client connecting to your system.
For the most secure experience, OSIsoft recommends customers run PI Data Archive 3.4.395
(2015) or later, and PI API 2016 for Windows Integrated Security. Transport security is
supported on all client applications using PI API 2016 for Windows Integrated Security
automatically when connection is to a PI Data Archive server version 2015 or later. If a
buffering node connects to multiple PI Data Archive servers of different versions, transport
security is enabled only on the connections to the PI Data Archive servers with version
3.4.395 or later and PI API 2016 for Windows Integrated Security deployed.
• Software Security
PI API 2016 for Windows Integrated Security is the most secure version of PI API released.
Additionally, PI API 2016 for Windows Integrated Security leverages the greatest number of
Microsoft software security defenses provided by the compiler and operating system. PI API
2016 for Windows Integrated Security was developed specifically for modern Windows
platforms, and enables the server operating system defenses in accordance with Microsoft
security development lifecycle (SDL) guidance. Updated software is critical to defending
against malicious attacks and unauthorized intrusions in your system.
PI API 2016 for Windows Integrated Security is supported on most UniInt PI Interfaces, such
as: PI Interface for OPC DA, PI to PI interface, and Random simulator interface.
Note:
PI API 2016 for Windows Integrated Security is NOT supported on interfaces running on
UNIX or Linux platforms.
OSIsoft recommends upgrading from PI trusts and explicit login to Windows authentication
through the use of PI mappings as the authentication model throughout your PI system.
Applications using PI API 2016 for Windows Integrated Security require a Windows logon or
service accounts to connect with the PI Data Archive server. Therefore, before upgrading to PI
API 2016 for Windows Integrated Security, you must configure PI mappings to replace any
existing PI trusts used by PI interfaces. PI trusts and explicit logins are disabled on PI API 2016
for Windows Integrated Security.
• When should I upgrade to PI API 2016 for Windows Integrated Security?

You should upgrade if your client node supports Windows authentication, and all PI Server
servers connected from this node run version 3.4.380 or later, with PI mappings configured
for the applications running on the client node.

• When should I not upgrade my PI API?
You should defer PI API 2016 upgrade if your Windows platform is unable to meet
minimum requirements or if you need more time to verify compatibility with a custom PI
API application.
• I am not upgrading my PI API. However, I want to upgrade my PI Data Archive

to PI Data Archive. Will upgrading my PI Data Archive server affect my existing
PI trusts?
There is no effect on your existing PI trusts, and they authenticate as normal. If, additionally,
you upgrade to PI API 2016 for Windows Integrated Security, then your existing PI trusts
will not work as expected. This is because PI trusts are not supported once PI API is
upgraded to PI API 2016 for Windows Integrated Security.
PI trusts are still available as a method for authenticating PI interfaces. However, the use of PI
trusts should be reserved to cases where Windows authentication cannot be used. In such
cases, do not install or upgrade to PI API 2016 for Windows Integrated Security, as it does not
support PI trusts or explicit logins.
Configure PI interface connections using PI mappings

Starting with the release of PI API 2016 for Windows Integrated Security, Windows
authentication and transport security extends to all client PI API-based applications, such as PI
interfaces. As a result, OSIsoft recommends upgrading your authentication model to Windows
authentication for all applications using PI API to connect to PI Data Archive.
Before upgrading your PI API to PI API 2016 for Windows Integrated Security, you must
perform the preparatory process outlined in the following sections.
Caution:
PI API 2016 does not support PI trusts and explicit logins. Before upgrading your PI API
to PI API 2016 for Windows Integrated Security, you must first configure PI mappings to
replace any existing PI trusts or explicit logins on PI API. In order to configure a PI
mapping, you will need a Windows logon or service account for the PI API application.
Procedure
1. Task 1: Ensure system requirements.
2. Task 2: Identify all PI trusts and corresponding PI identities.
3. Task 3: Identify Windows account for your interfaces.
4. Task 4: Change the login credentials for your interfaces.
5. Task 5: Create PI mappings between the Windows account and PI identities.
6. Task 6: Retire PI trusts.
Task 1: Ensure system requirements

In order to take advantage of the security improvements of Windows Integrated Security, you
must be running PI Data Archive 3.4.380 or later in your PI deployment. Support for PI API
2016 for Windows Integrated Security requires PI Data Archive 3.4.380 or later. Therefore, the
first step for installation or upgrade to PI API 2016 for Windows Integrated Security requires
ensuring that your PI Data Archive meets this minimum requirement.

Procedure
1. Check the PI Data Archive version number.
a. Open a command prompt window.
b. Go to the %PISERVER%\adm directory.
c. Type: piversion -v at the command prompt.
2. If the version number is earlier than 3.4.380, upgrade your PI Data Archive server to the
most recent version.
Task 2: Identify all PI trusts and corresponding PI identities

Before upgrading your PI API to PI API 2016 for Windows Integrated Security, you must first
configure PI mappings to replace any existing PI trusts or explicit logins on PI API. The second
task of this process is to identify all PI identities currently being used by PI trusts on your PI
interfaces running on the Interface node.
Consider the following factors:
• Which PI identity will you use to grant the interfaces access to the PI Data Archive?
• Which PI identities are currently being used and evaluate if it is worth preserving for the
upgraded PI API, or if a new PI identity is more suitable?
Procedure
1. Determine the name of the configured PI trust using the PI SMT Network Statistics plug-in.
a. Open PI SMT and expand Operation on the left pane.
b. Select Network Manager Statistics.
c. Identify the PI Data Archive in the Server list.
d. Identify the interface by the service name (interfaces run as services) and PeerAddress.
Identify the corresponding name of the trust in the Trust column for that interface. For
interfaces that are not running, the trust can be determined by examining the trust table
under Mappings & Trusts as described in the following steps.
2. Open PI SMT and expand Security on the left pane.
3. Select Mappings & Trusts.
4. Select the Trust tab.
5. For interfaces that are not running, identify the trust based on the Application Name,
Network Path and/or IP Address. Identify the PI User associated with this trust. Identify the
interface(s) on your Interface node under Application Name.
6. For interfaces that are running, identify the trust based on the service name (interfaces run
as services) determined in Step 1 and identify the PI user for that trust. Each of these trusts
enable an authentication model where the connection credentials of the interface is
compared to records in the trust database. Each PI trust is defined against a single PI
identity (one type of PI user), PI group (a group of PI users), or PI user (listed under the PI
User column). Take note of this PI Identity (Identity1) for later tasks of the upgrade. When

an interface successfully authenticates through a trust, it gets the access permissions

defined for the associated identity, group, or user.
7. Evaluate if you want to use the existing PI Identity for the upgraded PI API, or if new
identities need to be created.
a. If the PI identity assigned to an existing trust has least privileges or reasonable privileges
for their environment, then use that existing PI Identity. See OSIsoft Knowledge Base
article KB00833 - Seven best practices for securing your PI Server (https://
customers.osisoft.com/s/knowledgearticle?knowledgeArticleUrl=KB00833) for more
information.
b. If the interface is currently using excessive privilege, (for example a trust with piadmin
or piadmins), then consider creating a new PI identity to use for the mapping.
Task 3: Identify Windows account for your interfaces

The third task of replacing existing PI trusts with PI mappings is to identify the current
Windows account configured with the PI interface. This Windows account is referred to as
User1 in the following sections.
The Windows account configured with the interface service can be determined through the
Services console on the Interface node.
For interactive applications using PI API, the Windows account has the same user name as the
user running the application. If multiple users are running the same application, the
recommendation is to create a domain group or a local group on the PI Data Archive with these
multiple members in that group.
Procedure
1. Open Services on the Interface node machine by using the Start Menu > services.msc
command.
2. Select each interface currently running as a service.
3. Right-click on Properties.
4. Click the Log on tab.
5. Identify the name of the Windows account, referred to as User1.
6. Identify the type of account by identifying how the Interface node is accessing the data
source: Local System account or Windows account.
Task 4: Change the login credentials for your interfaces

Before creating new mapping based on your deployment scenario, determine if the user
account configured for your interfaces (User1) is sufficient for your deployment and security
needs. If the existing account is sufficient and aligns with the new mappings, use it as the
Windows account for the upgraded PI API.
Note:
You must restart an interface for any service account change to take effect on the
interface. Evaluate your situation carefully regarding the downtime around the time
necessary for an interface restart. It is important to understand the estimated downtime
for your specific interface, as well as planning for the process.

Consider the following factors on whether to preserve your existing Windows account or
create a new account for the PI API upgrade under the following scenarios:
• The Interface node is on a trusted domain computer. For this type of scenario, if the
Windows account is either a domain Managed Service account (MSA) or custom domain
account, you can just use the same account for the upgraded PI API. An acceptable
alternative can be to use a Network Service account or Virtual account.
• The Interface node is on a workgroup or untrusted domain. For this type of scenario, if the
Windows account is a Local System account (domain account using Windows Credentials
Manager), you can just use the same account for the upgraded PI API. However, if the
Windows account is a Local System Account (mirrored Local System account on PI Data
Archive), we recommend creating a new account for better security.
In addition, consider the following when changing the log on properties for the interface
(running as a service).
• The new user account should have the permissions to the data source. Refer to the interface
user guide specific to your interface for this information, available at the OSIsoft Customer
Portal (https://my.osisoft.com/).
• The new user account should have permissions to access folders and files on the Interface
node required for the interface to run correctly. You can determine whether any specific
folders and file permissions are necessary by referencing the specific PI interface user guide
available from the OSIsoft Customer Portal (https://my.osisoft.com/).
Procedure
1. Open Services in your Interface node machine by using the Start menu > services.msc
command. The PI interfaces run as services and will show up in this window.
2. Click on Properties.
3. Select each PI interface, listed as a service.
4. Enter the log on credentials for each interface to reflect the selected Windows account
determined in an earlier task. See Task 3: Identify Windows account for your interfaces.
5. Restart the interface.
6. Verify that the interface is able to function correctly and still connecting to PI Data Archive
through trusts. This verifies that the new user account for the interface does not have
permission issues with the data source.
Task 5: Create PI mappings between the Windows account and PI

identities
The final task in preparation for a PI API upgrade is to create new PI mappings that associate
the Windows account running your PI interfaces with the PI identities currently being used
with PI trusts on those interfaces. This upgrades your authentication model from PI trusts to
Windows authentication in preparation for the PI API upgrade.
The actual procedure to create new mappings depends upon where the Interface node and PI
Data Archive reside in reference to each other in your deployment. The following sections
discuss five common deployment scenarios, with instructions on how to map your account
with the identity for Windows authentication.

Note:
As a preliminary step for each of the following deployment scenarios, upgrade your PI
Data Archive server to PI Data Archive 2015 R2 SP1 (version 3.4.395.80 or later) to use
Windows authentication and transport security.

• Scenario: Interface node and PI Data Archive on the same node
• Scenario: Interface node and PI Data Archive on the same domain or on trusted domains
• Scenario: Interface node and PI Data Archive on untrusted domains
• Scenario: Interface node or PI Data Archive or both in a workgroup
• Scenario: Mapping for multiple interfaces on the Interface node
Scenario: Interface node and PI Data Archive on the same node

In this deployment scenario, the Interface node and PI Data Archive are both located within the
same node. The objective is to map User1 to Identity1.
Procedure
1. Open PI System Management Tool (SMT). From the Windows Start menu, choose All
Programs > PI System > PI System Management Tools.
2. Expand Security in the left pane. The
4. Click the Mappings tab.
5. Click the New icon to create a new PI mapping.
6. In the Windows Account field, enter the Windows service account, local system account, or
domain account identified in Task 3: Identify Windows account for your interfaces (User1).
The PI mapping associates the PI identity (or PI user or PI group) with the Windows service
account, local system account, or domain account. Authenticated Windows accounts are
automatically authenticated on PI Data Archive through the mapping.
7. In the Server field, select the PI Data Archive server to which you want to create the
mapping. In the PI Identity field, enter the PI user or PI group from Task 2: Identify all PI
trusts and corresponding PI identities (Identity1).
This PI mapping associates the PI identity (or PI user or PI group) to the Windows service
account, local system account, or domain account. With mappings, your accounts are
granted access and permissions based upon the corresponding PI identity associated with
the mapping on the PI Data Archive server.
Scenario: Interface node and PI Data Archive on the same domain or on trusted
domains
In this deployment scenario, the Interface node and PI Data Archive are located in the same
domain, or different but trusted domains. In the case of trusted domains, if there is one-way
trust between the domains, then the direction of the trust is important. The domain with PI
Data Archive must trust the domain with the Interface node. The objective is to map User1 to
Identity1.

Procedure
• If the Windows account (User1) is a Local System account or Network Service account, map
the interface node name (<Domain>\<InterfaceNodeName>$) to your PI identity
(Identity1).
• If the Windows account (User1) is a domain account, map the account (User1) to your PI
identity (Identity1) as described in the earlier scenario. See Scenario: Interface node and PI
Data Archive on the same node.
• If the Windows account (User1) is a local account, then either:
◦ Change the user account for the interface to a domain account. See Task 4: Change the
login credentials for your interfaces.
◦ Map the account (User1) to a domain account (DomainUser1) in Windows Credential
Manager on the Interface node (see Windows Credential Manager). Map DomainUser1 to
Identity1 on PI Data Archive using PI SMT.
◦ Create the same account (User1) on PI Data Archive with the same credentials as the
account on the Interface node. Map ServerNode\User1 to Identity1 .on PI Data Archive
using PI SMT.
Caution:
Identical user accounts and passwords is a form of credential reuse. Verify identical
accounts are consistent with your IT policies.
Scenario: Interface node and PI Data Archive on untrusted domains

In this deployment scenario, the Interface node and PI Data Archive are located in different
domains, and the domains are not trusted domains. The objective is to map User1 to Identity1.
Procedure
• If the Windows account (User1) is a local account or a domain account on the Interface node
domain, then either:
◦ Map Windows account (User1) to a PI Data Archive domain account (ServerDomain
\DomainUser1) in Windows Credential Manager on the Interface node. See Windows
Credential Manager. Map ServerDomain\DomainUser1 to Identity1 on PI Data Archive.
◦ Create the same Windows account (User1) on thePI Data Archive node with the same
credentials as the account on the Interface node. Map ServerNode\User1 to Identity1.
• If Windows account (User1) is either a Local System account or Network Service account,
change the user account of the Interface node to enable Windows authentication (see Task
4: Change the login credentials for your interfaces).
Windows Credential Manager
In deployment scenarios where the PI Data Archive server exists in an untrusted Domain
\Workgroup, a user can save the Windows credentials used for authenticating into that
untrusted Domain\Workgroup in Windows Credential Manager. As a result, when the user
connects to a PI Data Archive through Windows authentication and there is a saved set of
Windows credentials for the network path of that PI Data Archive, the stored Windows
credentials will be used in place of the user's actual Windows credentials.

See the OSIsoft Knowledge Base article KB00354 - Supported Windows Security
Configurations in Domains and Workgroups for the PI Data Archive (https://
customers.osisoft.com/s/knowledgearticle?knowledgeArticleUrl=KB00354) for more
information about the used of Windows Credential Manager.
Scenario: Interface node or PI Data Archive or both in a workgroup

In this deployment scenario, the Interface node and/or PI Data Archive are setup to be
accessed within a Windows workgroup. In a Workgroup, all users and passwords are local to
each machine and thus requires effort to manage them (keep the credentials all identical).
Procedure
• If the Windows account (User1) is a local account, then create the same account (User1) on
the PI Data Archive with same credentials as the account on the Interface node. Map
ServerNode\User1 to Identity1.
• If the Windows account (User1) is a either Local System account or Network Service
account, you must change the user account for the Interface node to use a local account to
enable Windows authentication. See Task 4: Change the login credentials for your
interfaces.
Scenario: Mapping for multiple interfaces on the Interface node

This deployment scenario considers an Interface node with multiple interfaces, where the
interfaces do not use the same PI Identity to connect to PI Data Archive. In this type of scenario,
different user accounts must be used for the interfaces that map to different PI Identities.
Procedure
1. Create the necessary number of new Windows domain account to accommodate each
different PI identity used for the mappings to access Create a new Windows domain
account.
2. Map a new account to a distinct PI identity used on the Interface node. Repeat until all of the
distinct PI identities are mapped.
Mapping three PI interfaces and two PI identities

Consider a deployment with three interfaces running on the Interface node: Interface1,
Interface2 and Interface3. In this scenario, Interface1 and Interface2 connect with the same PI
Identity: Identity12, as determined in Step 2. Interface3 connects a different PI Identity:
Identity3). All three interfaces run through a Local System account, and the Interface node and
PI Data Archive are on the same domain.
Mapping the interface node to Identity12 grants the appropriate permissions for Interface1 and
Interface2. However, for Interface3 to continue using Identity3, a new mapping is necessary. A
Windows account can only be mapped to one identity, therefore it is necessary to identify (or
create) a new Window account for Interface3.
Create a new Windows domain user User3. Then, create a new PI mapping that associates the
new User3 account to Identity3.

Task 6: Retire PI trusts

The final step is to retire the existing PI trusts on the Interface node.
Procedure
1. Open PI SMT and expand Security on the left pane.
3. Select the Trust tab.
4. Disable or delete the trust(s) from the Interface node.
Installing and upgrading PI API 2016 for Windows Integrated Security

PI API 2016 for Windows Integrated Security is available as a standalone setup kit on the
OSIsoft Customer Portal (https://my.osisoft.com/). The kit contains both 32-bit and 64-bit
versions of the software.
Before you start

After configuring PI mappings to replace any existing PI trusts or explicit logins on PI API, you
are ready to install/update it to PI API 2016 for Windows Integrated Security.
Caution:
PI API 2016 for Windows Integrated Security does not support PI trusts and explicit
logins. On upgrade, PI Mappings must be configured to replace any existing PI trusts or
explicit logins
For detailed instructions on this preparation process, see Configure PI interface connections
using PI mappings.
Procedure
1. Download the setup kit on the Interface node from the OSIsoft Customer Portal (https://
my.osisoft.com/).
2. Run the installation program to install the PI API 2016 for Windows Integrated Security
files. The setup kit will use the existing installation path.
3. Specify the PI Data Archive hostname for a new PI API installation. For a PI API upgrade, the
setup will use the existing settings.
4. Follow the remaining prompts to finish the installation.
5. Run the interface as an automatic Windows service.
6. Verify that the interface is running properly.
a. Open PISDKUtility to view the logged interface messages.
b. Open PI SMT and expand Operation on the left pane.
c. Select Network Manager Statistics.
d. Ensure that the connection is using the proper account and PI Identity.
7. Disable the existing PI trust(s) replaced by the new PI mapping(s).

Uninstalling PI API 2016 for Windows Integrated Security

Uninstalling PI API 2016 for Windows Integrated Security rolls back the PI API to PI API
1.6.8.22. However, if no other application requires the PI API files, then the files are removed
from the system completely. The following scenarios illustrate the uninstall process:
• If you installed the PI SDK (which installed PI API 1.6.8.22), and then upgrade to PI API
2016 for Windows Integrated Security, when you uninstall PI API 2016 for Windows
Integrated Security, the PI API will be rolled back to PI API 1.6.8.22.
• If you installed PI API 2016 for Windows Integrated Security as a new PI API install, when
you uninstall it, all PI API files will be removed completely and there is no rollback.
• If you installed PI API 2016 for Windows Integrated Security as a new install, then installed
PI SDK, uninstalling PI API 2016 for Windows Integrated Security will roll back PI API to PI
API 1.6.8.22.
• If you installed the PI SDK before upgrading PI API, upgrade PI API to PI API 2016 for
Windows Integrated Security, and then uninstall both the PI API and PI SDK. In this
scenario, all PI API files will be uninstalled.
Procedure
1. Open Windows Control Panel.
2. Select PI API 2016 for Windows Integrated Security from the Add or Remove Programs.
3. Remove PI API 2016 for Windows Integrated Security from the list.
Configure PI interface connections using PI trusts

PI trusts are still available as a method for authenticating PI interfaces. However, the use of PI
trusts for interfaces should be reserved to cases where Windows authentication cannot be
used. For example, the interface node is running an older version of the PI API and cannot be
upgraded at this time. Instead, use the PI API 1.6.8 or earlier and configure this connection
using PI trusts for authentication.
Note:
If the client application does not support Windows authentication and/or must connect
to PI Server versions prior to 3.4.380, do not install or upgrade to PI API 2016 for
Windows Integrated Security, as it does not support PI trusts or explicit logins.
Configure your PI Data Archive server to provide access for PI interfaces using PI trusts on PI
API 1.6.8 or earlier.
Procedure
1. Identify all the PI interfaces that need access to the PI Data Archive server.
2. Consult the documentation for each interface and gather the information you need to
configure the PI trust. You need to know the connection type (Connection types (PI API and
PI SDK)). 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)
◦ IP information for the connecting computer (IP information in SMT)
◦ For SDK connections only, you have the option to specify Windows account information,
but this is not recommended (Windows account information)
3. Decide how many PI trusts you will create.
You can create explicit individual trusts for each PI interface or you can group them
according to subnet, host machine, or username. A group of PI interfaces can share the same
privileges.
4. For each PI trust, create a PI identity.
See Create a PI identity.
5. Give that PI identity all the access permissions required by the PI trust.
See Product access permissions reference and configuration issues as well as the
documentation for the interface.
6. Create a trust based on that PI identity.
See Create a trust.

• About PI trusts
• Create a trust
About PI trusts
PI trusts allow applications to access the PI Data Archive server without explicitly logging onto
Windows (or onto the PI Data Archive server). In earlier versions of PI API, you used trusts for
PI interfaces, which ran unattended. Starting with PI API 2016 for Windows Integrated
Security, we recommend using Windows authentication for PI interfaces. However, PI trusts are
still supported by the PI Data Archive for scenarios where Windows Integrated Security is not
an option, and if the API-based client applications is not running PI API 2016 for Windows
Integrated Security.
Each PI 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.
Create a trust
Procedure
1. Under Servers (or if you have a collective deployment, Collectives and Servers), select the
server.
2. Under System Management Tools, select Security > Mappings & Trusts.
The Mappings & Trusts tool appears.
3. Select the Trusts tab.

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

5. Select the PI Data Archive server name and enter a name for the trust (and, optionally, a
description). Click Next.
6. Select the type of trust to add:
◦ PI-API application (this is the right choice for most PI interfaces)
◦ PI-SDK application on a Windows NT based OS
7. Click Next.
The next screens allow you to define optional information for the PI 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 PI
trust.
◦ Application Name
This is slightly different for PI API and PI 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
The full name of the connecting application, including the extension, but not the path
(for example, PI-ICU.exe).
◦ 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:
◦ 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 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 (PI API and PI SDK)
• The application name
• IP information in SMT

• Windows account information
Connection types (PI API and PI SDK)

When you configure a PI trust, you need to know the type of connection the trust will be used
for. There are two different PI Data Archive connection types. Each PI 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 PI interfaces use the PI API to connect to the PI Data Archive server.
• PI SDK Connection: Most client applications use the PI SDK to connect to the PI Data Archive
server.
The PI API and PI SDK connections both support Windows authentication, which is the most
secure authentication method available for thePI Data Archive server. OSIsoft recommends that
you always use Windows authentication when possible.
The application name

A PI 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:
• Applications that connect through PI API send an identifier called an application process
name, or procname. This is a four-character string with an E appended. For example, the
procname for the Perfmon interface is: PIPeE
Note:
PI API versions before 1.6.0 always send a five-character string: 4 characters plus a
capital E. For PI API versions 1.6.0 and later, up to 8 characters may be specified as the
procname, if configured to do so (in this case, there is no longer an E appended to the
procname).
• For applications that connect through PI SDK, use the full name of the connecting
application, including the extension, but not the path. For example, the application name for
PI ICU is: PI-ICU.exe
If you are running the same PI interface on another PI Data Archive server, then you can use PI
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. See the
OSIsoft Knowledge Base article How to recognize connecting application names in the PI
Network Manager Statistics table and message logs (https://customers.osisoft.com/s/
knowledgearticle?knowledgeArticleUrl=KB00505).
IP information in SMT
A PI trust can specify IP information about the computer running the PI 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 PI Data Archive computer. If you have difficulty configuring the trust, visit the
OSIsoft Customer Portal (https://my.osisoft.com/).
• Network Path. The fully-qualified domain name. For PI API, this should match what the PI
Data Archive 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 PI Data Archive server for the trust
authorization. OSIsoft thus recommends that you either avoid such configurations, or
create a PI 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 PI 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.


Configuring security for PI Data Archive upgrades
When you upgrade to PI Server 3.4.380 or later from an earlier version, you get access to a
variety of new features and components. If you are upgrading from an older version of the PI
Data Archive server, this section discusses what you need to know.

• What is in the new security model?
• Why a new security model?
• Your upgrade options
What is in the new security model?

The new security model introduces a number of changes to the PI Data Archive server:
• Windows Authentication
Previous versions of PI Data Archive had two methods of authentication: PI trusts and PI
password authentication (typing in PI user name and password). PI Server 3.4.380 adds a
third method: Windows authentication. This method is more secure than the other two and
is now the recommended method for authenticating connections.
• 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 PI Data Archive 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 PI Data Archive server without creating a
separate set of credentials.
• 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 PI SMT

PI 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.
You can replace these components over time.

Note:
Previous versions of PI Data Archive 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 PI Data Archive had a
built-in PI user and a built-in PI group that were both named piuser.
Why a new security model?

The new PI Data Archive security model has the following major benefits:
• Improves Security
You can now use Windows authentication to control user access to the PI Data Archive
server. PI password authentication (typing in a PI user name and password) are nowhere
near as secure as Windows authentication. If you configure your PI Data Archive 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 PI Data Archive server configuration by maintaining a
much smaller set of PI identities. Each PI identity should define a unique set of access
permissions on the PI Data Archive 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 PI Data
Archive server.
• Provides Single Sign-on

If you use Windows for authentication, your users no longer need to separately log onto the
PI Data Archive 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 PI Data Archive server to the new model,
but you are not required to do that. Here are your options:
• Option 1: Migrate over time

If you choose this option, you immediately switch to Windows authentication, but you
continue to use some components of your existing configuration. You can replace these
components over time. See Migrate over time for instructions. This is the recommended path
for most PI Data Archive 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 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 Set
up a new security configuration 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 for tips and concerns.

• Quick-start security migration
• Migrate over time
• Set up a new security configuration
• Keep existing configuration
Quick-start security migration

Many PI Data Archive 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 PI Data Archive security.
Although these instructions assume you are using the piadmin and pidemo accounts, note that
you can apply the same method to any PI Data Archive 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 for more information.
Procedure
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 PI Data Archive 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.
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 PI Data Archive 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.
After you finish

This completes the basic configuration on the PI Data Archive server. As soon as possible,
consider these additional steps for further securing your PI Data Archive 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 PI Data Archive server disallows user-name and password access for
those accounts and only provides access through the mappings you created or through PI
trusts. See Disable explicit logins for individual user accounts 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.
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 PI Data Archive security configuration that uses
Windows authentication. See Initial configuration steps.
• Follow-up Steps
Perform these follow-up steps over time. See Follow-up steps.
If your existing configuration relies on very few PI users or PI groups, the Quick-start security
migration might work better for you.

• Initial configuration steps
• Follow-up steps
Initial configuration steps

When you migrate your PI Data Archive 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 PI Data Archive server. You can use components of your existing
configuration, which you can replace over time.
Procedure
1. Review existing access permissions.

Export the access permissions for all existing points and modules and for all the entries in
the PI SMT Database Security tool. See Review access permissions.
2. Create a list of unique access strings.
You will use this list to determine the needed sets of access permissions. See Create a list of
unique access strings.
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.
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.
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.
6. Create the mappings.
Set up mappings between AD groups and PI groups and identities. See Create mappings in
SMT.
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.
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 PI SMT.
Note:
If you do not need to preserve existing access permissions, then you can implement a
new security configuration instead (Configuring security on a new PI Data Archive
installation).
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 PI Data Archive 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 PI Data Archive 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 PI Data Archive server for more information on the ACL.
Create an access permissions spreadsheet

To create a spreadsheet that contains all the existing access permissions on your PI Data
Archive server, create the following three separate spreadsheets and merge them together:
• Point Data and Point Configuration

Use PI Builder 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 PI Data Archive server you are using.
◦ For PI Server 3.4.380 and later, import the ptsecurity and datasecurity attributes (these
attributes are new in PI Server 3.4.380).
◦ On earlier versions of the PI Data Archive 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 PI SMT. Click the Export To File button to export the list
into a .csv file. Open that file in Excel.
Create a list of unique access strings

Examine the spreadsheet containing the access permissions for the PI Data Archive 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.4.380, 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 PI Data
Archive server that uses the old security model. Notice that the access permissions are exactly
the same for most of the tags.
point dataaccess datagroup dataowner
tag1 o:rw g:r w:r pi_ops bob
tag4 o:rw g:rw w:r pi_eng nancy
The following table shows what the same access permissions look like after upgrading to PI
Server 3.4.380.
point datasecurity
tag1 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)

point datasecurity
tag4 nancy: A(r,w) | pi_eng: A(r,w) | PIWorld: A(r)
What we want to do is collapse these access permissions into a set of unique access strings. It
does not matter whether we use the owner/group/word notation or the ACL strings. We will
use ACLs for the rest of this example.
We would then have the following:

point datasecurity
datasecurity for tag4 nancy: A(r,w) | pi_eng: A(r,w) | PIWorld: A(r)
datasecurity for: tag1, tag2, tag3, tag5 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)
In this manner, reduce all your access permissions to a set of unique access strings. The next
step is to determine what PI groups you need, based on this list.
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:
Points datasecurity
tag4 nancy: A(r,w) | pi_eng: A(r,w) | PIWorld: A(r)
tag1, tag2, tag3, tag5 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)
We need to distill our list down into the smallest number of access permission sets and we
need to keep track of who currently has that level of access. Another way to look at our current
access permissions is as follows:

Who? What Access?

bob read/write access to tag1, tag2, tag3, tag5
pi_eng read/write access to tag 4
nancy read/write access to tag 4
pi_ops read only access to tag1, tag2, tag3, tag5
PIWorld read only access to all tags
Looking at the above table, notice the following:
• If we are not going to disable PIWorld, then the pi_ops access permissions are not needed.
For the purposes of this example, assume we will continue to rely on PIWorld.
• The PI user nancy and the PI group pi_eng have identical access permissions. Since these
access permissions are already defined for pi_eng, we will leave this PI group in place. We
need to create a mapping between pi_eng and a Windows group that contains the following
users:
◦ Windows users represented by the PI user members of pi_eng
◦ Windows user represented by the PI user nancy
We can retire the PI user called nancy.
• The PI user bob has unique access permissions. We have two choices:
◦ We can keep the PI user bob and create a mapping between the corresponding Windows
user and PI user bob. This gives us Windows authentication, which is much more secure
than PI user accounts. We can continue to use the access permissions defined for bob.
◦ Another solution would be to create a new PI identity, grant it the same access
permissions as bob then map a Windows group containing the corresponding Windows
user to this new PI identity.
We choose to continue using bob for now, but we plan to create a new PI identity and retire
the PI user bob in the future.
The following table summarizes our new security configuration:

Keep: Type: Mapping:
pi_eng PI group Windows group containing the users
represented by the PI user pi_eng;
Windows user represented by the PI
User nancy.
bob PI user Windows user represented by the PI
User bob.

Keep: Type: Mapping:

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.
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.
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 PI password
authentication.
Review AD groups
Ideally, you want one AD group for each PI group and PI identity on your PI Data Archive
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 PI Data Archive server. You need an AD group for each set of access permissions.
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 PI Data Archive
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.
Create mappings in SMT
Procedure
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:
6. See Specifying AD users and groups for more information.
Verify initial configuration

After you complete your initial PI Data Archive security configuration, deploy to a small
number of test clients. Verify that the connections are working. Exercise all the mappings from
this small set of clients and verify with test applications that you get proper authentication and
proper access permissions through your mappings.
Follow-up steps
After you have an initial PI Data Archive server configuration, you can continue to transition to
the new model over time. This section discusses some measures that you should take.
• Check custom PI API applications

A security loophole in earlier versions of the PI Data Archive server allowed world access to
PI 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 PI API applications that rely on
this loophole. Current versions of the PI Data Archive server permanently disable that
access and any applications that rely on that access will no longer have access to the PI Data
Archive server. You will need to configure authentication for these applications. (This is
typically only a problem for custom PI API applications.) See Check for unauthenticated PI
API connections.
• 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
dministrative tasks (see Protect piadmin in PI SMT).
• Upgrade the SDK on client computers

On computers running client applications, upgrade PI SDK to PI SDK 2016 to utilize
Windows authentication and transport security. PI SDK version 1.3.6 and later support
Windows authentication but not transport security. Versions earlier than 1.3.6 of the SDK do
not support transport security nor Windows authentication.

• Configure application server clients
If you are using applications where the client is accessing the PI Data Archive 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 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 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 PI password authentication). This is the least secure PI Data Archive server
authentication method and it is best to disable it entirely or at least partially. See Disable PI
password authentication (explicit logins) for more information.
Note:
Remember that support for transport security and Windows authentication requires
PI SDK 2016, while 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 PI trusts. In most
cases, the PI Data Archive server will no longer use existing trusts anyway (see Retire SDK
trusts).
• 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 PI Data Archive 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 PI Data Archive server). Additionally, PI
users have associated passwords that are not secure. Ideally, you should plan to replace
your PI users and PI groups with descriptively-named PI identities.
To further improve security, see Tightening security.
Set up a new security configuration

To set up a new security configuration using Windows for authentication, configure security as
you would for a new PI Data Archive installation. See Configuring security on a new PI Data
Archive installation. 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. You can choose if and when to complete each step.
Keep existing configuration

You can continue to use your existing PI Data Archive security configuration for as long as you
choose. There are a few things you should do immediately:

• Check custom PI API applications.

A security loophole in earlier versions of the PI Data Archive server allowed world access to
PI API connections, even if the authentication failed. That loophole is now closed. If you
have PI API applications that rely on this loophole, they will no longer get access. This is
typically only a problem for custom PI API applications. See Check for unauthenticated PI
API connections.
• Protect the piadmin account with a password.

The piadmin PI user is the PI Data Archive 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 in PI SMT 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.
Plan to migrate to the new security model. You can do this gradually over time. See Migrate
over time. Even before you begin configuration on the PI Data Archive server, you can gradually
perform many of the steps listed in Follow-up steps.

Security for PI Data Archive collectives
This section discusses security configuration when you enable PI Data Archive high availability
(HA) features by configuring a PI Data Archive collective.

• Overview of security in PI Data Archive collectives
• Mapping unresolved users
• Enable the lookup-failure tuning parameter
• Creation of mappings with a Windows Security ID (SID)
Overview of security in PI Data Archive collectives

PI Data Archive collectives support Windows authentication. In a standard configuration, a
collective replicates the PI security mappings defined on the primary server across all
collective members. In non-homogeneous security environments or environments without
Microsoft Active Directory (AD), PI mappings on a specific collective member will reference
Windows users or groups that are not valid on other collective members. In this case, the
replication process will fail. Therefore, you cannot simply replicate mappings: you must use a
custom configuration.
In a standard configuration, where all collective members are in the same security
environment and you are using AD, you configure security on the collective’s primary server
just as you would configure a single PI Data Archive server. The collective’s PI Data Archive
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 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 PI applications and users when accessing
PI Data Archive information. If the same mappings are not available on all collective members,
applications might fail to connect or might receive different permissions on failovers. OSIsoft
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. Visit the OSIsoft Customer
Portal (https://my.osisoft.com/) if you need help.
Mapping unresolved users

To use a custom security configuration in a PI Data Archive collective, you must configure the
PI Data Archive server to accept unresolvable security mappings during replication. The PI
Data Archive 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 Enable the lookup-failure
tuning parameter.
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 the Windows Security ID
(SID) of a group instead of the group name when you configure a mapping for a local Windows
group. Because you cannot use PI SMT to create mappings based on SIDs, you must use
piconfig. See Creation of mappings with a Windows Security ID (SID).
Enable the lookup-failure tuning parameter

You must enable the lookup-failure tuning parameter on any secondary PI Data Archive server
in a PI Data Archive 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 PI Data
Archivecollective if you define mappings valid only on secondary servers.
Note:
Like any tuning parameter, collectives do not replicate this setting.
Procedure
1. Click Start > All Programs > PI System > PI System Management Tools.
2. Under Collectives and Servers, select the PI Data Archive server where you want to enable
the tuning parameter.
3. Under System Management Tools, select Operation > Tuning Parameters.
4. Click the New Parameter button.
5. In Parameter name, type:
Base_AllowSIDLookupFailureForMapping
6. In Value, type:
1
7. Click OK.
8. Restart the server’s PI Base Subsystem.

Creation of mappings with a Windows Security ID (SID)

After you enable the lookup-failure tuning parameter, you must use a group’s SID instead of its
name when you configure a mapping for a local Windows group. Use PI SMT to determine the
SID, and use piconfig to create the mapping based on that SID.
OSIsoft recommends that you enable the lookup-failure tuning parameter only when you create
mappings. After you create mappings and the primary server replicates the mappings to the PI
Data Archive collective, you can disable the parameter to protect against the accidental
creation of invalid mappings.


Tightening security
This section discusses how you can improve the security on your PI Data Archive server.
The slider position of the Security Settings tool in PI SMT offers one measure as to the level of
security around your PI Data Archive. Once you have upgraded to PI API 2016 for Windows
Integrated Security, and migrated all clients to Windows authentication and away from PI
trusts, you can move your slider to the top level.
For more information about PI Data Archive security, see the OSIsoft Knowledge Base Article
Seven best practices for securing your PI Server (https://customers.osisoft.com/s/
knowledgearticle?knowledgeArticleUrl=KB00833).

• Upgrade PI API
• Retire PI trusts
• Protect piadmin in PI SMT
• Disable PI password authentication (explicit logins)
• Retire SDK trusts
• Configure PI Firewall
• Disable PIWorld
Upgrade PI API
Starting with the release of PI API 2016 for Windows Integrated Security, Windows
authentication and transport security extends to all client API-based applications, such as PI
interfaces. As a result, OSIsoft recommends upgrading your authentication model to Windows
authentication for all applications using PI API to connect to PI Data Archive. Before upgrading
your PI API to PI API 2016 for Windows Integrated Security, you must replace any existing PI
trusts with PI mappings.
Caution:
PI API 2016 does not support PI trusts and explicit logins. Before upgrading your PI API
to PI API 2016 for Windows Integrated Security, you must first configure PI mappings to
replace any existing PI trusts or explicit logins on PI API. In order to configure a PI
mapping, you will need a Windows logon or service account for the PI API application.
For detailed information on how to upgrade to PI API 2016 for Windows Integrated Security,
see Installing and upgrading PI API 2016 for Windows Integrated Security.
Retire PI trusts
After replacing any existing PI trusts with PI mappings, retire all PI trusts as an authentication
model.
Prior to the availability for Windows authentication on PI API enabled by the release of PI API
2016 for Windows Integrated Security, PI trusts were typically used to authenticate API-based

Tightening security
client applications that ran unattended, such as PI interfaces. 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. PI trust
authentication is a weak form of authentication compared to Windows authentication, and is
not recommended.
For information about retiring PI trusts, see Task 6: Retire PI trusts.
Protect piadmin in PI SMT

The piadmin PI user is the PI Data Archive 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). Explicit
logins (also called password authentication) on the PI Data Archive server are not nearly as
secure as Windows authentication or PI trusts. Although the password mechanism
performs as designed, weakness exists due to the use of a proprietary cypher developed in
the 1990s that has not been modified to keep up with modern cryptographic advances. In
short, the explicit login as an authentication method is not secure from malicious actors.
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 PI Data Archive 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 for more
information.
Disable explicit logins for piadmin

When you disable explicit logins for piadmin, users cannot access the PI Data Archive server by
typing in the username and password. However, mappings and trusts can still use piadmin.
Procedure
1. In PI SMT, open the Identities, Users, & Groups tool (under System Management Tools,
select Security > Identities, Users, & Groups).
3. Double-click the piadmin entry.
4. On the General tab, select the User cannot be used for an explicit login check box.
5. Click OK.

Tightening security
Disable PI password authentication (explicit logins)

When a user logs onto the PI Data Archive server by typing in a PI user name and password,
this is called an explicit login (or password authentication). Explicit logins on the PI Data
Archive server are the least secure authentication method available to you. A good security
practice is to disable all explicit logins on the PI Data Archive 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. 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. 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. As you begin to configure Windows
authentication for your users, you can disable explicit logins for these accounts.

• Disable all explicit logins
• Disable explicit logins with blank passwords
• Disable explicit logins for individual user accounts
Disable all explicit logins

In PI SMT you can use the Security Settings tool to disable all explicit logins.
Procedure
1. Under System Management Tools, select Security > Security Settings. The Security Settings
tool opens.
You can change settings for only one PI Server server at a time and only for PI Server servers
running version 3.4.380 or later.
3. Move the slider to the Explicit login disabled option.

Tightening security
4. Click Save.
5. Stop and restart PI Base Subsystem:
a. Under System Management Tools, select Operation > PI Services.
b. Right-click the PI Base Subsystem entry and choose Stop Service.
c. After the subsystem stops, right-click on the PI Base Subsystem entry again and choose
Start Service.
Disable explicit logins with blank passwords

In PI SMT you can use the Security Settings tool to disable explicit logins for PI user accounts
that do not have passwords.
Procedure
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 PI
Data Archive server at a time and only for PI Server servers running version 3.4.380 or later.
3. Move the slider to the Blank password not allowed option.
4. Click Save.
c. After the subsystem stops, right-click the PI Base Subsystem entry again and choose
Start Service.
Disable explicit logins for individual user accounts

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

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

The Properties dialog box for that PI user opens.
4. On the General tab, select the User cannot be used for an explicit login check box.
5. Click OK.
To re-enable explicit logins for a PI user account, clear the same check box.
Retire SDK trusts

The PI SDK (version 1.3.6 and later) supports Windows authentication, so you can almost
always use a mapping rather than a trust. You should do that for two reasons:
• Though more secure than explicit logins, PI trusts are not as secure as Windows
authentication.
• If you create a trust, application users might still be authenticated through Windows and
not the trust (Windows authentication versus SDK trusts). 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 PI
Data Archive server by disabling SDK trusts altogether.

• Windows authentication versus SDK trusts
• Configure SDK authentication protocols in SMT
• Disable SDK trusts
Windows authentication versus SDK trusts

If a Windows user running an SDK application has access to the PI Data Archive 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.
Configure SDK authentication protocols in SMT

When a PI SDK application attempts to connect to the PI Data Archive 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. OSIsoft recommends you use this method wherever possible.

Tightening 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.
• PI Trust.
If the connection request matches an existing PI trust, then the user is authenticated as the
PI identity, PI user, or PI group defined for that trust.
• A default PI user account. OSIsoft does not recommend this method.
The first method that succeeds defines the access permissions granted to the connecting
application. After an 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 use PI SMT to configure the methods the SDK tries first:
Procedure
1. Select File > Connections to open PI 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 PI Connection Manager from the About PI-SDK application. Select
File > Connections.
Disable SDK trusts

In PI SMT you can use the Security Settings tool to disable access to the PI Data Archive server
through SDK trusts.
Procedure
1. Under System Management Tools, select Security > Security Settings.
The Security Settings tool opens.
You can change settings for only one PI Data Archive server at a time and only for PI Server
servers running version 3.4.380 or later.
3. Move the slider to the SDK trusts are disabled option.

Tightening security
4. Click Save.
c. After the subsystem stops, right-click the PI Base Subsystem entry again and choose
Start Service.
Configure PI Firewall
For all incoming connections, the PI Data Archive 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 PI Data Archive 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 PI SMT Firewall tool, which you can access by choosing Security > Firewall. PI
Data Archive collectives do not replicate the PIFIREWALL table.
Note:
PIFIREWALL does not filter IPv6 traffic.
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 PI
SMT, choose Security > Database Security.
Tip:
Use Windows firewall or install a hardware firewall for additional security. PIFIREWALL
is installed by default with PI Data Archive, and blocks connections to the PI System only.
A Windows firewall or a hardware firewall offer more robust firewall filtering, such as
IPv6 filtering. Using a Windows firewall or hardware firewall in addition to the
PIFIREWALL is recommended.
Disable PIWorld
You can disable the PIWorld identity. This improves your control over access to the PI Data
Archive 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.

Tightening security
• For PI Data Archive server upgrades, or for new installations that are part of an existing
configuration of PI 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, contact the OSIsoft Customer Portal (https://
my.osisoft.com/) to help you form a plan.
• OSIsoft recommends disabling the PIWorld identity for all new installations.

How will PI Server 3.4.380 affect my clients and
interfaces?
In most cases, the new security model does not affect PI client applications. Additional security
configuration steps might be necessary for:
• Products that connect to an application server

• Products that connect through a trust (most will work fine; some custom applications might
need reconfiguring)
Unless a client meets one of the above criteria, it should work with the PI Server 3.4.380
without any extra configuration. If you want to use new PI Data Archive security features, you
need to:
• Upgrade the PI SDK to PI SDK 2016 or later. Nearly all functionality for the new Windows
security and transport security on the client side resides within the PI SDK.
• Upgrade Administrative client applications (applications that can set access permissions)
Note:
Starting with the release of PI API 2016 for Windows Integrated Security, PI API supports
Windows authentication. Earlier versions of PI API do not support Windows
authentication. In those cases, PI API-based applications can authenticate only through a
PI trust or explicit login. Most interfaces are PI API-based.

• Products that connect through a trust
• Products that connect to an application server
• Administrative client applications
Products that connect through a trust

Prior to the availability of PI API 2016 for Windows Integrated Security, most interfaces
connected to PI using a PI trust. Client applications also connected through a PI trust due to
Windows authentication not being supported through PI API.
If you upgrade to PI Server 3.4.380 or later, your existing PI trusts continue to work. The
exception is that custom applications might have been accessing the PI Data Archive server
through wrongly-configured trusts and might no longer be able to connect. See Check for
unauthenticated PI API connections for more information.
Starting with the availability of PI API 2016 for Windows Integrated Security, support for
Windows authentication is extended to all PI API-based client applications, including all
Windows-based PI interface. Linux or UNIX-based interfaces are NOT supported. As a result, if
your PI API-based application supports Windows Integrated Security, we recommend that you
upgrade to PI API 2016 for Windows Integrated Security, and upgrade your authentication
model to Windows authentication. This involves migrating any existing PI trusts to Windows
authentication. See Configure PI interface connections using PI mappings.

How will PI Server 3.4.380 affect my clients and interfaces?
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 in PI SMT.
You will need to configure appropriate access permissions. Typically, for all relevant points, a PI
interface needs:
• Write access for point data

• Read access for point configuration
• Read access to PIPOINT in the Database Security window of PI SMT, unless the interface
supports point creation, in which case it needs read/write access
Note:
In previous versions of the PI Data Archive server, you could not define a PI trust against
a PI group. This restriction no longer applies. For PI Server 3.4.380 and later, you can
define a PI trust against a PI identity, a PI user, or a PI group.
If you are implementing a new PI System using PI Server 3.4.380, we recommend that you
follow the instructions in Configure PI interface connections using PI trusts.
Check for unauthenticated PI API connections

Previous versions of the PI Data Archive server allowed unauthenticated PI API applications to
connect to the PI Data Archive server with world access. In previous versions of the PI Data
Archive server, you could explicitly close this security hole by using the DefaultUserAccess
tuning parameter. PI Server 3.4.380 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 PI Data Archive server.
In most cases, the closing of this security hole should not cause you a problem. Since world
access is usually read-only, your PI interfaces are unlikely to be relying on this access. However,
if you have custom PI API applications, you might find that they were not configured properly
and now no longer have access. You must configure valid PI trusts for those applications.
To identify PI API applications that are not connecting properly, check the PI Data Archive
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 PI API
Connection"
You can filter these unique message IDs in the PI SMT Message Logs tool.
Products that connect to an application server

Certain PI client applications require a connection to a separate application server in addition
to a PI Data Archive server. Examples include PI DataLink Enterprise Server (PI DLES) and PI
WebParts. These types of applications require additional configuration steps if you want to use
the new security features.

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 PI Server 3.4.380
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 PI SMT, Point Builder, Module Database Builder, and so on. When you upgrade to
PI Server 3.4.380, 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 PI Data Archive.
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 PI

Server 3.4.380 installation.

• Which administrative tools are compatible with PI Data Archive
• How to maintain backwards-compatible access permissions
Which administrative tools are compatible with PI Data Archive

To work with access permissions for PI Server 3.4.380 or later, run SDK 1.3.6 or later and use
the following administrative tools:
• PI SMT version 3.3.1.3 or later (includes Point Builder, Module Database tool, and Database
Security tool)
• PI Builder
• 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
How to maintain backwards-compatible access permissions

On previous versions of the PI Data Archive 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 PI Data Archive 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.
Change names of PIUserIncompatible and PIGroupIncompatible

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

How will PI API 2016 for Windows Integrated
Security affect clients and interfaces?
Windows Integrated Security is the recommended security model for PI Data Archive server
and clients, including PI interfaces. All PI Server 3.4.380 or later support Windows Integrated
Security for the server side. For PI API-based client applications, extending this security model
involves upgrading to PI API 2016 for Windows Integrated Security.
• When should I upgrade to PI API 2016 for Windows Integrated Security?

You should upgrade if your client supports Windows authentication.
• When should I not upgrade my PI API?

You should defer PI API 2016 upgrade if your Windows platform is unable to meet
minimum requirements or if you need more time to verify compatibility with a custom PI
API application.
• What are the requirements to upgrade to PI API 2016 for Windows Integrated
Security?
The account that is running the API must be able to generate a Windows login context that
can authenticate with the PI Data Archive computer. Note the computer running the API
application does not need to be a member of a domain. Separate credentials can be stored in
Windows Credential manager to authenticate with the PI Data Archivecomputer when the
API is running on a workgroup computer.
• I am not upgrading my PI API. However, I want to upgrade my PI Data Archive

to 3.4.395. Will upgrading my PI Data Archive server affect my existing PI
trusts?
There is no effect on your existing PI trusts, and they authenticate as normal. If, additionally,
you upgrade to PI API 2016 for Windows Integrated Security, then your existing PI trusts
will not work as expected. This is because PI trusts are not supported once PI API is
upgraded to PI API 2016 for Windows Integrated Security.

How will PI API 2016 for Windows Integrated Security affect clients and interfaces?

MDB to AF security synchronization considerations
On PI Server 2010 (PI Data Archive 3.4.385) and later, PI Module Database (MDB) is
automatically synchronized with PI Asset Framework (AF). If MDB is enabled, this
synchronization is mandatory. PI Server 2010 includes a new subsystem (the PI AF Link
Subsystem) that performs the synchronization.
Both PI AF and PI Data Archive 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 PI AF,
potentially causing access problems for users. See the PI MDB to AF Transition Guide for details
about synchronization.
To minimize security synchronization problems, follow these guidelines:
• The PI Data Archive and PI 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 PI Database security are the same as the
access permissions on the PI Data Archive element in AF. You can edit the access
permissions on PIModules using the Database Security tool in PI SMT (Security > Database
Security).
• Use Windows authentication on the PI Data Archive 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 PI Data Archive 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 thePI Data Archive server. Thus, OSIsoft
recommends that you do not map piadmin and do not use it for routine access to the PI Data
Archive server. Reserve piadmin exclusively for the very few and rarely executed
administrative tasks that no other PI identity can perform.
• In AF, do not use deny access for any AF Element under the PI Data Archive element. AF
allows you to explicitly deny access, but the PI Data Archive server does not. If you use deny
on an element in AF, then everyone except piadmin will lose all access to the corresponding
module.

MDB to AF security synchronization considerations

Permissions required for tasks
The following table shows the permissions that are required for various tasks.
Task Database security permissions Permission required on the
target object
Archives: Backing up PIBACKUP (r,w)
Archives: Create / Register / PIARCADMIN (w)
Unregister, Force Shift, Online
Reprocessing
Archives: Listing, Activity Grid, PIARCDATA (r)
General Stats, Cache Stats
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 / PIUnit is a module; see
Delete / View PIUnit corresponding tasks for modules
Batch Database: Create / Edit / PIModules (r) PIUnit (r1,w) read and write
Delete PIUnitBatch, PISubBatch permission on the target PIUnit
Batch Database: Create / Edit / PIBatch (r,w)
Delete PIBatch
Batch Database: Create / Edit / PICampaign (r,w)
Delete PICampaign
Batch Database: Create / Edit / PITransferRecords (r,w) • If src or dest is type PIBatch,
Delete PITransferRecord you also need permissions for
the target batch database:
View PIBatch
• If src or dest is type
PIUnitBatch, you also need
permissions on the target
batch database: View
PIUnitBatch, PISubBatch
• If src or dest is type module,
you also need permission on
the target modules: View
Batch Database: Insert / Remove PIBatch (r,w) PIUnit (r1,w) read and write
PIUnitBatch into / from PIBatch permission on the target PIUnit
Batch Database: Insert / Remove PICampaign (r,w) PIBatch
PIBatch into / from PICampaign (r,w)
Batch Database: View PIModules (r) PIUnit (r1,w) read and write
PIUnitBatch, PISubBatch permission on the target PIUnit
Batch Database: View PIBatch PIBatch (r) If contains PIUnitBatches, also
need permission on the target


target object
Batch Database: View PICampaign (r) If contains PIBatches, also need
PICampaign permissions on the target batch
database: View PIBatch
Batch Database: View PITransferRecords (r) • If src or dest is type PIBatch,
PITransferRecords you also need permission on
the target batch database:
View PIBatch
• If src or dest is type
PIUnitBatch, you also need
permission on the target
• If src or dest is type module,
you also need permission on
the target modules: View
Batch Subsystem: Create / Edit / PIBATCHLEGACY (r,w) unit (r1,w) read and write
Delete units and batches permission on the target unit
Batch Subsystem: Create / Edit / PIBATCHLEGACY (r,w) Permission on the target points:
Delete aliases View attributes
Batch Subsystem: View units and PIBATCHLEGACY (r) unit (r1,w) read and write
batches permission on the target unit
Batch Subsystem: View aliases PIBATCHLEGACY (r) Permission on the target points:
View attributes
Database Security Table: Edit PIDBSEC (r,w) Database security (w), write
permission on the target
database
Database Security Table: View PIDBSEC (r)
Digital State Sets: Create / Edit / PIDS (r2,w)
Delete digital sets or states
Digital State Sets: View digital PIDS (r2)
sets or states
Event Queue: Configure PITUNING (r,w)
Firewall: Configure PITUNING (r,w)
HA: Create / Configure a PI Data PIREPLICATION (r,w)
Archive collective PIBACKUP (r,w)
Heading Sets: Create / Edit / PIHeadingSets (r3,w) heading set (r,w) read and write
Delete heading set permission on the target heading
set
Heading Sets: Create / Edit / PIHeadingSets (r3,w) heading set (r,w) read and write
Delete heading permission on the target heading
set, heading (r,w) read and write
permission on the target heading
Heading Sets: View heading set PIHeadingSets (r3) heading set (r) read permission
on the target heading set


target object
Heading Sets: View heading PIHeadingSets(r3) heading set (r) read permission
on the target heading set,
heading (r) read permission on
the target heading
Identities, Users, and Groups: PIUSER (r,w)
Create / Edit / Delete
Identities, Users, and Groups: PIUSER (r)
View
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 (r1,w) read and
write permission on the parent
module
Modules: Delete PIModules (r,w) parent module (r1,w) read and
write permission on the parent
module, module (r1,w) read and
write permission on the target
module
Modules: Edit PIModules (r) module (r1,w) read and write
permission on the target module
Modules: Edit – Link / Unlink PIModules (r) new parent module (r1w) read
and write permission on the new
parent module, module (r1w)
read and write permission on the
target module
Modules: Edit – Add / Remove PIModules (r) module (r1w) read and write
alias permission on the target module,
permission on target point: View
attributes
Modules: Edit – Add / Remove PIModules (r) module (r1w) read and write
heading permission on the target module,
permission on the target Heading
Sets: View heading
Modules: View PIModules (r) module (r1), read permission on
the target module
Points: Create PIPOINT (r,w)
Points: Delete PIPOINT (r,w) PtSecurity (r,w) read and write
permission on the target point's
PtSecurity attribute
Points: Edit attributes PIPOINT (r) PtSecurity (r,w) read and write
permission on the target point's
PtSecurity attribute


target object
Points: Edit DataSecurity PIPOINT (r) PtSecurity (r,w) read and write
attribute permission on the target point's
PtSecurity attribute,
DataSecurity (w) write
permission on the DataSecurity
attribute
Points: Add / Edit / Remove data PIPOINT (r) PtSecurity (r) read permission
on the target point's PtSecurity
attribute, DataSecurity (r,w) read
and write permission on the
DataSecurity attribute
Points: View attributes PIPOINT(r) PtSecurity (r) read permission
attribute
Points: View data PIPOINT(r) PtSecurity (r) read permission
attribute, DataSecurity (r) read
permission on the DataSecurity
attribute
Trusts: Create / Edit / Delete PITRUST (r,w)
Trusts: View PITRUST (r)
Tuning Parameters (Timeout PITUNING (r,w)
Table): Create / Edit / Delete
Tuning Parameters (Timeout PITUNING (r)
Table): View
1
module (r) / PIUnit (r) also assumes read permission for all modules in the hierarchy path above it
2
PIDS (r) is implicitly granted by PIPOINT (r)
3
PIHeadingSets (r) is implicitly granted by PIModules (r)

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 PI clients,
data access products, and/or interfaces.
In some cases, these product permission tables are followed by additional information
regarding related configuration issues.
AF 2.x Client
Database Security Permission Notes
PIDS r
PIPOINT r,w
Point Database Permission Notes

PtSecurity r,w w: only necessary for autocreate
option of PI PointData Reference
DataSecurity r,w w: only if writing data to PI
AF 1.3 Server
PIDS r
PIModules r,w
PIPOINT r,w not required for SQL backend

PtSecurity r,w not required for SQL backend
DataSecurity r,w not required for SQL backend
Module Database Permission Notes

Module Security1 r,w both SQL and non-SQL backends
require access
1
Generic client application permissions that can operate on any module

Product access permissions reference and configuration issues
AF 1.3 Client
PIDS r
PIModules r
PIPOINT r,w w: only necessary for autocreate

PtSecurity r,w w: only necessary for autocreate
DataSecurity r,w w: only if writing to PI

Module Security1 r
1
DataSheet Control
PIUSER r
PIBatch r,w w: to create PIBatches, and to
insert PIUnitBatches into
PIBatches
PIModules r
PIPoint r

PtSecurity r
DataSecurity r,w w: to edit point data

Module Security1 r,w w: for PIUnits to create
PIUnitBatches and insert
PIUnitBatches into PIBatches
1
PI groups and DataSheet Control

Some features of the DataSheet Control are tied to PI groups. Specifically, some regulatory
features let you limit the ability to commit and confirm manually entered data to a user-
specified PI group. You can limit commit functionality to one PI group, and limit confirm

functionality to a different PI group. Users who do not belong to the specified regulatory user
groups within the DataSheet Control receive an error that indicates they do not have the
required permissions to commit or confirm data. See the DataSheet Control User Guide for more
information.
PI Server 3.4.380 continues to support PI groups for backwards compatibility. See What about
PI users and PI groups? for more information.
PI ACE
PIModules r1,w2,3,4
PIPoint r1,w
PIDS r
PIMSGSS r1,w2
PIDBSec r2,3,4,5

PtSecurity r1,w 5
DataSecurity r1,w2

Module Security6 r1,w2,3,4
1
In order for PI ACE Manager to look at ACE configuration, read permission is required for PIPoint and PIModules, as well as
on the Module Database.
2
PI ACE schedulers/hosts have two types of connection to the PI Data Archive 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 PI ACE modules. Typically, a PI trust has to be setup for the PI API connection while the PI SDK connection can be
mapped to a Windows user. If PI ACE scheduler/host is running on a PI Data Archive server, it needs read/write permission to
the PIMSGSS to log messages.
3
Users of PI ACE Manager who configure and manage PI ACE calculations need read/write permission to PIModules. Most of
the tasks in PI ACE Manager only require read permission to the PIPoint table. Item 5 below describes the exception.
4
Users developing PI ACE calculations using the PI ACE wizard in a MS Visual Studio environment need read/write permission
to PIModules, and read permission to the data source tags, including the PIDS table.
5
PI 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.
6

PI BatchView
PIBatch r r: to execute PIBatch queries,
retrieve anchored PIBatch
records, and detect updates to
PIBatch records
PIDS r r: to display tag data in the batch
trend
PIModules r r: required for all of the
following:
+ to access the unit properties
associated with the PIUnitBatch.
Both the Gantt and Results
require read access to show unit
name and heading properties.
+ to resolve aliases to a tag (for
the trend).
+ to execute queries for
PIUnitBatch records on a
particular unit
+ to detect updates to
PIUnitBatch and PISubBatch
records (to reflect on the results,
Gantt and Trend)
PIPOINT r r: to show any traces on the

Batch Trend

PtSecurity r
DataSecurity r

Module Security1 r same as for PIModules Database
Security
1
Security configuration for PI BatchView

PI BatchView requires two types of security.
Point Database security

Read access is required to DataSecurity and PtSecurity for all tags used by PI 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 PI Data Archive 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 PI 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 PI BatchView. This may be desirable since the PI 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 PI 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).
PI DataLink
PIModules r
PIPOINT r

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

Module Security1 r
1

PI DataLink Server (PI DLES)

PIBatch r
PIHeadingSets r
PIModules r
PIPOINT r

PtSecurity r
DataSecurity r

Module Security1 r
1
Security configuration for PI DLS

If you are configuring a PI Data Archive server to use Windows Active Directory (AD) for
authentication, then you need to perform some additional configuration steps to use PI
DataLink Server (PI DLS).
Specifically, you need to configure the SharePoint Server for Kerberos delegation. Kerberos is a
secure type of authentication used by AD. If a PI Data Archive server is configured for AD
authentication, but Kerberos delegation is not configured on the SharePoint Server, then PI DLS
returns the following error message:
No PI user was recorded for a trusted connection.
For more details, see "Kerberos authentication for PI DataLink Server" in Live Library (https://
livelibrary.osisoft.com).
PI Manual Logger
PIModules r In version 2.x or greater
PIHeadingSets r In version 2.x or greater
PIPOINT r
PIUSER r

PtSecurity r
DataSecurity r,w


Module Security1 r In version 2.x or greater
1
Configuring security for PI Manual Logger

In PI Manual Logger (PI-ML) version 2.2.x or prior, certain security checks were being
performed within PI-ML itself outside the PI Data Archive server. Because of these extra checks,
such older versions of PI-ML should connect to the PI Data Archive server solely via a PI trust
to a PI user. For details, see Create a trust.
Furthermore, these extra security checks require that all tags accessed by PI-ML 2.2.x remain
backwards-compatible. For more information, see How to maintain backwards-compatible
access permissions.
If access is not configured correctly, you receive the following error when writing data to the
tags included in the tour:
You do not have permission to write the manual data to PI at this moment.
Cannot write to tag ' <tagName>'
Your PI configuration does not allow you to write manual data to PI.
In PI-ML 2.3, the security checks within PI-ML itself have been removed, and PI-ML now relies
solely on the PI Data Archive server for its security. Thus, PI-ML 2.3 can fully leverage all the
new security features of thePI Server 3.4.380 server.
PI Notifications
Note:
This topic pertains to the legacy product. Prior to PI AF 2016 R2, PI Notifications was the
system component that built and maintained notifications. PI AF 2016 R2 and later
versions include notifications as a feature; it is no longer installed as a separate
component. The last version of PI Notifications was PI Notifications 2012. For more
information on current version of notifications, see the PI Server topic " Notifications" in
Live Library (https://livelibrary.osisoft.com).

PIDS r1
PIPOINT r1,w2
PIMSGSS r,w2

PtSecurity r1,w2
DataSecurity r1,w2
1
Read permission for PI Notification client (e.g. PI System Explorer) is required to the PIDS and PIPoint tables as well as to the
data source tags and notification history tags.
2
PI Notification schedulers/processors have two types of connection to the PI Data Archive 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 PI trust for the PI API connection
while the PI SDK connection can be mapped to a Windows user. If the PI Notification scheduler
and processors are running on a PI Data Archive server, then they also need read/write
permission to PIMSGSS for error message logging.
Developer Technologies
PI OLEDB Provider
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 PI OLEDB
PITransferRecords r,w r,w: to query pibatch..pitransfer
or pibatch..pitransferproperty
tables
PIUSER r,w r,w: to query any table in the
piuser catalog

PtSecurity r,w
DataSecurity r,w

Module Security1 r,w
1
Configuring security for PI OPC DA Server

The PI OPC DA Server connects to a PI Data Archive server using both the PI SDK 2016 and PI
API 2016 for Windows Integrated Security. PI SDK and PI API are used to read from and write
to the PI Data Archive server.
PI OPC DA Server 2015 and later connects to PI Data Archive using PI AF SDK. PI AF SDK fully
supports Windows Integrated Security (WIS), which provides security over the connection to
PI Data Archive. WIS can be configured for PI Data Archive using PI System Management tools,
including mapping the Windows identity (account/group) to the appropriate PI identity.

Determining which Windows identity to map depends upon how PI OPC DA Server is launched,
as follows:
• PI OPC DA Server is launched as a Windows Service - In this configuration, all access to PI

Data Archive is granted using the Windows identity configured for the service. The
Windows identity of the OPC DA client application is not considered.
• PI OPC DA Server is launched as a process launched by the OPC DA client - By default, all
access to the PI Data Archive is granted using the Windows identity of the user launching
the OPC DA client application. This Windows identity can be changed using the Windows
DCOM Configuration Utility.
Note:
Note: PI OPC DA Server 2010 and earlier used both the PI SDK and PI API. OSIsoft
recommends upgrading to the current release of PI OPC DA Server to improve security.
The following connection options are available for the PI OPC DA Server:
• [Recommended] Connect to the PI Data Archive server via Windows Security with a PI
identity. The requirement for this option is to either use PI SDK or update PI API to PI API
2016 for Windows Integrated Security, as well as replacing any PI trusts with PI mappings
to your PI Identities. This option provides the best security measures between the PI Data
Archive server and the PI OPC DA Server.
• Connect to PI Data Archive server using both a PI trust and Windows Security. Set up a trust
for either the PI API connection or PI SDK connection, and use Windows Security for the PI
SDK connection or PI API 2016 for Windows Integrated Security connection. This option is
only recommended if Windows authentication is not feasible for your deployment. It is
slightly more secure than using PI trusts exclusively.
• Connect to the PI Data Archive server via a PI trust set up with a PI identity. This option is
only recommended if Windows authentication is not feasible for your deployment. It is least
secure option available between the PI Data Archive server and the PI OPC DA Server.
Configuring security for PI OPC HDA Server

The PI OPC HDA Server connects to a PI Data Archive server using both the PI SDK and PI API.
The PI SDK is used to read data from the PI Data Archive server, and the PI API is used to write
data to the PI Data Archive server.
The following connection options are available for the PI OPC HDA Server:
• [Recommended] Connect to the PI Data Archive server via Windows Security with a PI
identity. The requirement for this option is to update PI API to PI API 2016 for Windows
Integrated Security, as well as replacing any PI trusts with PI mappings to your PI Identities.
This option provides the best security measures between the PI Data Archive server and the
PI OPC HDA Server.
• Connect to PI Data Archive server using both a PI 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 only recommended if Windows authentication is not feasible for your deployment. It is
slightly more secure than using PI trusts only.
• Connect to the PI Data Archive server via a PI trust set up with a PI identity. This option is
only recommended if Windows authentication is not feasible for your deployment. It is least
secure option available between the PI Data Archive server and the PI OPC HDA Server.

PI ProcessBook
PIBatch r
PICampaign r
PIDBSEC r
PIDS r
PIHeadingSets r
PIModules r
PIPOINT r,w1 r,w: to use the annotation feature
of the PI ProcessBook Details
add-in
PITransferRecords r
PIUSER r

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

Module Security2 r
1
Write access not required if you have PI SDK 1.4 or later installed
2
Note:
PI ProcessBook displays that contain custom VBA code might require additional security
configuration depending on what PI SDK calls are invoked.
RtAlerts
PIDS r
PIModules r,w
PIPOINT r

PtSecurity r
DataSecurity r


1
RtReports Server (to PI Data Archive)

PIBatch r
PIModules r,w RtReports creates and writes to
PI modules for application data
(by default, under \%OSI
\RtReports)
PIMSGSS r,w r,w: to write to the PI Data
Archive message log
PIPOINT r,w r: in RtReports Server 3.1.1 and
prior r,w: in 3.2 and later,
RtReports creates tags to store
report comments

PtSecurity r,w r: in RtReports Server 3.1.1 and
RtReports maintains tags to store
report comments
DataSecurity r,w r: in RtReports Server 3.1.1 and
RtReports annotates tags to store
report comments

Module Security1 r r,w: required for the \%OSI
\RtReports node of the MDB to
read or write application data
(report templates, RtReports
app-level security)
1
RtReports Editor (to PI Data Archive)

PIBatch r
PIModules r
PIPOINT r


DataSecurity r

Module Security1 r
1
Configuring security for RtReports

While RtReports allows you to configure permissions access for various user types, it does not
depend on the PI Data Archive server, which contains the RtReports data to administer these
permissions.
Rather, all requests from RtReports users to the PI Data Archive server containing RtReports
data are channeled through a single PI trust connection (defined as RtReports Server (to PI
Data Archive)). For versions 3.1.1 and earlier, this PI trust must have read/write access to the
Module Database, as well as read access to the point database on the PI Data Archive server.
For version 3.2, the trust must also have read/write access to the point database to store report
properties in tag annotations.
In addition, the RtReports Server accesses the PI Data Archive server when generating a report.
This access is read-only to both the point and module databases.
Most PI access via the RtReports Editor is accomplished via web service calls to the RtReports
Server trusted connection described above. However, the Editor also has its own read-only
connection to the PI Data Archive server defined when running test reports (defined as
"RtReports Editor" above). This PI Data Archive server is the one defined by the currently-
tested report template.
PI WebParts and PI Web Services

PIBatch r
PIDBSEC r
PIHeadingSets r
PIModules r,w r: for PI Data Services ProcessID
w: for an administrator UserID to
make configuration changes
PIPOINT r
PIUSER r

PtSecurity r


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

Module Security1 r,w r: for PI Data Services ProcessID
w: for an administrator UserID to
make configuration changes
1
Configuring security for PI WebParts and PI Web Services

Security for Developer Technologies PI WebParts and PI Web Services, or other products that
use the PI 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 PI 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 PI Data Archive
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:
• In PI WebParts, open the PI Data Services Administration page and click the PI Data Services
link in the Version Information section to review the user mapping and the process mapping
found in the Server Machine Information section.
• If you are using PI Web Services, open IIS Manager and select the Application Pools node to
view the Windows identity that is used. Then, use PI 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. OSIsoft 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 PI Data Archive if you
are using PI Web Services, or between the SharePoint Server and PI Data Archive if you are
using PI WebParts.
• The client machine must belong to the same Active Directory forest.
For instructions on setting up the Kerberos environment, see the PI WebParts topic
"Configuration of Kerberos delegation" in Live Library (https://livelibrary.osisoft.com).
Note:
If membership in an AD group used in a PI mapping is modified, or if a relevant PI
mapping itself is modified, you might need to restart IIS.

Interfaces
This section provides access permissions required for PI interfaces.

• Interfaces that create points
• PI to PI TCP/IP Interface
• PI Interface for OPC DA
• PI Interface for OPC HDA
• PI APS
• PI ICU
Interfaces that create points

PIPOINT r,w1 r,w: for any interface that creates
or deletes points
1
Interfaces with separate utilities that create points (for example, PI-Perfmon, PI-Ping, SNMP, etc.) and run from PI SMT only
require that you have read access for PIPOINT.

PtSecurity r,w
DataSecurity r,w
PI to PI TCP/IP Interface
Database Security Source PI Data Archive Receiving PI Data Notes
Server Archive Server
PIPOINT r r
Point Database Source PI Tags Receiving PI Tags Notes

PtSecurity r r
DataSecurity r r,w
PI Interface for OPC DA

PIPOINT r


PtSecurity r
DataSecurity r,w
PI Interface for OPC HDA

PIPOINT r

PtSecurity r
DataSecurity r,w
PI APS
Database Security PI APS Sync Engine Sync Trigger PItoPI_APS
Configuration
Utility
PIDS None for read-only r,w: for automatic r
mode; r,w: to set/state creation
interactively create and edits (for
or edit digital sets/ digital points);r:
states(for digital for non-automatic
points) modes
PIModules r: to review APS r,w r,w
configuration; r,w:
to change APS
configuration
PIPOINT None for read-only r,w: for automatic r
mode; r,w: to point creation;r:
interactively create for non-automatic
or delete points modes
Point Database PI APS Sync Engine1 Sync Trigger2 PItoPI_APS3

Configuration
Utility
PtSecurity r: to display r,w: to r
existing interface automatically edit
points;r,w: to or delete points; r:
interactively edit for non automatic
or delete interface modes
points
DataSecurity

Module Database PI APS Sync Engine Sync Trigger PItoPI_APS

Configuration
Utility
Module Security4 r: to review APS r,w r,w
configurationr,w:
to change APS
configuration
1
The Synchronization Engine runs as a service and therefore requires some form of automatic log on (either a PI trust or new
PI mapping).
2
Synchronization Trigger is also a service and therefore requires some form of automatic log on. Without write permission for
the Module Database, Synchronization Trigger is non-functional. Synchronization Trigger only uses the Module Database (no
point access).
3
The PItoPI_APS Connector requires read permission to points on the source PI Data Archive server. Since PIAPS Connectors
run inside the Synchronization Engine process, which is a service, some form of automatic log on to the source PI Data Archive
server is required. That is, the Synchronization Engine that is running the PItoPI_APS Connector requires automatic log on to
two PI Data Archive servers: the target PI Data Archive server and the source PI Data Archive server. The method of connection
and the access rights granted do not need to be the same for both PI Data Archive servers. The Synchronization Engine only
needs read access to the PIPOINT and PIDS tables on the source PI Data Archive 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 PI Data Archive server. For non-automatic modes, only read access is needed (on the target PI Data
Archive server).
4
Configuring security for PI APS

In order to run PIAPS, you must configure the PIServer to allow connections from the PIAPS
Configuration Utility, PIAPS Synchronization Engine, and PIAPS Synchronization Trigger
service. This section discusses the information that you need to configure:
• Connection methods for the PIAPS programs, and

• PIServer security to grant the required access rights to these connections.
Note:
A copy of PIAPS on the PIServer node does not require any security configuration in the
PIServer, however OSIsoft discourages using PIAPS on the PIServer node except to
synchronize points for PI COM Connectors.
The PIAPS Synchronization Engine and PI APS Synchronization Trigger service are both
Windows services. You need to set up either a PI trust or a PI mapping to connect each of them
to the PI Data Archive server. The PIAPS Configuration Utility is an interactive application, so
you can use a PI mapping or PI trust to a PI Data Archive server User account. PI mappings are
the most secure option; PI trusts are the least secure. Use PI mappings where possible (PI
mappings require PI Data Archive version 3.4.380 and PI SDK 1.3.6 or later).

Note:
PI API 2016 for Windows Integrated Security does not support PI trusts, requiring that
you use PI mappings to connect with the PI Data Archive server.
PI mappings for Windows services

By default, PI APS services log on as the Local System account, which cannot be used for PI
mappings on a remote PI Data Archive server. In order to create a PI mapping, you must first
change the PI 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 PIAPS Configuration Utility creates the module AutoPointSync under the %OSI module.
PIAPS configuration settings are stored in a hierarchy of modules under this module. Other
information also is stored in the modules used by PIAPS. For example, the last synchronization
time (stored by the PIAPS Synchronization Engine) and the SyncImmediately flag (set by the
PIAPS Synchronization Trigger service or PIAPS Configuration Utility) are stored in the
AutoPointSync hierarchy.
The PIAPS 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 PIAPS, to
change configuration settings, or to manually initiate a synchronization scan. Read access is
sufficient to view configuration settings.
The PIAPS Synchronization Engine and PIAPS Synchronization Trigger service require write
access for modules in the AutoPointSync hierarchy for normal operation.
Point Database permissions

To create or delete points, the PIAPS Synchronization Engine or PIAPS Configuration Utility
requires write access for the PIServer PIPOINT table. To edit points, the PIAPS Synchronization
Engine or PIAPS Configuration Utility requires write access for individual points.
The PIAPS Synchronization Trigger service does not access the PIServer point database.
PI 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. PIAPS needs write access for point
attributes of the points that are associated with interface instances registered for
synchronization.
PIAPS does not access point data.
Digital State Table permissions

To create digital sets, the PIAPS Synchronization Engine or PIAPS Configuration Utility requires
write access for the PIServer digital state table (PIDS in Database Security). The PIAPS
Synchronization Trigger service does not access the PIServer digital state table.

PI ICU
PIDS r,w w: to create "InterfaceStatus"
digital set if it does not exist
PIModules r,w
PIPOINT r,w w: to create or delete Perfmon
Performance Counter Points,
UniInt Performance Points, or
UniInt Health Points

PtSecurity r, w

1
Configuring PI ICU
When PI ICU is installed on an interface node, the PI ICU obtains permissions to access PI Data
Archive objects by logging on with some form of credentials. The PI Data Archive 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 PI Data Archive
object has access control information. Authorization for a client program to access a securable
PI Data Archive 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
• PI trust
• PI mapping (requires PI Server version 3.4.380 or later and PI SDK 1.3.6 or later)
The PI ICU is an interactive application and all the methods for logging on to the PI Data
Archive server can be used.
If the PI Server server is version 3.4.380 or later, OSIsoft recommends using Windows security
through PI mappings. Windows security provides the strongest authentication and full
Windows account traceability in the PI Data Archive log and audit trail records.
Module Database Permission

The PI ICU creates the module interfaces under the %OSI module. PI ICU configuration settings
are stored in a hierarchy of modules under the interfaces module.
The PI 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 PI ICU and to
change configuration settings
Digital State Table Permissions

When PI ICU starts, it checks for the existence of a digital set named InterfaceStatus. If this
digital set does not exist, PI ICU requires write access for the PI Data Archive digital state table
(PIDS in Database Security) to create the InterfaceStatus digital set.
When UniInt Failover is configured for an interface instance, PI 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,
PI ICU requires write access for the PI Data Archive 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 PI ICU process, PI ICU requires write access to the PI Data
Archive 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.
Point Database Permissions

PI ICU can create, edit, or delete the following types of points that are common to UniInt-based
interfaces:
• PI Perfmon Performance Counter Points

• UniInt Performance Points
• UniInt Health Points
To create or delete these types of points, PI ICU requires write access for the PI Data Archive
PIPOINT table (Database Security).
To edit or delete individual points of these types, PI ICU requires write access for each point. PI
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. PI ICU needs write access for point attributes of
these types of points. PI 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 PI ICU manages. Since ICU Controls run inside the PI ICU
process, the PI ICU requires write access for the PI Data Archive PIPOINT table for an ICU
Control to create points.


Checklist: Configure Windows authentication for
upgrades
This table lists the basic steps for configuring an upgraded PI Data Archive server for Windows
authentication.
Step Notes
Review existing access permissions See Review access permissions
Create a list of unique access strings See Create a list of unique access strings
Identify PI groups and PI users that will be See Create a configuration plan
retained
Create new identities to fill gaps See Create PI identities to fill gaps
If using AD, determine which AD groups are (AD only) See Review AD groups
needed and which identities to map them to
If using local Windows security, determine which (only if using local Windows security)
local Windows groups are needed and which
identities to map them to
If using local Windows security, configure (only if using local Windows security)
matching Windows user accounts and passwords
on PI Data Archive server and client workstations
Create mappings See Create mappings in SMT
Verify configuration See Verify initial configuration
Check custom PI API applications, if any (if any) See Check for unauthenticated PI API
connections
Upgrade PI SDK to 1.3.6 or later on client (required for Windows authentication)
computers
Upgrade PI API to PI API 2016 for Windows (required for Windows authentication)
Integrated Security on client computers
Configure clients that connect through an (if any) See Products that connect to an application
application server (for example, PI DLES and PI server
WebParts)
Upgrade administrative applications: See Administrative client applications
• PI SMT version 3.3.1.3 or later
• PI Builder
• Module Database Builder version 1.2.1.3 or
later
Disable explicit logins (Optional) See Disable PI password authentication
(explicit logins)
Replace SDK trusts with PI mappings (Optional) See Retire SDK trusts
Retire obsolete PI users and PI groups (Optional)

Checklist: Configure Windows authentication for upgrades

Checklist: Configure Windows authentication for new
installations
This table lists the basic steps for configuring a new PI Data Archive server for Windows
authentication.
Step Notes
Identify user access categories Identify user access categories
Create a PI identity for each access category (you Create PI identities
can also use built-in identities, users, or groups,
such as piadmins)
If using AD, determine which AD groups are (if using AD) See Review AD configuration
needed and which identities to map them to
If using local Windows security, determine which (only if using local Windows security) See
local Windows groups are needed and which Configure Windows groups
identities to map them to
If using local Windows security, configure (only if using local Windows security) See Use
matching Windows user accounts and passwords local Windows security or Use local Windows
on PI Data Archive server and client workstations security with AD
Create the mappings for AD: Map AD groups to PI identities
for local Windows security: Create mappings
Configure access permissions Configure access permissions

Configure authentication for interfaces Configure PI interface connections using PI trusts
Check custom PI API applications, if any (only for installations with existing clients &
interfaces) See Check for unauthenticated PI API
connections
Upgrade PI SDK on client computers to 1.3.6 or (only for installations with existing clients &
later interfaces; required for Windows authentication)
Upgrade PI API to PI API 2016 for Windows (required for Windows authentication)
Integrated Security on client computers
Configure clients that connect through an (if any) See Products that connect to an application
application server (for example, PI DLES and PI server
WebParts)
Upgrade administrative applications: (only for installations with existing clients &
• PI SMT version 3.3.1.3 or later interfaces) See Administrative client applications
• PI Builder
• Module Database Builder version 1.2.1.3 or
later
Disable explicit logins (Optional) See Disable PI password authentication
(explicit logins)

Checklist: Configure Windows authentication for new installations

Technical support and other resources
For technical assistance, contact OSIsoft Technical Support at +1 510-297-5828 or through the
OSIsoft Customer Portal Contact Us page (https://customers.osisoft.com/s/contactus). The
Contact Us page offers additional contact options for customers outside of the United States.
When you contact OSIsoft Technical Support, be prepared to provide this information:
• Product name, version, and build numbers
• Details about your computer platform (CPU type, operating system, and version number)
• Time that the difficulty started
• Log files at that time
• Details of any environment changes prior to the start of the issue
• Summary of the issue, including any relevant log files during the time the issue occurred
To ask questions of others who use OSIsoft software, join the OSIsoft user community,
PI Square (https://pisquare.osisoft.com). Members of the community can request advice and
share ideas about the PI System. The PI Developers Club space within PI Square offers
resources to help you with the programming and integration of OSIsoft products.

Technical support and other resources

PI Data Archive 2018 SP3 Security Configuration Guide EN

Uploaded by

Copyright:

Available Formats

You might also like

PI Data Archive 2018 SP3 Security Configuration Guide EN

Uploaded by

Document Information

Original Description:

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

PI Data Archive 2018 SP3 Security Configuration Guide EN

Uploaded by

Copyright:

Available Formats

PI Data Archive

Security Configuration Guide

Included with PI Server 2018 SP3

PI Data Archive Security Configuration Guide

Introduction to PI Data Archive security...................................................................... 3

Configuring security on a new PI Data Archive installation...........................................13

PI interface connections through PI API..................................................................... 35

Configuring security for PI Data Archive upgrades.......................................................51

Security for PI Data Archive collectives...................................................................... 63

PI Data Archive Security Configuration Guide iii

How will PI Server 3.4.380 affect my clients and interfaces?......................................... 75

MDB to AF security synchronization considerations....................................................81

Permissions required for tasks...................................................................................83

Product access permissions reference and configuration issues....................................87

iv PI Data Archive Security Configuration Guide

PI WebParts and PI Web Services.................................................................................................................. 98

Checklist: Configure Windows authentication for upgrades....................................... 107

Checklist: Configure Windows authentication for new installations............................ 109

Technical support and other resources..................................................................... 111

PI Data Archive Security Configuration Guide v

vi PI Data Archive Security Configuration Guide

PI Data Archive Security Configuration Guide 1

2 PI Data Archive Security Configuration Guide

Topics in this section

A brief look at PI Data Archive security

Topics in this section

How the security model has changed

Topics in this section

PI Data Archive Security Configuration Guide 3

◦ Interface node and PI Data Archive on the same computer

4 PI Data Archive Security Configuration Guide

◦ Interface node and PI Data Archive on untrusted domains

PI Data Archive Security Configuration Guide 5

What are PI identities and mappings?

6 PI Data Archive Security Configuration Guide

Topics in this section

What about PI users and PI groups?

PI Data Archive Security Configuration Guide 7

authentication is a weak form of authentication and should be avoided unless technically

Managing identities and PI mappings

8 PI Data Archive Security Configuration Guide

Built-in PI identities, users, and groups

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

PI Data Archive Security Configuration Guide 9

PI users, groups, and Description

The piadmin user

The piadmins group

10 PI Data Archive Security Configuration Guide

• All database security entries (in PI SMT)

The PIWorld identity

Why use Windows Integrated Security?

• Less work for PI Data Archive administrators

PI Data Archive Security Configuration Guide 11

• Single-sign on for users

◦ Control over server-side authentication policies

• More control over access permissions

12 PI Data Archive Security Configuration Guide

Topics in this section