Configuring PI Server Security

Version 3.4.380
OSIsoft, Inc. International Offices
777 Davis St., Suite 250 OSIsoft Australia
San Leandro, CA 94577 USA Perth, Australia
Auckland, New Zealand
Additional Offices OSIsoft Germany GmbH
Houston, TX Altenstadt, Germany
Johnson City, TN
OSIsoft Asia Pte Ltd.
Longview, TX
Mayfield Heights, OH Singapore
Philadelphia, PA OSIsoft Canada ULC
Phoenix, AZ
Montreal, Canada
Savannah, GA
Calgary, Canada
Sales Outlets/Distributors OSIsoft, Inc. Representative Office
Middle East/North Africa Shanghai, People’s Republic of China
Republic of South Africa OSIsoft Japan KK
Russia/Central Asia Tokyo, Japan
South America/Caribbean
Southeast Asia OSIsoft Mexico S. De R.L. De C.V.
South Korea Taiwan Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda.
Sao Paulo, Brazil

Contact and Support:

Main phone: (01) 510-297-5800
Fax: (01) 510-357-8136
Support phone: (01) 510-297-5828
Web site: http://www.osisoft.com
Support web site: http://techsupport.osisoft.com
Support email: techsupport@osisoft.com

Copyright: © 1992-2009 OSIsoft, Inc. 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, Inc.

OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, Sigmafine, Analysis Framework, IT
Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Data Services, PI Manual Logger, PI
ProfileView, PI WebParts, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of
OSIsoft, Inc. 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, Inc. license agreement and as
provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as applicable. OSIsoft, Inc.

Published: 9/22/2009
Table of Contents
Chapter 1 Introduction to PI Server Security .............................................................................. 1
A Brief Look at PI Server Security...................................................................................... 1
Why Use the New Security Model? .................................................................................... 9

Chapter 2 Configuring Security on a New PI Server Installation ............................................11

Quick-Start Configuration ................................................................................................. 11
Recommended Configuration .......................................................................................... 14
Other Security Configurations .......................................................................................... 24
Configure PI Interface Connections ................................................................................. 30

Chapter 3 Configuring Security for PI Server Upgrades .........................................................35

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

Chapter 4 Configuring Security on PI HA Collectives ............................................................. 47

Change the Lookup Failure Parameter ............................................................................ 48
Create a Mapping with a SID ........................................................................................... 49

Chapter 5 Tightening Security ................................................................................................... 51

Protect piadmin ................................................................................................................ 51
Disable PI Password Authentication (Explicit Logins) ......................................................52
Secure piconfig Utility ....................................................................................................... 54
Retire SDK Trusts ............................................................................................................ 54
Configure PI Firewall ........................................................................................................ 56
Disable PIWorld................................................................................................................ 57

Chapter 6 How Will PI Server 3.4.380 Affect My Clients and Interfaces? ..............................59
Products That Connect Through a Trust .......................................................................... 59
Products that Connect to an Application Server .............................................................. 60
Administrative Client Applications .................................................................................... 61

Appendix A Task-Based Access Permissions Reference .......................................................63

Appendix B Product Access Permissions Reference and Configuration Issues .................67

AF 2.x Client ..................................................................................................................... 68
AF 1.3 Server ................................................................................................................... 69
AF 1.3 Client ..................................................................................................................... 70
DataSheet Control ............................................................................................................ 71

Configuring PI Server Security iii

Table of Contents

PI ACE .............................................................................................................................. 73
PI BatchView .................................................................................................................... 74
PI DataLink ....................................................................................................................... 76
PI DataLink for Excel Services (PI DLES)........................................................................ 77
PI Manual Logger ............................................................................................................. 79
PI Notifications ................................................................................................................. 81
PI OLEDB ......................................................................................................................... 82
PI ProcessBook ................................................................................................................ 83
RtAlerts ............................................................................................................................. 84
RtReports Server (to configuration PI Server) ................................................................. 85
RtReports Editor (to PI Data Server) ................................................................................ 86
RtWebParts and RtBaseLine Services ............................................................................ 88
Interfaces .......................................................................................................................... 90

Appendix C New SMT Highlights ............................................................................................. 101

Appendix D Checklist: Configure Windows Authentication for Upgrades ..........................103

Appendix E Checklist: Configure Windows Authentication for New Installations .............105

Appendix F Technical Support and Resources ...................................................................... 107

iv
Chapter 1

Introduction to PI Server Security

PI Server 3.4.380 allows you to manage your PI Server authentication through Windows and
Microsoft Active Directory (AD). This model improves PI Server security, reduces your
management workload, and provides users a single-sign on experience.
• A Brief Look at PI Server Security (page 1)
• What are PI Identities and PI Mappings? (page 4)
• Why Use the New Security Model? (page 9)

Note: PI Server 3.4.380 continues to support previous PI Server security mechanisms. If

you decide not to use the new security model, then no action is required on your
part. If you do choose to keep your existing security configuration, you are free to
gradually migrate to the new security model at a later date.

A Brief Look at PI Server Security

Computer security has two parts: authentication (who is the user, and how do we confirm that
the user is really who he or she says?) and authorization (once we know who the user is, what
is that user allowed to do?).
The new PI 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

In PI Server 3.4.380, both the authentication and the authorization mechanisms are different
from the mechanisms in earlier versions of the PI Server. Although the old model continues
to be supported, the new mechanisms are more flexible, easier to manage, and more secure.
• Authentication (page 1)
• Authorization (page 4)

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

Configuring PI Server Security 1

Introduction to PI Server Security

• PI Trusts were typically used for PI Interfaces, which run unattended. Trust
authentication works by comparing the connection credentials of the connecting
application to the Trust records in the Trust Database. Human intervention is not required
at the time of connection.
• Users connecting to the PI Server through client applications were typically authenticated
through explicit logins, which means that the user logs on to the PI Server by typing in a
PI User name and password. Explicit logins have a number of drawbacks: they require
users to log in separately to Windows and to the PI Server; they require system managers
to maintain separate user accounts for every user on the PI Server; and they are not
especially secure.

2
 A Brief Look at PI Server Security

With PI Server 3.4.380, a third method of authentication becomes available: Windows

authentication. With this method of authentication, users log onto their Windows accounts
and are automatically authenticated on the PI Server. Rather than requiring individual user
accounts on the PI Server, in the new model you define user categories called PI Identities,
on the PI Server. You then create Mappings from groups of Windows users to the relevant
user categories. PI Identities and PI Mappings are new objects of the 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 Server. PI Trusts
are still the recommended method for authenticating most Interfaces. However, explicit
logins are not recommended. They are available to provide backward compatibility.

Configuring PI Server Security 3

Introduction to PI Server Security

Authorization
The new security model includes a much more flexible model for access permissions. In
previous versions of the PI 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 Server
object can have read and/or write permissions defined for any number of PI Identities.

What are PI Identities and PI Mappings?

PI Identities and PI Mappings are the central components of the new PI Server security
model. They determine which Windows users are authenticated on the PI 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 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 Server resource (such as a point or a
module). Instead, you create a PI Identity that has that access and then you create a PI
Mapping between the Windows user or group and that PI Identity.
Members of the Windows groups that are mapped to a PI Identity are automatically granted
the access permissions for that PI Identity. For example, in the following illustration, the PI
Identity called PIEngineers has read/write access to the data for the TestTag point. Because
the Active Directory (AD) group EngineeringTeam is mapped to PIEngineers, all the
members in that AD group get read/write permission for the point data.

4
 A Brief Look at PI Server Security

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

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

What about PI Users and PI Groups?

Previous versions of the PI 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
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 Server access permissions.
For backward compatibility, Groups and Users are still supported and the standard built-in
accounts (such as piadmin and pidemo) are still provided. This allows PI Servers upgraded
to 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.
In PI Server 3.4.380, Groups and 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,
and Groups tool. The Users and Groups tabs allow you to manage existing Users and
Groups just as you did in earlier versions of the PI Server.

Configuring PI Server Security 5

Introduction to PI Server Security

Managing Identities and PI Mappings

The PI System Management Tools (SMT) provides tools for configuring and managing PI
Identities and PI Mappings, as well as for other security components. SMT is included with
every PI Server installation.
To manage PI Identities, use the Identities, Users, & Groups tool in SMT. Identities, Users,
and Groups are shown in separate tabs by default; but you can display everything in one
single list, if you prefer (click the Options button to select display options).

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

To see what Identities you are currently connected as, look at the Connection Information at
the bottom left of the SMT. It displays your Windows user ID, followed by the list of your
Identities (and/or PI Users and Groups).

If you click on the Identities, it 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 Server through a Mapping.

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

6
 A Brief Look at PI Server Security

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

Built-in Identities, Users, and Groups

The PI Server includes several built-in Identities, Users, and Groups. The most important are:
• The piadmin User (page 8) for super-user access (a PI User account)
• The piadmins Group (page 8) for administrative access (a PI Group)
• The PIWorld Identity (page 8) for general access (a PI Identity)
The following table shows all the built-in PI Identities, PI Users, and PI Groups:
Name Description
piadmin A PI User with super privileges. The piadmin user always has complete
read/write access to all PI Server resources. You cannot modify the access
permissions for piadmin.
piadmins The piadmins group is a built-in PI Group intended to represent PI Server
administrators. This PI Group was called piadmin on previous versions of
the PI Server. This meant that these PI Servers had both a PI User called
piadmin and a PI Group called piadmin.
On new PI Servers, version 3.4.380 and later, piadmins is pre-configured
to have read and write access to all PI Server resources and default points.
For upgrades, piadmins does not have any pre-configured access
permissions. It has whatever permissions the piadmin Group had before
the upgrade.
PIOperators, These sample Identities have no pre-configured access permissions, so
PIEngineers, they don't really do anything. However, you can use them as a starting
and point, if you like. These sample PI Identities are completely configurable and
PISupervisors you are also free to delete them. These PI Identities are included only on PI
Servers 3.4.380 and later.
piusers The piusers group is a built-in PI Group with no pre-configured access
permissions.

PIWorld A PI Identity with default access permissions for read-only access to all 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 all PI Server databases and objects. All
authenticated PI Server users are given at least PIWorld privileges.
PIWorld is available only on PI Server version 3.4.380 and later.
You can rename the PIWorld Identity; however you cannot delete PIWorld.
You cannot map PIWorld to an AD group and you cannot use it in a trust.

Note: There is also a hidden user and a hidden group. PIUserIncompatible and
PIGroupIncompatible are used to display an owner and group in older
administrative tools that do not support Windows authentication. They do not
appear in the list of Identities by default. To show them, use the Options button.
These PI Identities are included only on PI Servers 3.4.380 and later. See
Administrative Client Applications (page 61) for more information.

Configuring PI Server Security 7

Introduction to PI Server Security

The piadmin User

The piadmin user is the built-in PI Server super-user account. As piadmin you have
complete access to all objects and operations on the PI Server, regardless of the security
specification. This powerful account cannot be deleted or disabled.
In previous versions of the PI Server, several maintenance operations were reserved to the
piadmin account and could not be delegated. 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.
With the 3.4.380 release no tasks are reserved to piadmin. You should not use piadmin for
any normal administrative tasks. Delegate common administrative tasks to piadmins (or to a
different PI Group or PI Identity) and rely on the piadmin account only for exceptional or
recovery procedures. See The piadmins Group (page 8).
You should take further steps to protect the piadmin account, if possible. See Protect
piadmin (page 51).

The piadmins Group

The piadmins group is a built-in PI Group intended to represent PI Server administrators.
OSIsoft recommends that you use piadmins, rather than the super-user account (piadmin)
for common administrative tasks. On new installations, the built-in PI Group called
piadmins is granted full administrative access permissions by default so you do not need to
configure access permissions for it. Upgrade installations do not change the access
permissions for piadmins, so you might need to configure access permissions in order to use
it for administrative tasks.
To do this, add read/write access for piadmins to:
• All Database Security entries (SMT)
• All existing points and modules.
See How to Configure Access Permissions (page 22) for more information. You can then map
piadmins to the Windows users and/or groups that represent your PI Server system
administrators.

Note: The piadmins PI Group was called piadmin on previous versions of the PI
Server. The 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 Server 3.4.380 includes 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 Server users automatically get the access permissions
defined for PIWorld (in addition to any other access permissions they have been granted).

8
 Why Use the New Security Model?

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

The PIWorld Identity replaces the world access of earlier versions of the PI Server; world
access was always granted to all authenticated users, but there was no explicit world user
account. With PI Server 3.4.380, the previously implied world access is now made explicit
with the PIWorld Identity.
By default, PIWorld is granted read access to all PI Server databases and objects. 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 the New Security Model?

The new PI Server security model provides substantial improvements in security, efficiency,
and flexibility:
• Less work for PI Server administrators. You no longer need to create and manage
individual user accounts on the PI Server. When a user enters, leaves, or changes roles,
only the Windows configuration needs to be modified. PI Server security automatically
reflects these changes. You also get complete traceability of the specific Windows
account in the PI Server 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 Server login is
required.
• Improved Security:
ο Secure authentication. Connections are authenticated through Microsoft's Security
Support Provider Interface (SSPI). If you're using AD, then this means the most
secure Kerberos authentication, which greatly improves your PI Server security.
ο Control over server-side authentication policies. With the new security model, you
have control over the authentication protocols that client applications can use to
connect to the PI 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 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 Server resource can have read and/or write
permissions defined for any number of PI Identities.

Configuring PI Server Security 9

Chapter 2

Configuring Security on a New PI Server

Installation
This chapter explains how to configure security for new PI Server installations. If you
implement one of these configurations now, you are free to make changes at any time.
• Option 1: Quick-Start Configuration (page 11) describes a simple configuration that you
can use while you are working on a more comprehensive security configuration plan.
While very quick to implement, this configuration is not as secure or as flexible as the
recommended configuration. However, options for improving the security and flexibility
of this configuration are included. For simple systems, this might be sufficient for your
needs.
• Option 2: Recommended Configuration (page 14) explains how to create and implement
a custom PI Server security configuration that uses Microsoft Active Directory (AD) for
authentication (but not for PI access permissions; these are still defined directly on the PI
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 Server will be accessed by
client applications across non-trusted domains, then these configurations might be difficult to
implement. You can alternatively use local Windows security alone or in conjunction with
AD. See Other Security Configurations (page 24) to determine your options.
For instructions on upgrades, see Configuring Security for PI Server Upgrades (page 35).

Quick-Start Configuration
This configuration provides a quick implementation option that you can use while you are
developing a more complete security plan. For very simple systems, you could use this
configuration long term; in that case, consider making some adjustments to improve security
and increase flexibility.
• About the Configuration (page 12) explains the configuration and how it works.
• How to Configure (page 12) explains how to set it up.
• Improve the Quick-Start Configuration (page 13) explains how you could improve the
quick-start configuration to make it more usable for the long term.

Configuring PI Server Security 11

Configuring Security on a New PI Server Installation

About the Configuration

In this configuration you assign two levels of access permissions that apply to all PI Server
resources: users either get read-write or read-only access to everything. In AD, your users
should be grouped according to these two levels of PI Server access. On the PI 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 pre-
configured access permissions:
• piadmins: piadmins is a built-in PI Group that is pre-configured with read-write access
to all PI Server resources. Because we're using 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. On

upgrades, the access permissions for piadmins are not automatically
reconfigured, so this configuration option does not work. See Configuring
Security for PI Server Upgrades (page 35).

• PIWorld: PIWorld is a built-in PI Identity that is pre-configured with read access to all
PI Server resources. You cannot use PIWorld directly in a Mapping, however all
authenticated users on the PI 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 pre-configured for PIWorld. See The PIWorld
Identity (page 8) for more on PIWorld.

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

How to Configure

In this very simple model, users either get read-only access to everything on the PI Server or
they get read/write access to everything on the PI 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 Server access. (For AD configuration, your company's IT department is
probably your best resource.)
Step 1. Configure Authentication:
1. Identify which AD group or groups will have administrator (read/write) privileges on the
PI 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 pre-defined read/write access to all PI Server configuration and data, all the Windows
users in those AD groups will then get that level of access.

Note: Be sure to use the piadmins Group and not the piadmin User.

12
 Quick-Start Configuration

3. Map the AD group containing your read-only access users to the built-in PI Group
piusers. You can map multiple AD groups to piusers if needed. All the Windows users
in those groups will be authenticated as piusers. Since all authenticated users get read
access through the PIWorld Identity, you do not need to explicitly configure access
permissions for piusers.
Step 2. Configure PI interfaces. See Configure PI Interface Connections (page 30).

Improve the Quick-Start Configuration

If you plan to base your long-term security configuration on the quick-start configuration,
then consider these suggested improvements:
• To make the quick-start security configuration more flexible, you can add PI Identities to
represent different user categories. For example, you might want to grant IT
administrators permission to perform backups. To do that, you create a PI Identity and
give it the necessary access permissions. Then create a Mapping between AD group for
the IT administrators and that PI Identity.
• To make the quick-start security configuration more secure, you can explicitly set the
access permissions for the piusers Group, rather than relying on the PIWorld access
permissions. In the quick-start configuration we relied on PIWorld in order to make the
configuration process quicker and easier. However, it is a better practice to use explicitly-
configured access permissions. If you rely on PIWorld, it becomes difficult over time to
determine which users or applications are relying on that access.
The following examples demonstrate how to implement each of these suggested
improvements.
Example 1. Configure Administrative Access Categories: This example demonstrates how
to explicitly configure administrative access to run backups.
1. First create a PI Identity called ITAdmins (How to Create a PI Identity (page 16)).
2. Start PI SMT and connect to the PI Server as piadmins (for new installations only; for
upgrades, connect as piadmin). Open the Database Security Editor (Select Security >
Database Security).
3. In the Database Security Editor, 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
Server as piadmins. Open the Database Security Editor (Select Security > Database
Security).
1. For every entry in the Database Security Editor, set the access permissions for piusers to
read-only. See Set Permissions in the Database Security Editor (page 23).
2. Set permissions for built-in points. The PI Server installation includes several default
points. These are useful for test purposes. To explicitly grant read access to the piusers
Group, edit the points themselves. You can do this using Point Builder or Tag
Configurator, both available in the SMT (Set Permissions on Specific Points and Modules
(page 23)).

Configuring PI Server Security 13

Configuring Security on a New PI Server Installation

When you create new points, the piusers Group will automatically have read-only access.
This is because new points automatically have the same access permissions as the
PIPOINT entry in the Database Security Editor. See Set Default Access for New Points
and Modules (page 23) for instructions.
3. Set permissions for existing modules. At a minimum, the PI Server installation includes
the built-in module %OSI. Depending on what client applications you have installed,
there might be others. To explicitly grant read access to the piusers Group, edit the
modules themselves. You can do this using the Module Database Editor in SMT.
When you create new modules, the piusers Group will automatically have read-only
access. This is because new modules automatically have the same access permissions as
the PIModules entry in the Database Security Editor. See Set Default Access for New
Points and Modules (page 23) for instructions.

Recommended Configuration
These instructions assume that you are using Microsoft Active Directory (AD) for
authentication. You can use local Windows security instead, but it is not quite as secure and
extra configuration is required. See Use Local Windows Security (page 25).
To configure PI Server security with AD authentication, follow these basic steps (each step is
explained in more detail in the following sections):
1. Configure User Authentication. In most cases this simply means creating a PI Identity
for each AD group that requires PI access and creating a Mapping between them.
a. Identify User Access Categories: Identify the users who need access to the PI
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 Server backups? See Identify User Access Categories (page 15).
a. Create PI Identities: On the PI Server, create PI Identities for each user category.
See Create PI Identities (page 16).
b. Review Active Directory Groups: In Windows, identify Active Directory groups
that represent your PI Server users. In some cases you might need the help of your
Domain Administrator in order to create new groups, nest existing groups, or adjust
group memberships. See Review AD Configuration (page 17).
c. Map AD Groups to Identities: Once you have the necessary AD groups and PI
Identities, the next step is to set up a Mapping between them. See Map AD Groups to
PI Identities (page 20).
2. Configure Access Permissions. Give your PI Identities access to the necessary PI Server
resources. The access permissions specify what tasks each PI Identity is allowed to
perform on the PI Server. See Configure Access Permissions (page 21).
3. Configure PI Interface (and PI Client) access to the PI Server.
a. Configure access for PI Interfaces: You need to set up PI Trusts for interfaces that
will connect to the PI Server. Each trust is defined against a PI Identity that has the
required access permissions for that interface. See Configure PI Interface
Connections (page 30) for instructions on creating PI Trusts for interfaces.

14
 Recommended Configuration

b. Configure access for client applications (optional): Client applications typically

connect to the PI Server using PI SDK. You need SDK 1.3.6 or later to use Windows
authentication. Certain PI client applications require a connection to a separate
application server in addition to a PI 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? (page 59) for more
information.
There are a number of things you can do to provide extra security for your PI Server. See
Tightening Security (page 51) for suggestions and instructions.

Configure Authentication

This section outlines the recommended approach to configuring your PI Server

authentication.

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

To configure PI Server authentication, follow these steps:

• Identify User Access Categories (page 15)
• Create PI Identities (page 16)
• Review AD Configuration (page 17)
• Map AD Groups to PI Identities (page 20)

Identify User Access Categories

The first step in the security configuration is to determine:
• Who needs to use the PI Server?
• What PI Server resources do they need to access?
• What level of access do they need for each resource? (Read access? read/write access?)
Define categories of users that need the same set of access permissions. These will be your PI
Identities. You can have as many categories as you want. Typical PI Installations start from
one of the following basic models:
• Two category model: operators/admins
PI Server users are divided into two categories, which we refer to here as operators and
administrators. The operator category gets read-only access to all PI Server resources.
The administrator category gets read/write access to all PI Server 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 Server resources. This

Configuring PI Server Security 15

Configuring Security on a New PI Server Installation

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 Server installation (Built-in Identities, Users,
and Groups (page 7)).
Most of these are sample Identities, not configured with access permissions. However the
piadmins Group is pre-configured with read/write access to all PI Server resources. Using
piadmins for your main administrator category can save you some configuration time.
The following example shows you how you might use built-in PI Identities for the four user
categories described in Identify User Access Categories (page 15).
• Users: Use the built-in PI Group called piusers. This Group does not have any pre-
configured access permissions, so you will have to set those manually. As a short-cut you
could rely on the PIWorld access permissions, rather than explicitly setting permissions
for piusers. However, this model is less secure. See The PIWorld Identity (page 8).
• Engineers: Use the built-in PI Identity called PIEngineers. This Identity does not have
any pre-configured 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 Server resources. You can adjust these access permissions
as needed.
• IT Administrators: Create a PI Identity called ITAdmins. You will need to set the
access permissions manually.
Creating PI Identities is just the first step. You also need to:
• Map each AD group to the appropriate PI Identity (Map AD Groups to PI Identities (page
20)).
• Configure access permissions for each PI Identity (Configure Access Permissions (page
21)).

How to Create a PI Identity

To create a new PI Identity in PI SMT, follow these steps:

16
 Recommended Configuration

1. Select a server in the Collectives and Servers pane.

2. Select Security > Identities, Users, & Groups.
3. Select the Identities tab.
4. Click the New Identity icon . The New Identity dialog appears. This is where you
create and configure the new PI Identity.
5. In the Identity text field, type in a name for the new Identity. This is the only field that is
required to create a new Identity. Note the following restrictions on Identity names:
ο The name must be unique.
ο The name cannot include the vertical pipe (|) character or the colon (:) character.
ο The name cannot be a positive integer, although it can contain numbers. For example,
the name 407 is not valid, but the name Admins407 is valid.
ο The name is not case sensitive.
If you try to create an Identity with an invalid name, an error message appears and the
Identity is not created. Note that you can change an Identity name at any time after
creation.
6. Select the appropriate server from the drop-down Server menu. This menu is populated
from the selected servers in the Collectives and Servers pane. Only version 3.4.380 and
later PI Servers appear in the menu. Earlier versions of the PI Server do not support PI
Identities.
7. Optionally, enter a brief description in the Description field. There are no restrictions on
the contents of this field.
8. At the bottom of the dialog, several check boxes allow you to further configure the PI
Identity. Click to check the Identity cannot be deleted check box. This prevents the
Identity from being accidentally deleted. In order to delete this Identity, you would first
need to edit it and uncheck this check box.
9. Click Create. The new PI Identity now appears in the PI Identities tab.

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

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

Follow these guidelines:

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

Configuring PI Server Security 17

Configuring Security on a New PI Server Installation

• Review your AD group memberships to ensure that all Windows users will get the
appropriate PI Server permissions (PI Server Access Permissions and AD (page 18)).
• Establish a naming convention for PI Identities and/or AD groups so that it is clear which
group is mapped to which Identity. Over time, you will be able to control user access to
the PI Server simply by editing group memberships in AD or Windows
Once you have a workable set of AD groups, you are ready to AD groups to PI Identities.

Note: If your current AD groups do not suffice and you cannot get your AD Domain
Administrator's support, there is a simple workaround. You can create local
Windows groups on your PI Server and then place existing AD groups within the
local groups. See Other Security Configurations (page 24) for more information.

PI Server Access Permissions and AD

The access permissions for each user 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

18
 Recommended Configuration

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 AD
Group2. Since AD Group2 is nested inside AD Group1, the users in Group2 get all the access
permissions of Group1, as well as those of Group2.

Configuring PI Server Security 19

Configuring Security on a New PI Server Installation

Note: While it is possible to 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 Server security access by manipulating group memberships.

Map AD Groups to PI Identities

Once you have the necessary PI Identities and AD groups, you need to create a Mapping
between each AD group and a PI Identity. The Mapping associates the specified AD group
with the specified PI Identity. Members of that AD group will be automatically authenticated
on the PI Server as the specified PI Identity.
To map a PI Identity to a Windows group, follow these steps:
1. Open PI SMT.
2. Select the server in the Collectives and Servers pane.
3. In the System Management Tools pane, select Security > Identities, Users, & Groups.
4. Select the Identities tab.
5. Select the Identity that you want to map.
6. In the tool bar, click the Properties icon . The Properties dialog appears.
7. In the Properties dialog, click the Mappings and Trusts tab. The top portion of the
dialog 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 at the bottom of the Mappings portion of the dialog. (There is also
an Add button at the bottom of the Trusts portion, so be sure to click the right button.)
The Add New Identity Mapping dialog appears.

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

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

Specifying AD Users and Groups

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

20
 Recommended Configuration

• 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 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 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 have the Mappings between AD groups and PI Identities, you configure access
permissions so that each PI Identity is authorized to perform the appropriate tasks on the PI
Server.
• About Access Permissions on the PI Server (page 21)
• How to Configure Access Permissions (page 22)

About Access Permissions on the PI Server

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

Configuring PI Server Security 21

Configuring Security on a New PI Server Installation

The PI Server stores the settings for each object in an Access Control List (ACL). Each secure
object on the PI 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 Server does not allow you to explicitly deny access
privileges.

Access Permissions: Out-of-the-Box Configuration

The PI Server has an Identity, a User and a Group that come pre-configured 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 Server
resources. On PI Servers that are upgraded from an earlier version, the piadmins Group
has no pre-configured access permissions.
• The piadmin User is the super-user account. It has guaranteed read/write access to all PI
Server resources, regardless of security settings.
The PI Server also includes the PI Operators, PI Engineers, and PI Supervisors Identities.
These sample Identities have no pre-configured access permissions, so they don't 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 Server installations are as follows:
• Set default access permissions for new points and modules. After you do this, all new
points and modules that you create will automatically have these default settings. See Set
Default Access for New Points and Modules (page 23).
• Set top-level access permissions in SMT's Database Security Editor. 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 Editor (page 23).

22
 Recommended Configuration

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

Set Default Access for New Points and Modules

You can set default access permissions for points and modules. When you create a new point
or module without explicitly setting access permissions, the point or module gets the default
access permissions.
• Default access permissions for all new points (both point data and point configuration)
match the access permissions for the Point Database (PIPOINT). You can set permissions
for PIPOINT in the Database Security Editor.
• 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 Editor. New modules below the root level inherit from their parent.

Set Permissions in the Database Security Editor

The Database Security Editor controls access to most PI Server resources. The exception is
that permissions for specific points and modules are configured on the objects themselves.
To set access permissions in the Database Security Editor, follow these steps:
1. Open PI SMT.
2. Select the server in the Collectives and Servers pane.
3. In the System Management Tools pane, select Security > Database Security. The
Database Security Editor appears.
4. Double-click on the table for which you want to set access (see below). The Properties
dialog appears.
5. Select the PI Identity, PI User, or PI Group for which you want to modify access
permissions. If the PI Identity, User, or Group does not appear in the list, click the Add
button to add it.
6. Check the appropriate boxes to assign read and/or write access to that PI Identity.
For a complete list of PI Server tasks and associated access permissions, see Complete Table
of PI Server Access Permissions.

Set Permissions on Specific Points and Modules

You configure access permissions for individual points and modules by editing the object
itself. The PI Server installation includes tools for editing these objects. All of these tools can
be accessed from the PI System Management Tools (SMT). Some are located in the tree of
System Management Tools (in the lower left corner of the SMT window) and the others are
accessible from the SMT Tools menu.
To Control Use:
Access on:
a point Point Builder (SMT Plug-in), Tag Configurator (access from the SMT
Tools menu)

Configuring PI Server Security 23

Configuring Security on a New PI Server Installation

To Control Use:
Access on:
a module Module Database Editor (SMT Plug-in) or Module Database Builder
(access from the SMT Tools menu)
a PIUnit Module Database Editor (SMT Plug-in) or Module Database Builder
(access from the SMT Tools menu)
administrative Database Security Editor (SMT Plug-in)
tasks

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

Permissions for Typical Administrative Tasks

The following table lists some basic PI Server administration tasks and tells you which
Database Security entries control access to that task. For a more complete list, see Task-
Based Access Permissions Reference (page 63).
Administration Task Which Entries Control the Task
Managing Archives PIARCADMIN (basic archive administration tasks: archive creation,
registration and shifts" ) and PIARCDATA (archive data that is not
tag-specific, such as listing the archives; archive trouble-shooting
tasks)
Managing Backups PIBACKUP
Managing Identities, PIUSER
Mappings, Trusts, Users, and
Groups
Managing Auditing PIAUDIT
Creating/Deleting Points PIPOINT
Creating/Deleting Modules PIModules
Editing the Database PIDBSEC
Security Table
Managing firewall table, PITUNING
tuning parameters
Managing Message logs PIMSGSS

Managing PI HA Collectives PIReplication

Other Security Configurations

If you don't 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).

24
 Other Security Configurations

ο Extra configuration is required. The Windows user accounts on the PI Server must
exactly match the accounts on each client workstation. If you have a lot of client
workstations with a lot of users, then Windows authentication might not be a good
choice for you.
However, authenticating through local Windows security is still far more secure than
authenticating through PI Trusts or PI User accounts. See Use Local Windows Security
(page 25).
• Use a Combination of Local Windows Security and AD: If you want to use AD for
authentication but are not able to configure AD groups to meet your needs, then consider
this workaround. You can use local Windows groups to organize AD users. Then map the
local Groups to your PI Identities. See Use Local Windows Security with AD (page 28).
• Use PI Password Authentication: If you cannot use local Windows security or AD for
authentication, only two authentication methods are available: PI Server 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 Groups (page 28).

Use Local Windows Security

You can use local Windows security to grant access to the PI 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 Server and all client machines. When a
password changes or a user is added or deleted, you must make that change on the PI Server
and all participating client machines (this is actually a Windows requirement).

Note: If the PI Server is part of an HA collective, please refer to Configuring Security on

PI HA Collectives (page 47) before using local Windows groups.

The basic steps for configuring security with local Windows authentication are as follows:
1. Identify User Access Categories. Identify the users who need access to the PI 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 Server backups? See Identify User Access Categories (page 15).
2. Create PI Identities. On the PI Server, create PI Identities for people with similar access
needs. See Create PI Identities (page 16).
3. Configure Local Windows Groups. In Windows, identify the Windows groups that
represent your PI Server roles. See Configure Windows Groups (page 26).
4. Map Windows Groups to Identities. See Create Mappings (page 27).
5. Grant PI Access Permissions. Give your PI Identities access to the necessary PI Server
resources. The access permissions specify what tasks each PI Identity is allowed to do on
the PI Server. See Configure Access Permissions (page 21).
6. Configure access for client applications. Client applications typically connect to the PI
Server using PI SDK. You need SDK 1.3.6 or later to use Windows authentication.
Certain PI client applications require a connection to a separate application server in

Configuring PI Server Security 25

Configuring Security on a New PI Server Installation

addition to a PI 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? (page 59) for more information.
7. Configure access for interfaces. You need to set up trusts for the interfaces that will
connect to the PI Server. Each trust is based on a PI Identity. See Configure PI Interface
Connections (page 30).
There are a number of things you can do to provide extra security for your PI Server. See
Tightening Security (page 51) for suggestions and instructions.

Configure Windows Groups

To use Windows groups for PI Server authentication, follow these three steps:
1. Configure user accounts on client and server workstations. In order to use Windows users
and groups, the Windows user accounts on the PI 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 can't 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
Server permissions (Managing User Access Permissions with Windows Groups (page
26)).

Managing User Access Permissions with Windows Groups

The access permissions for each Windows user are determined by the PI Identities that user is
associated with. Each Windows group is mapped to a PI Identity. Windows users that belong
to that Windows group get the access permissions for that PI Identity.

26
 Other Security Configurations

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 the permissions for 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 Server as the specified PI Identity.
To map a Windows group to a PI Identity, follow these steps:
1. Open PI SMT.
2. Select the server in the Collectives and Servers pane.
3. In the System Management Tools pane, select Security > Identities, Users, and
Groups.
4. Select the Identities tab. (If you do not see the Identities tab, verify that you are
connected to a PI Server 3.4.380 or later. The Identities tab does not appear in SMT with
earlier versions of the PI Server.)
5. Double-click on the Identity. The Properties dialog appears.
6. In the Properties dialog, click the Mappings and Trusts tab. The top portion of the
dialog shows all existing Mappings for this PI Identity. The bottom portion shows all
existing PI Trusts for this PI Identity.

Configuring PI Server Security 27

Configuring Security on a New PI Server Installation

7. Click the Add button at the bottom of the Mappings portion of the dialog. (There is also
an Add button at the bottom of the Trusts portion, so be sure to click the right button.)
The Add New Identity Mapping dialog appears.

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

8. Windows Account: Enter the Windows group. 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 with an error message appears.
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 Server computer as a configuration tool to organize existing
AD principals. Create local Windows groups on your PI Server and map them to the
appropriate PI Identities (Create Mappings (page 27)). Then place existing AD groups and
users within the local Windows groups. In this configuration, user authentication is still
handled by AD.

Use PI Users and 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 Server and each user types in 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. To
configure PI Server PI password authentication, follow these steps:
1. Identify User Access Categories. Identify the users who need access to the PI 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 Server backups?
See Identify User Access Categories (page 15).
2. Create PI Groups: On the PI Server, create PI Groups for each user category. See
Create a PI Group (page 29).
3. Grant PI Access Permissions. Give your PI Groups access to the necessary PI Server
resources. The access permissions specify what tasks each PI Group is allowed to do on
the PI Server. See Configure Access Permissions (page 21).

28
 Other Security Configurations

4. Create PI Server User accounts. Each user who needs access to the PI Server should
have an associated account. See Create a New PI User (page 29). If you allow multiple
users to share a single PI Server account, then you will not have any way to know who
made what changes on the PI Server.
5. Configure Group memberships. Add each PI User to the appropriate PI Group or
Groups.
6. Configure Access for Interfaces. You need to set up trusts for the interfaces that will
connect to the PI Server. Each trust is based on a PI User, a PI Group, or a PI Identity.
See Configure PI Interface Connections (page 30).
7. Upgrade Administrative Client Applications. If you have existing client computers
that will connect to this PI Server, upgrade any applications that configure access
permissions (Administrative Client Applications (page 61)).

Create a New PI User

To create a new PI User, follow these steps:
1. Select a server in the Collectives and Servers pane.
2. Select Security > Identities, Users, & Groups.
3. Select the Users tab.
4. Click the New User icon . The New User dialog appears. This is where you create and
configure the new PI User.
5. In the Username text field, type in a name for the new PI User. This field is required to
create a new PI User. Note the following restrictions on user names:
ο The name must be unique. It cannot be the same as the name for an existing PI User,
PI Group, or PI Identity.
ο 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 329 is not valid, but the name Admins329 is valid.
ο The name is not case sensitive.
If you try to create a PI User with an invalid name, an error message appears and the User
is not created. Note that you can change a PI User name at any time after creation.
6. Select the appropriate server from the drop-down Server menu. This menu is populated
from the selected servers in the Collectives and Servers pane.
7. Optionally, enter a brief description in the Description field. There are no restrictions on
the contents of this field.
8. Enter a password for the PI User.
Click Create. The new PI User now appears in the PI Users tab.

Create a PI Group
To create a new PI Group, follow these steps:

Configuring PI Server Security 29

Configuring Security on a New PI Server Installation

1. Select a server in the Collectives and Servers pane.

2. Select Security > Identities, Users, & Groups.
3. Select the Group tab.
4. Click the New Group icon . The New Group dialog appears. This is where you create
and configure the new PI Group.
5. In the Group text field, type in a name for the new PI Group. This field is required to
create a new PI Group. Note the following restrictions on Group names:
ο The name must be unique. It cannot be the same as the name for an existing PI User,
PI Group, or PI Identity.
ο 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 329 is not valid, but the name Admins329 is valid.
ο The name is not case sensitive.
If you try to create a PI Group with an invalid name, an error message appears and the
Group is not created. Note that you can change a PI Group name at any time after
creation.
6. Select the appropriate server from the drop-down Server menu. This menu is populated
from the selected servers in the Collectives and Servers pane.
7. Optionally, enter a brief description in the Description field. There are no restrictions on
the contents of this field.
8. Click Create. The new PI Group now appears in the PI Groups tab.

Configure PI Interface Connections

To configure your PI Server to provide access for PI Interfaces:
1. Identify all the PI Interfaces that need access to the PI 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 (page
32)). The type of connection determines what information you can use to define the
Trust. You will also need to specify at least one item in the following list:
ο The correct application name to use when defining the Trust (The Application Name
(page 32))
ο IP information for the connecting computer (IP Information (page 33))
ο For SDK connections only, you have the option to specify Windows account
information, but this is not recommended (Windows Account Information (page 33))
3. Decide how many 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 How to Create a PI Identity (page 16).

30
 Configure PI Interface Connections

5. Give that PI Identity all the access permissions required by the PI Trust. See Product
Access Permissions Reference and Configuration Issues (page 67) as well as the
documentation for the Interface.
6. Create a trust based on that PI Identity. See How to Create a Trust (page 31).

About PI Trusts

PI Trusts allow applications to access the PI Server without explicitly logging onto Windows
(or onto the PI Server). Trusts are typically used for PI Interfaces, which run unattended.
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. Human intervention is not required at the time of
connection.

How to Create a Trust

To create a new PI Trust in SMT, follow these steps:

1. Select the server in the Collectives and Servers pane.
2. In the System Management Tools pane, select Security > Mappings and Trusts. The
Mappings and Trusts tool appears.
3. Click the New Trust icon . This launches the Add Trust Wizard.
4. Select the PI Server name and type in a name for the Trust (and, optionally, a
description). Click Next.
5. 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
6. 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 API and SDK connections.
− API: Connecting PI API applications send an identifier called an application
process name, or procname. This is a four-character string with an E appended.
(for example, the procname for the Perfmon Interface is: PIPeE)
− SDK: This is the full name of the connecting application, including the extension,
but not the path. (for example: PI-ICU.exe)
ο Network Path: Fully-qualified domain name of the Interface Node. (for example
my_laptop.my_company.com)
ο IP Address: The IP address of the Interface Node.
ο Net Mask: The net mask for the Interface Node. (for example, 255.255.255.255)

Configuring PI Server Security 31

Configuring Security on a New PI Server Installation

ο For SDK connections only, you also have the following optional fields:
− Windows Domain: the Windows domain of the user who is running the
application. (for example: osi)
− Windows Account: the Windows user name of the user who is running the
application. (for example: my_account)
7. Select the PI Identity that you want to use for this Trust. Applications authenticated
through this Trust will have all the access permissions granted to this PI Identity. You can
alternatively select a PI Group or a PI User for this step.

Connection Types
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 Server 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 Server. PI
API does not support Windows authentication. PI Trusts are the standard way to
authenticate PI API connections.
• PI SDK Connection: Most client applications use the PI SDK to connect to the PI
Server. PI SDK versions 1.3.6 and later support Windows authentication, so use
Windows authentication for these connections if possible. Windows authentication is the
most secure authentication method available for the PI Server.

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

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 the API send an identifier called an application process
name, or procname. This is a four-character string with an E appended. For example, the
procname for the Perfmon Interface is: PIPeE

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

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

32
 Configure PI Interface Connections

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

IP Information
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 Server computer. If you have
difficulty configuring the Trust, contact OSIsoft Technical Support.

• Network path. The fully-qualified domain name. For PI API, this should match what the
PI 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.
• Net Mask. If you specify an IP address, you must also explicitly provide a Netmask
value. Failure to do so will generate an error. If you are requiring an exact match on an IP
address, specify the Netmask as 255.255.255.255. If you are specifying 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, it is unpredictable
which credentials are sent to the PI 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 is running the application.
• Windows Account: the Windows user name of the user who is running the application.

Configuring PI Server Security 33

Chapter 3

Configuring Security for PI Server Upgrades

The upgrade to PI Server 3.4.380 provides a variety of new features and components. If you
are upgrading from an older version of the PI Server, this chapter explains what you need to
know:
• What is in the New Security Model? (page 35)
• Why a New Security Model? (page 36)
• Your Upgrade Options (page 36)

What is in the New Security Model?

The new security model introduces a number of changes to the PI Server:
• Windows authentication. In previous versions of the PI Server, there were only 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 users.
• New Access Permissions Model. The owner/group/world model of access permissions
has been replaced with access control lists that allow you to define permissions for as
many different purposes as you need. You are no longer restricted to one owner, one
group, and everyone else.
• PI Identities. The old model had only PI Users and PI Groups. This model was based on
the necessity for managing user accounts on the PI 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 Server.
• Mappings. Mappings are the mechanism for associating Windows users or groups with
PI Identities. You can also create Mappings to existing PI Users and PI Groups.
• New Version of 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 Editor. See
New in SMT (page 101) for more.

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

Configuring PI Server Security 35

Configuring Security for PI Server Upgrades

Why a New Security Model?

The new PI Server security model has the following major benefits:
• Improves Security. You can now use Windows authentication to control user access to
the PI 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 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 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 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 Server.
• Provides Single Sign-on. If you use Windows for authentication, your users no longer
need to separately log onto the PI 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 Server to the new model,
but you are not required to do that. Here are your options:
• Option 1: Migrate Over Time. Migrate to the new security model over time. If you
choose this option, you immediately switch to Windows authentication, but you continue
to use some components of your existing configuration. You can replace these
components over time. See Migrate Over Time (page 38) for instructions. This is the
recommended path for most PI Server installations.
• Option 2: Quick-start Migration. If your existing configuration is very simple (you use
only a handful of PI Users and PI Groups) then you can start with a quick upgrade
configuration. You can keep this configuration indefinitely, or you can use it as a starting
point for a slow migration to the new model. See Quick-Start Security Migration (page
37) for instructions.
• Option 3: Implement from Scratch. You can implement an entirely new security
configuration to take advantage of the new security model. The disadvantage is that this
could be disruptive to existing users. See Implement a New Configuration (page 46) for
instructions.
• Option 4: Keep existing configuration. You have the option to continue to use your
existing security configuration for as long as you choose. See Keep Existing
Configuration (page 46) for tips and concerns.

36
 Your Upgrade Options

Quick-Start Security Migration

Many PI 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 Server security.
Although these instructions assume you are using the piadmin and pidemo accounts, note
that you can apply the same method to any PI Server that relies on a very small number of PI
Users or PI Groups for security.

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

To set up this security configuration, follow these steps:

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 Server. If the appropriate group does not exist, get your domain
administrator to set one up for you. If you cannot get help from your domain
administrator, try the workaround described in Use Local Windows Security with AD
(page 28).
b. Create a Mapping between that AD group and the piadmin account. Now all users in
that AD group have the same privileges as piadmin.
2. Configure authentication for pidemo.
a. In Windows AD, identify the Windows group that will get the pidemo access
permissions on the PI Server.
b. Create a Mapping between that AD group and the pidemo account. Now all users in
that AD group have the same privileges as pidemo.
This completes the basic configuration on the PI Server. As soon as possible, consider these
additional steps for further securing your PI 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. A
good fix for this is to disable explicit logins (typing in a PI User name and password) for
the pidemo and piadmin accounts. Then username/password access is disallowed for
those accounts and they are only accessible through the Mappings you created or through
PI Trusts. See Disable Explicit Logins for Individual User Accounts (page 54) for
instructions.
• Review the follow-up steps, which include upgrading the SDK on client workstations,
upgrading administrative applications, and so on. You can choose if and when to
complete each step. See Follow-up Steps (page 45).

Configuring PI Server Security 37

Configuring Security for PI Server Upgrades

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 Server security
configuration that uses Windows authentication. See Initial Configuration Steps (page
38).
• Follow-up Steps: Perform these follow-up steps over time. See Follow-up Steps (page
45).
If your existing configuration relies on very few PI Users or PI Groups, the Quick-Start
Security Migration (page 37) might work better for you.

Initial Configuration Steps

When you migrate your PI 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 Server. You can use components of your existing configuration, which
you can replace over time. Here are the initial configuration steps:
1. Review Existing Access Permissions. Export the access permissions for all existing
points and modules and for all the entries in the SMT Database Security Editor. See
Review Access Permissions (page 38).
2. Create a List of Unique Access Strings. You will use this list to determine what sets of
access permissions are needed. See Create List of Access Strings (page 39).
3. Create a Configuration Plan. In this step you identify which PI Groups you will keep
and which are redundant. If you have any sets of access permissions that are not covered
by existing PI Groups, determine how you will fill those gaps. See Create a
Configuration Plan (page 41).
4. Create New Identities to Fill Gaps. If you decided to create new PI Identities to fill
configuration gaps, create them now. See Create PI Identities to Fill Gaps (page 43).
5. Review AD Groups. In this step, you determine how your AD groups correspond with
your configuration plan. You might need to create new AD groups or adjust group
membership. See Review AD Groups (page 43).
6. Create the Mappings. Set up Mappings between AD groups and PI Groups and
Identities. See Create Mappings (page 44).
7. Verify Initial Configuration. Check your new security configuration to make sure that
everyone is getting the correct level of access. See Verify Initial Configuration (page 44).

Step 1. Review Access Permissions

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

38
 Your Upgrade Options

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
Server Installation (page 11)).

When you export the existing data access permissions, each object will have an associated
Access Control List (ACL). This is different from the old owner/group model. For example,
in earlier versions of the PI 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 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 Server (page 21) for more information on the ACL.

CREATE AN ACCESS PERMISSIONS SPREADSHEET

To create a spreadsheet that contains all the existing access permissions on your PI Server,
you create the following three separate spreadsheets and merge them together:
• Point Data and Point Configuration: Use Tag Configurator to import all your point
security information into an Excel spreadsheet. Do this for all point classes. Which
attributes you need to import depends on which version of the PI 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 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 Editor in SMT. Click the Export List
icon to export the list into a .csv file. Open that file in Excel.

Step 2. Create List of Unique Access Strings

Examine the spreadsheet containing the access permissions for the PI 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 Server
that uses the old security model. Notice that the access permissions are exactly the same for
most of the tags.

Configuring PI Server Security 39

Configuring Security for PI Server Upgrades

point dataaccess datagroup dataowner

tag1 o:rw g:r w:r pi_ops bob
tag2 o:rw g:r w:r pi_ops bob
tag3 o:rw g:r w:r pi_ops bob
tag4 o:rw g:rw w:r pi_eng nancy
tag5 o:rw g:r w:r pi_ops bob

The following table shows what the same access permissions look like after upgrading to PI
Server version 3.4.380.
point datasecurity
tag1 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)
tag2 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)
tag3 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)
tag4 nancy: A(r,w) | pi_eng: A(r,w) | PIWorld: A(r)
tag5 bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)

40
 Your Upgrade Options

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, bob: A(r,w) | pi_ops: A(r) | PIWorld: A(r)
tag3, tag5

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

Step 3. Create a Configuration Plan

We want to identify the smallest set of existing PI Groups that can define our existing access
permissions. Ideally we want to retire all PI User accounts. To see how this works, look at the
list of unique access strings we identified in the previous example:

Configuring PI Server Security 41

Configuring Security for PI Server Upgrades

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:
ο the Windows users represented by the PI User members of pi_eng
ο the 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.

42
 Your Upgrade Options

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

The following table summarizes our new security configuration:

Keep: Type: Mapping:
pi_eng PI Group Windows group containing the users represented by the PI
User pi_eng;
Windows user represented by the PI User nancy
bob PI User Windows user represented by the PI User bob
PIWorld PI Identity n/a All authenticated users automatically get PIWorld access

The next step is to create the required Mappings and then disable the PI Group pi_ops and the
PI User nancy.

Step 4. Create PI Identities to Fill Gaps

Some of your old PI Users might have access permissions that do not match the access
permissions of any of your PI Groups. Ideally you should create a PI Identity for each set of
access permissions that you need. You then need to set the access permissions for each new
PI Identity. See Create PI Identities (page 16).
If you decide to keep PI User and PI Groups for some period of time, you should at least
create Mappings for them. Windows authentication is much more secure than PI password
authentication.

Step 5. Review AD Groups

Ideally, you want one AD group for each PI Group and PI Identity on your PI Server. When
you determined what sets of access permissions are needed, 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 Server. You need an AD group for each set of access permissions.

Configuring PI Server Security 43

Configuring Security for PI Server Upgrades

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 all PI Server
resources.

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

Step 6. Create Mappings

To create a Mapping in SMT, follow these steps:
1. Select the server in the Collectives and Servers pane.
2. In the System Management Tools pane, select Security > Mappings and Trusts.
3. Select the Mappings tab.
4. In the tool bar, click the New Mappings icon .
5. The New Mappings dialog appears.
6. 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 with an error message appears.
See Specifying AD Users and Groups (page 20) for more information.

Step 7. Verify Initial Configuration

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

44
 Your Upgrade Options

Follow-up Steps
After you have an initial PI Server configuration, you can continue to transition to the new
model over time. This section outlines some measures that you should take.
• Check Custom API Applications. A security loophole that was present in earlier
versions of the PI Server allowed world access to API connections, even if the
authentication failed. It was possible to disable that access explicitly but if you did not
disable it, then you might currently have API applications that rely on this loophole. That
access is now permanently disabled and any applications that rely on it will no longer
have access to the PI Server. You will need to configure authentication for these
applications. (This is typically only a problem for custom API applications.) See Check
for Unauthenticated API Connections (page 60).
• Limit Use of piadmin. Explicitly configure administrative permissions for a different PI
Identity; map the appropriate Windows group to that PI Identity. Do not use the piadmin
account for routine administrative tasks (Protect piadmin (page 51)).
• Upgrade the SDK on Client Computers. On computers running client applications,
upgrade PI SDK to version 1.3.6 or later. Earlier versions of the SDK do not support
Windows authentication.
• Configure Application Server Clients. If you are using applications where the client is
accessing the PI Server through an application server, then you might need to take
additional steps to complete your security configuration. See Products that Connect to an
Application Server (page 60) for more information.
• Upgrade Administrative Applications. If you are using older versions of administrative
applications, they might not handle new access permissions properly. See Administrative
Client Applications (page 61) 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 Server authentication method and it is best to disable it entirely or at least
partially. See Disable PI Password Authentication (Explicit Logins) (page 52) for more
information.

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

• Replace SDK Trusts. After you upgrade SDK on your client workstations, replace PI
SDK Trusts with PI Mappings. Windows authentication is more secure than
authentication through PI Trusts. In most cases, the existing Trusts will no longer be used
by the PI Server anyway (Retire SDK Trusts (page 54)).
• 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 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
Server). Additionally, PI Users have associated passwords that are not secure. Ideally,
you should plan replace your PI Users and PI Groups with descriptively-named PI
Identities.

Configuring PI Server Security 45

Configuring Security for PI Server Upgrades

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

Implement a New Configuration

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

Keep Existing Configuration

You can continue to use your existing PI Server security configuration for as long as you
choose. There are a couple of things you should do immediately:
• Check Custom API Applications. A security loophole that was present in earlier
versions of the PI Server allowed world access to API connections, even if the
authentication failed. That loophole is now closed. If you have API applications that rely
on this loophole, they will no longer get access. This is typically only a problem for
custom API applications. See Check for Unauthenticated API Connections (page 60).
• Protect the piadmin account with a password. The piadmin PI User is the PI Server
super-user account. This powerful account should be protected and should not be used
regularly. If you have not already done this, be sure to at least protect piadmin with a
password. See Protect piadmin (page 51) for more information on protecting piadmin.
• Require passwords for all PI Users. Do not allow blank passwords. Disable logins for
accounts with blank passwords. See Disable Explicit Logins with Blank Passwords (page
53).
Plan to migrate to the new security model. You can do this gradually over time. See Migrate
Over Time (page 38). Even before you begin configuration on the PI Server, you can
gradually perform many of the steps listed in Follow-up Steps (page 45).

46
Chapter 4

Configuring Security on PI HA Collectives

Windows authentication is fully supported on PI Servers configured as a Collective for High
Availability (HA).
If all Collective members are in the same security environment and if you are using Microsoft
AD, then configure the Primary Server just as you would a single PI Server. The
configuration will be replicated on the Secondary Servers. For this to work, all members of
the Collective must be either on a single domain or part of fully-trusted domains.
Configuration is more complicated if:
• Collective members are not contained in a homogeneous security environment. For
example, members are on different non-trusted domains, or one or more members are on
no domain.
• You do not have access to AD and must configure authentication through local Windows
security on Primary and Secondary Servers.
The complication arises because in a true HA Collective PI Mappings defined on the Primary
Server are fully replicated across all Collective members. In both the situations above, PI
Mappings on a specific Collective member needs to reference Windows users or groups that
are not valid on other members of the Collective.
This type of system is not a true HA Collective and could affect PI applications and users
when accessing PI Server information. If the same Mappings are not available on all
Collective members, applications might fail to connect or might receive different permissions
on failovers. There is a workaround, but this configuration should be avoided whenever
possible. If you need to do this, understand the risk and the complexity of managing a
heterogeneous PI Collective. More specifically, look at who needs access to each collective
member, and who will need to fail over. Consult OSIsoft Technical Support if you need help.
The PI Server includes a tuning parameter that tells Collective members to ignore Mappings
that they cannot resolve. (Tuning parameters are not replicated.) You can use this parameter
to create Mappings on a Collective member even though those Mappings cannot be resolved
by other Collective members.
Look at the following 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. When
you create Mappings on the Primary Server with domain accounts, the replication of these
Mappings will fail on the Secondary Server (because that domain doesn't exist for the
Secondary Server). Replication will stop and Secondary Server will fall out of
synchronization.
To fix this, use the Base_AllowSIDLookupFailureForMapping tuning parameter.
This parameter is not exposed in SMT by default. See Change the Lookup Failure Parameter
(page 48) for instructions on adding it. On the secondary Server, set the value of this
parameter to 1 and then stop and restart the Base subsystem for the new value to take effect.

Configuring PI Server Security 47

Configuring Security on PI HA Collectives

The Secondary Server will attempt to reapply the changes from replication; now it will accept
the Mappings and replication will succeed.
This same situation holds true for Mappings against local Windows groups. Suppose the
Primary Server defines a Mapping against a local Windows group. Secondary Servers do not
know about that local group and the Mappings will fail on replication. In order for replication
to succeed, on the Secondary, you would need to set
Base_AllowSIDLookupFailureForMapping to 1 and then restart the Base
Subsystem.
Similarly, you might need to define Mappings against local Windows groups on the
Secondary Server. In this case, on the Primary you would set
Base_AllowSIDLookupFailureForMapping to 1 and then restart the Base
Subsystem.
Once the timeout parameter is set to 1, if you wish to map to a local Windows group from
another machine, you have to use the group's SID instead of its name when you configure the
Mapping. SMT does not allow you to create a Mapping based on a SID, so you must use
piconfig to create the Mapping (Create a Mapping with a SID (page 49)).
You can use SMT to determine the SID however. Use the SMT Mappings and Trusts tool
on the Secondary that needs the Mapping. If you already have a Mapping based on the
desired Windows group, the properties for that Mapping display the SID. If you don't already
have a Mapping, start to create one (you do not have to save it). The New Mapping dialog
will display the SID as soon as you select a Windows user or group. Copy the SID and use it
to create the Mapping on the Primary.
In these scenarios, it is recommended to use the
Base_AllowSIDLookupFailureForMapping setting as a temporary setting while
you are creating the Mappings. Once they are created, you can revert
Base_AllowSIDLookupFailureForMapping back to 0, which will protect against
the accidental creation of invalid Mappings.

Change the Lookup Failure Parameter

The Base_AllowSIDLookupFailureForMapping parameter is not exposed in SMT
by default. To change it, follow these steps in SMT:
1. Select Operation > Tuning Parameters.
2. Click the New Parameter button .
3. In the Parameter Name field, type:
Base_AllowSIDLookupFailureForMappings
4. In the Value field, type:
1
5. Click OK.
6. Restart the Base subsystem.

48
 Create a Mapping with a SID

Note: This setting (like any tuning parameter) is not replicated.

Create a Mapping with a SID

To create a Mapping based on a SID you need to use the piconfig utility to update the PI
Identity Mapping table (PIIdentMap). To run piconfig, open a command window, change to
the PI/adm directory, and type piconfig. The piconfig command prompt appears. The
following example demonstrates how to create a new Mapping called My_Mapping. This
example would map the Windows principal specified by a SID (S-1-5-21-
1111111111-1111111111-1111111111-11111) to the PI Group piadmins.
PIconfig> @table PIIdentmap
PIconfig> @mode create
PIconfig> @istr IdentMap,Principal,PIIdent
PIconfig> My_Mapping,S-1-5-21-1111111111-1111111111-1111111111-
11111,piadmins
The above example sets only those attributes that are required to create a Mapping:
• name the PI Identity Mapping with the IdentMap attribute
• name the PI Identity to be mapped with the PIIdent attribute
• specify the SID to be mapped with the Principal attributeUpdates to other PIIdentMap
table attributes are optional.
The PIIdentMap table has other attributes, which you can optionally specify when you create
the Mapping. They are:
Attribute Description

IdentMap The name of the PI Mapping. This must be unique, but is not case-sensitive.
This field is required to create a new Mapping.
Desc Optional text describing the Mapping. There are no restrictions on the contents
of this field.
Flags Bit flags that specify optional behavior for the mapping. Currently the only option
is:
0x01 = Disabled; the Mapping is inactive and will not be used during
authentication.
(The default value is 0x00 = Mapping is active and will be used during
authentication after initial setup.)
IdentMapID A unique integer corresponding to the identity mapping. The system will
automatically generate the value upon creation and it will not change for the life
of the identity mapping.
PIIdent Name of the PI Identity to which the security principal specified by the Principal
field will be mapped. The contents of this field must match the Ident field of an
existing entry in the PIIdent table. The target identity must not be flagged as
Disabled or MappingDisabled. Multiple IdentMap entries can map to the same
PIIdent entry. This field is required to create a new identity mapping

Configuring PI Server Security 49

Configuring Security on PI HA Collectives

Attribute Description

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

50
Chapter 5

Tightening Security
This chapter explains how you can improve the security on your PI Server. For a
comprehensive guide to the best possible PI Server security, see the PI Server Security Best
Practices white paper, available on the OSIsoft Technical Support web site.
• Protect piadmin (page 51)
• Disable PI Password Authentication (Explicit Logins) (page 52)
• Secure piconfig Utility (page 54)
• Retire SDK Trusts (page 54)
• Configure PI Firewall (page 56)
• Disable PIWorld (page 57)

Protect piadmin
The piadmin PI User is the PI Server super-user account. Take the following basic measures
to protect this powerful account:
• Disable explicit logins for the piadmin account (Disable Explicit Logins for piadmin
(page 51)). Explicit logins (also called password authentication) on the PI Server are not
nearly as secure as Windows authentication or PI Trusts. Instead, control access to this
account through Windows authentication.
• If you cannot disable explicit logins for the piadmin account, then at least make sure that
the piadmin account does not have a blank password. New PI Server installations require
a password for piadmin. While this is not mandatory for upgrades, it is strongly
recommended.
• Restrict piadmin access to a small group of trusted administrators.

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

Disable Explicit Logins for piadmin

When you disable explicit logins for piadmin, this means that users cannot access the PI
Server by typing in the username and password. piadmin can still be used in Mappings and
Trusts.
To disable explicit logins for piadmin:

Configuring PI Server Security 51

Tightening Security

1. In SMT, open the Identities, Users, and Groups tool (select Security > Identities, Users,
& Groups).
2. If you are using the display option with separate tabs for Users, Group, and Identities,
then click the Users tab.
3. Double-click the piadmin entry.
4. The Properties dialog box appears.
5. On the General tab, click to check the User cannot be used for an explicit login check
box.
6. Click OK.

Disable PI Password Authentication (Explicit Logins)

When a user logs onto the PI Server by typing in a PI User name and password, this is called
an explicit login (or password authentication). Explicit logins on the PI Server are the least
secure authentication method available to you. A good security practice is to disable all
explicit logins on the PI Server, however this is not always possible. You can alternatively
disable explicit logins for some accounts. Here are your basic options:
• Disable All Explicit Logins (page 52). This is the most secure option, but if your current
configuration requires users to log into PI User accounts, then you are not ready for this
move.
• Disable Explicit Logins with Blank Passwords (page 53). 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 Users.
• Disable Explicit Logins for Individual User Accounts (page 54). As you begin to
configure Windows authentication for your users, you can disable explicit logins for
these accounts.

Note: On new PI Server installations, explicit logins are disabled by default. When you
upgrade the PI Server, you are prompted to disable explicit logins, but you are not
required to do so.

Disable All Explicit Logins

In PI SMT you can use the Security Settings tool to disable all explicit logins:
1. In SMT, select Security > Security Settings. The Security Settings tool appears.
2. Select the Server in the Collectives and Servers pane. You can change settings for only
one PI Server at a time and only for PI Servers running version 3.4.380 or later.
3. Move the slider to the Explicit login disabled option.

52
 Disable PI Password Authentication (Explicit Logins)

4. Click Save.
5. Stop and restart the Base subsystem:
a. In SMT, select Operation > PI Services.
b. Right-click on the PI Base Subsystem entry and choose Stop Service from the
resulting pop-up menu.
6. After the Base 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:
1. In SMT, select Security > Security Settings. The Security Settings tool appears.
2. Select the Server in the Collectives and Servers pane. You can change settings for only
one PI Server at a time and only for PI Servers running version 3.4.380 or later.
3. Move the slider to the Blank password not allowed option.

4. Click Save.
5. Stop and restart the Base subsystem:
a. In SMT, select Operation > PI Services.
b. Right-click on the PI Base Subsystem entry and choose Stop Service from the
resulting pop-up menu.

Configuring PI Server Security 53

Tightening Security

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

Disable Explicit Logins for Individual User Accounts

To disable explicit logins for a PI User account:

1. In SMT, open the Identities, Users, and Groups tool (select Security > Identities, Users,
& Groups).
2. If you are using the display option with separate tabs for Users, Group, and Identities,
then click the Users tab.
3. Double-click the username for the PI User.
4. The Properties dialog box for that PI User appears.
5. On the General tab, click to check the User cannot be used for an explicit login check
box.
6. Click OK.
To re-enable explicit logins for a PI User account, un-check the same check box.

Secure piconfig Utility

System managers who have physical access to the PI Server computer and to the directory
containing the PI Server files are able to run all PI Server management utilities as piadmin,
without being prompted for a password. You can configure the PI Server to force an explicit
login in order to use piconfig and other command-line utilities. When you do this, the PI
Server requires administrators to type in a user name and password when they use these
utilities.
Follow these steps:
1. In PI SMT, select Operation > Tuning Parameters.
2. Click the Security tab.
3. In the list of parameters, double-click on the CheckUtilityLogin parameter.
4. In the Value text field, type:
1
5. Click OK.

Retire SDK Trusts

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

54
 Retire SDK Trusts

• While 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 (When Both a Mapping and a Trust Apply (page 55)). This means that their
access permissions will be dictated through Windows, rather than the Trust.
Once all your SDK Trusts are replaced by Windows authentication, you can further secure
the PI Server by disabling SDK Trusts altogether.

When Both a Mapping and a Trust Apply

If a Windows user who is running an SDK application has access to the PI Server through
Windows authentication (PI Mappings and PI Identities) then that user will be authenticated
through Windows, rather than through the Trust. This is because newer versions of the SDK
try Windows authentication first.
This means that their access permissions will be dictated through the Mappings, rather than
the Trust. It is best to retire SDK Trusts wherever possible, and rely on the Windows
authentication instead.

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

Configure SDK Authentication Protocols

When an SDK application tries to connect to the PI Server, it tries all available authentication
methods until it succeeds. The order in which it tries the authentication methods is
configurable. The possible methods are:
• Windows Security. If a valid PI Mapping exists for the Windows user (or for any group
to which the user belongs) then the user is authenticated as the PI Identity, PI User, or PI
Group defined for that Mapping.
• 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.
• Default User. A default PI User account.
The first one that succeeds defines the access permissions that the connecting application is
granted. Once one authentication method succeeds, no other methods are tried. By default the
SDK (1.3.6 and later) tries to authenticate first through Windows.
You can configure which methods the SDK tries first. To do this from SMT:
1. Select File > Connections. The Connection Manager appears.
2. Select Tools > Options. The Connection Option dialog appears.
3. The Specify Authentication area is at the bottom of the dialog. You can choose which
protocols to allow and in which order they should be tried.

Configuring PI Server Security 55

Tightening Security

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

Disable SDK Trusts

In PI SMT you can use the Security Settings tool to disable access to the PI Server through
SDK Trusts:
1. In SMT, select Security > Security Settings. The Security Settings tool appears.
2. Select the Server in the Collectives and Servers pane. You can change settings for only
one PI Server at a time and only for PI Servers running version 3.4.380 or later.
3. Move the slider to the SDK trusts are disabled option.

4. Click Save.
5. Stop and restart the Base subsystem:
a. In SMT, select Operation > PI Services.
b. Right-click on the PI Base Subsystem entry and choose Stop Service from the
resulting pop-up menu.
c. After the Base subsystem stops, right-click on the PI Base Subsystem entry again
and choose Start Service.

Configure PI Firewall
For all incoming connections, the PI Server first checks the PI Firewall for partial or
complete IP host names or addresses. If there is no entry in the table that allows the incoming
connection, it is terminated immediately.
By default, the PI Firewall table allows all connections. Edit the Firewall to allow
connections only from the subnets defined for your community of users. You can change
settings for the PI Firewall with the SMT Firewall tool, which you can access by choosing
Security > Firewall. On PI HA collectives, the PI Firewall is not replicated.

56
 Disable PIWorld

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

Disable PIWorld
You can disable the PIWorld Identity. This improves your control over access to the PI
Server. All users get only the access that is explicitly configured for them and no more. The
decision to disable PIWorld should not be taken lightly.
• For PI 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, consult technical support to help you form a plan.
• If this is a completely new installation, with no pre-existing PI Interface Nodes or client
applications, then you should definitely consider disabling PIWorld.

Configuring PI Server Security 57

Chapter 6

How Will PI Server 3.4.380 Affect My Clients and

Interfaces?
In most cases, an installation or upgrade to PI Server 3.4.380 does not affect PI client
applications. Additional security configuration steps might be necessary for products that do
either of the following:
• Products that Connect to an Application Server (page 60)
• Products That Connect Through a Trust (page 59) (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 Server security features, you need
to:
• Upgrade the PI SDK to version 1.3.6 or later. Nearly all functionality for the new
Windows Security on the client side resides within the PI SDK.
• Upgrade Administrative Client Applications (page 61) (applications that can set access
permissions)

Note: PI API does not support Windows authentication. 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

Most Interfaces connect to PI using a PI Trust. Client applications can also connect through a
PI Trust. When you upgrade to PI Server 3.4.380, your existing PI Trusts continue to work.
The exception is that custom applications might have been accessing the PI Server through
wrongly-configured Trusts and might no longer be able to connect. See Check for
Unauthenticated API Connections (page 60) for more information.
If you have Trusts defined against the piadmin super-user account, it is a good security
practice to migrate these to a different PI Identity, PI User, or PI Group. See Protect piadmin
(page 51). 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

Configuring PI Server Security 59

How Will PI Server 3.4.380 Affect My Clients and Interfaces?

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

Note: In previous versions of the PI 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 (page 30).

Check for Unauthenticated API Connections

Previous versions of the PI Server allowed unauthenticated API applications to connect to the
PI Server with world access. In previous versions of the PI Server, you could explicitly close
this security hole by using the DefaultUserAccess Tuning Parameter. In PI Server 3.4.380,
this security hole is completely closed and the DefaultUserAccess parameter no longer
exists. Applications that do not successfully authenticate cannot be given any access on the PI
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 API applications, you might find that they were not connecting
properly and now no longer have access. You must configure valid PI Trusts for those
applications.
To identify API applications that are not connecting properly, check the message log. Look
for the following types of messages:
• Message ID = 7054, which contains text "No trust established for: <identifyingString>.
Explicit login is required for access "
• Message ID = 7140, which contains text "Timeout expired for unauthenticated API
Connection"
These Message IDs are unique and can be filtered in the 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 Server. Examples include PI DataLink for Excel Services (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.

60
 Administrative Client Applications

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 Server.
Older versions of administrative applications cannot interpret new-model access permissions
unless the access permissions are compatible with the old model. How the incompatible
access permissions are displayed depends on the specific client tool that you are using.
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 Server 3.4.380

Older versions of administrative tools cannot properly display access permissions unless they
follow the owner/group/world model. To work with new-model permissions, you need to be
running SDK 1.3.6 or later and you need a tool version that supports the new model. Here are
the required versions for common administrative tools:
• PI SMT version 3.3.1.3 or later (includes Point Builder, Module Database Editor, and
Database Security Editor)
• Tag Configurator version 2.1.3 or later
• Module Database Builder version 1.2.1.3 or later
• PI ICU 1.4.7 or later
• PI APS 1.2.5.0 or later

How to Maintain Backwards-Compatible Access Permissions

On previous versions of the PI 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
• the PIWorld Identity
If any of these conditions is not met, then the PI Server cannot determine an owner and
group. It will use the PIUserIncompatible and PIGroupIncompatible Identities for the

Configuring PI Server Security 61

How Will PI Server 3.4.380 Affect My Clients and Interfaces?

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 PIUserIncompatible and PIGroupIncompatible Names

PIUserIncompatible and PIGroupIncompatible are displayed as the owner and group

when new-model access permissions cannot be interpreted by older administrative
applications.

By default, PIUserIncompatible and PIGroupIncompatible are not displayed in the SMT

Identities, Users, and Groups tool. To see them, click the Options button and then click to
check the show the incompatible user and group option. PIUserIncompatible and
PIGroupIncompatible now appear in the Identities, Users, and Groups tool. You can change
their names as you would any other PI User and PI Group.

62
Appendix A

Task-Based Access Permissions Reference

The following table lists the required access permissions for tasks on the PI Server.
Task Database Security Other Permissions
permissions
Archives: Backing up PIBACKUP (r,w)
Archives: Create / Register / PIARCADMIN (w)
Unregister, Force Shift
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 / A PIUnit is a module; see
Delete / View PIUnit corresponding Tasks for
Modules
Batch Database: Create / Edit / PIModules (r) PIUnit (r1,w)
Delete PIUnitBatch, PISubBatch
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 / dest is type
Delete PITransferRecord PIBatch, also need
permissions for Task
Batch Database: View
PIBatch
- if src / dest is type
PIUnitBatch, also need
permissions for Task
Batch Database: View
PIUnitBatch, PISubBatch
- if src / dest is type
module, also need
permissions for Task
Modules: View
Batch Database: Insert / Remove PIBatch (r,w) PIUnit (r1,w)
PIUnitBatch into / from PIBatch
Batch Database: Insert / Remove PICampaign (r,w)
PIBatch into / from PICampaign PIBatch (r,w)

Configuring PI Server Security 63

Task-Based Access Permissions Reference

Task Database Security Other Permissions

permissions
Batch Database: View PIUnitBatch, PIModules (r) PIUnit (r1,w)
PISubBatch

Batch Database: View PIBatch PIBatch (r) if contains PIUnitBatches,

also need permissions for
Task Batch Database:
View PIUnitBatch,
PISubBatch
Batch Database: View PICampaign PICampaign (r) if contains PIBatches, also
need permissions for Task
Batch Database: View
PIBatch
Batch Database: View PITransferRecords (r) - if src / dest is type
PITransferRecords PIBatch, also need
permissions for Task
Batch Database: View
PIBatch
- if src / dest is type
PIUnitBatch, also need
permissions for Task
Batch Database: View
PIUnitBatch, PISubBatch
- if src / dest is type
module, also need
permissions for Task
Modules: View
Batch Subsystem: Create / Edit / PIBATCHLEGACY (r,w) unit (r,w)
Delete units and batches

Batch Subsystem: Create / Edit / PIBATCHLEGACY (r,w) permissions for Task

Delete aliases Points: View attributes

Batch Subsystem: View units and PIBATCHLEGACY (r) unit (r,w)

batches

Batch Subsystem: View aliases PIBATCHLEGACY (r) permissions for Task

Points: View attributes

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

Database Security Table: View PIDBSEC (r)

Digital State Sets: Create / Edit / PIDS (r2,w)

Delete digital sets or states

Digital State Sets: View digital sets PIDS (r2)

or states

64
 Administrative Client Applications

Task Database Security Other Permissions

permissions
Event Queue: Configure PITUNING (r,w)

Firewall: Configure PITUNING (r,w)

HA: Create / Configure an HA PIREPLICATION (r,w)

Collective

Heading Sets: Create / Edit / Delete PIHeadingSets (r3,w) heading set (r,w)
heading set

Heading Sets: Create / Edit / Delete PIHeadingSets (r3,w) heading set (r,w)
heading heading (r,w)

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

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

heading (r)

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

Create / Edit / Delete

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

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

Mappings: View PIUSER (r)

Message Log: Write messages PIMSGSS (w)

Message Log: View messages PIMSGSS (r)

Modules: Create PIModules (r,w) parent module (r1,w)

Modules: Delete PIModules (r,w) parent module (r1,w)

module (r1,w)

Modules: Edit PIModules (r) module (r1,w)

Configuring PI Server Security 65

Task-Based Access Permissions Reference

Task Database Security Other Permissions

permissions
Modules: Edit – Link / Unlink PIModules (r) new parent module (r1,w)
module (r1,w)

Modules: Edit – Add / Remove alias PIModules (r) module (r1,w)

permissions for Task
Point: View attributes
Modules: Edit – Add / Remove PIModules (r) module (r1,w)
heading
permissions for Task
Heading Sets: View
heading
Modules: View PIModules (r) module (r1)

Points: Create PIPOINT (r,w)

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

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

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

DataSecurity (w)

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

DataSecurity (r,w)

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

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

DataSecurity (r,w)

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

Trusts: View PIUSER (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 (r) for all modules along the hierarchy path above it
2
PIDS (r) is implicitly granted by PIPOINT (r)
3
PIHeadingSets (r) is implicitly granted by PIModules (r)

66
Appendix B

Product Access Permissions Reference and

Configuration Issues
This section provides a product-by-product table reference that allows you to quickly
determine what access permissions you might need given the presence of certain PI clients,
data access products, and/or Interfaces.
In some cases, these product permission tables are followed by additional information
regarding related configuration issues.

Configuring PI Server Security 67

Product Access Permissions Reference and 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

68
 AF 1.3 Server

AF 1.3 Server
Database Security Permission Notes

PIDS r
PIModules r,w

PIPOINT r,w not required for

SQL backend

Point Database Permission Notes

PtSecurity r,w not required for

SQL backend
DataSecurity r,w not required for
SQL backend

Module Database Permission Notes

Module Security* r,w both SQL and

non-SQL
backends
require access

* Generic Client application permissions that can operate on any module

Configuring PI Server Security 69

Product Access Permissions Reference and Configuration Issues

AF 1.3 Client
Database Security Permission Notes

PIDS r
PIModules r

PIPOINT r,w w: only

necessary for
autocreate
option of PI
PointData
Reference

Point Database Permission Notes

PtSecurity r,w w: only

necessary for
autocreate
option of PI
PointData
Reference
DataSecurity r,w w: only if writing
to PI

Module Database Permission Notes

Module Security* r

* Generic Client application permissions that can operate on any module

70
 DataSheet Control

DataSheet Control
Database Security Permission Notes

PIUSER r

PIBatch r,w w: to create PIBatches,

and to insert
PIUnitBatches into
PIBatches
PIModules r

PIPoint r

Point Database Permission Notes

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

Module Database Permission Notes

Module Security* r,w w: for PIUnits to create

PIUnitBatches and
insert PIUnitBatches
into PIBatches

* Generic Client application permissions that can operate on any module

Configuring PI Server Security 71

Product Access Permissions Reference and Configuration Issues

PI Groups and DataSheet Control

Some functionality in the DataSheet Control is tied to PI Groups. Specifically, there are
regulatory features that allow the ability to Commit and Confirm manually entered data to be
limited to a user-specified PI Group. One PI Group may be chosen to limit Commit
functionality, and a different PI Group may be chosen to limit Confirm functionality. Users
who do not belong to the specified Regulatory User Groups within the DataSheet Control
receive an error indicating 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? (page 5) for more information.

72
 PI ACE

PI ACE
Database Security Permission Notes

PIModules r1,w2,3,4
PIPoint r1,w5
PIDS r

PIMSGSS r1,w2
PIDBSec r2,3,4,5

Point Database Permission Notes

PtSecurity r1,w5
DataSecurity r1,w2

Module Database Permission Notes

Module Security* r1,w2,3,4

* Generic Client application permissions that can operate on any module

1
In order for PIACEManager 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 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
Server, it needs read/write permission to the PIMSGSS to log messages.
3
Users of PIACEManager that configure and manage PI ACE calculations need read/write
permission to PIModules. Most of the tasks in PIACEManager 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 VisualStudio
environment need read/write permission to PIModules, and read permission to the data source
tags, including the PIDS table.
5
PIACEWizard 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.

Configuring PI Server Security 73

Product Access Permissions Reference and Configuration Issues

PI BatchView
Database Security Permission Notes

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

Point Database Permission Notes

PtSecurity r
DataSecurity r

Module Database Permission Notes

Module Security* r same as for PIModules

Database Security

* Generic Client application permissions that can operate on any module

74
 PI BatchView

Configuring Security for PI BatchView

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 Server will automatically edit the security of the underlying tag based on
changes to the security of the PIUnit's module. Thus, the tag's security attributes
should never be modified directly to ensure they do not get out of sync with the
PIUnit's module. Only the security of the PIUnit's module should be edited.

Module Database Security

Read access is required for the PIUnit's module associated with any PIUnitBatch records used
by 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).

Configuring PI Server Security 75

Product Access Permissions Reference and Configuration Issues

PI DataLink
Database Security Permission Notes

PIModules r

PIPOINT r

Point Database Permission Notes

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

Module Database Permission Notes

Module Security* r

* Generic Client application permissions that can operate on any module

76
 PI DataLink for Excel Services (PI DLES)

PI DataLink for Excel Services (PI DLES)

Database Security Permission Notes

PIBatch r

PIHeadingSets r
PIModules r

PIPOINT r

Point Database Permission Notes

PtSecurity r
DataSecurity r

Module Database Permission Notes

Module Security* r

* Generic Client application permissions that can operate on any module

Configuring PI Server Security 77

Product Access Permissions Reference and Configuration Issues

Configuring Security for PI DLES

If you are configuring a PI Server to use Windows Active Directory (AD) for authentication,
then you need to perform some additional configuration steps to use PI DataLink for Excel
Services (PI DLES).
Specifically, you need to configure the SharePoint Server for Kerberos delegation. Kerberos
is a secure type of authentication used by AD. If a PI Server is configured for AD
authentication, but Kerberos delegation is not configured on the SharePoint Server, then PI
DLES returns the following error message:
No PI user was recorded for a trusted connection.
For more details, please see the OSIsoft Knowledge Base article on Configuring Kerberos
authentication required as post-installation step for PI DataLink for Excel Services
(http://techsupport.osisoft.com/NR/exeres/2E7F789F-4E41-4CC8-BC91-EB7DD11BD6A7).

78
 PI Manual Logger

PI Manual Logger
Database Security Permission Notes

PIModules r In version 2.x or

greater
PIHeadingSets r In version 2.x or
greater
PIPOINT r

PIUSER r

Point Database Permission Notes

PtSecurity r
DataSecurity r,w

Module Database Permission Notes

Module Security* r In version 2.x or

greater

* Generic Client application permissions that can operate on any module

Configuring PI Server Security 79

Product Access Permissions Reference and Configuration Issues

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 Server. Because of these extra checks, such
older versions of PI-ML should connect to the PI Server solely via a PI Trust to a PI User.
For details, see How to Create a Trust (page 31).
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 (page 61).
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 Server for its security. Thus, PI-ML 2.3 can fully leverage all the new
security features of the 3.4.380 PI Server.

80
 PI Notifications

PI Notifications
Database Security Permission Notes

PIDS r1
PIPOINT r1,w2
PIMSGSS r,w2

Point Database Permission Notes

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 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 Server, then they also need
read/write permission to PIMSGSS for error message logging.

Configuring PI Server Security 81

Product Access Permissions Reference and Configuration Issues

PI OLEDB
Database Security Permission Notes

PIBatch r,w r,w: to query

pibatch..pibatch or
pibatch..pibatchpr
operty tables
PICampaign r,w r,w: to query
pibatch..picampai
gn or
pibatch..picampai
gnproperty 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..pitransfer
property tables
PIUSER r,w r,w: to query any
table in the piuser
catalog

Point Database Permission Notes

PtSecurity r,w
DataSecurity r,w

Module Database Permission Notes

Module Security* r,w

* Generic Client application permissions that can operate on any module

82
 PI ProcessBook

PI ProcessBook
Database Security Permission Notes

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

Point Database Permission Notes

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

Module Database Permission Notes

Module Security* r

* Generic Client application permissions that can operate on any module

1
Write access not required if you have PI SDK 1.4 or later installed

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

Configuring PI Server Security 83

Product Access Permissions Reference and Configuration Issues

RtAlerts
Database Security Permission Notes

PIDS r
PIModules r,w

PIPOINT r

Point Database Permission Notes

PtSecurity r
DataSecurity r

Module Database Permission Notes

Module Security* r,w

* Generic Client application permissions that can operate on any module

84
 RtReports Server (to configuration PI Server)

RtReports Server (to configuration PI Server)

Database Security Permission Notes

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
Server 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

Point Database Permission Notes

PtSecurity r,w r: in RtReports Server

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

Module Database Permission Notes

Module Security* r r,w: required for the

\%OSI\RtReports node
of the MDB to read or
write application data
(report templates,
RtReports app-level
security)

* Generic Client application permissions that can operate on any module

Configuring PI Server Security 85

Product Access Permissions Reference and Configuration Issues

RtReports Editor (to PI Data Server)

Database Security Permission Notes

PIBatch r

PIModules r

PIPOINT r

Point Database Permission Notes

DataSecurity r

Module Database Permission Notes

Module Security* r

* Generic Client application permissions that can operate on any module

86
 RtReports Editor (to PI Data Server)

Configuring Security for RtReports

While RtReports allows you to configure permissions access for various user types, it does
not depend on the PI Server, which contains the RtReports data to administer these
permissions.
Rather, all requests from RtReports users to the PI Server containing RtReports data are
channeled through a single PI Trust connection (defined as "RtReports Server" above). 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 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 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 Server defined when running test reports (defined as
"RtReports Editor" above). This PI Server is the one defined by the currently-tested report
template.

Configuring PI Server Security 87

Product Access Permissions Reference and Configuration Issues

RtWebParts and RtBaseLine Services

Database Security Permission Notes

PIBatch r

PIDBSEC r

PIHeadingSets r

PIModules r,w r: for BLS ProcessID

w: for an administrator
UserID to make
configuration changes
PIPOINT r

PIUSER r

Point Database Permission Notes

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

Module Database Permission Notes

Module Security* r,w r: for BLS ProcessID

w: for an administrator
UserID to make
configuration changes

* Generic Client application permissions that can operate on any module

88
 RtWebParts and RtBaseLine Services

Configuring Security for RtWebParts and RtBaseline Services

When using RtWebParts (RtWP) and RtBaseline Services (RtBLS) there are two user
accounts that come into play:
• UserID—used when connecting the client machine to the RtBLS/RtWP Web server.
• ProcessID—used in the Web server connection to the PI Server
To identify the UserID and ProcessID used in a given session, select the RtBaseline Services
Version option from the RtBaseline Services Administration page. The User Mapping and the
Process Mapping are displayed in the Server Machine Information section.
To take advantage of Windows Integrated Security:
• Both the UserID and the ProcessID need to be valid Active Directory users with at least
one PI Mapping.
• Kerberos must be configured between the RtBLS/RtWP Web server and PI Server
• The client machine must belong to the same Active Directory forest.
For instructions on setting up the Kerberos environment, see the Knowledge Base article:
How to configure RtWebParts or RtBaseline Services to use Windows authentication relying
on Kerberos delegation (http://techsupport.osisoft.com/Support+Solution/7/KB00100.htm).
Configure both the Database Security tables and the rights per module on the PI Server. It is
recommended that the UserID and the ProcessID be members of distinct security groups,
either in Windows or in PI.
An IISRESET is required on the Web server if membership in an Active Directory group
used in a PI Mapping is modified, or if a relevant PI Mapping itself is modified.

Configuring PI Server Security 89

Product Access Permissions Reference and Configuration Issues

Interfaces

Interfaces that Create Points

Database Security Permission Notes

PIPOINT r,w1 r,w: for any

interface that
creates or deletes
points

Point Database Permission Notes

PtSecurity r,w
DataSecurity r,w

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.

90
 Interfaces

PI to PI TCP/IP Interface

Database Security Source PI Receiving PI Notes

Server Server
PIPOINT r r

Point Database Source PI Tags Receiving PI Notes

Tags
PtSecurity r r
DataSecurity r r,w

Configuring PI Server Security 91

Product Access Permissions Reference and Configuration Issues

PI OPC DA/PI OPC HDA Interfaces

Database Security Permission Notes

PIPOINT r

Point Database Permission Notes

PtSecurity r
DataSecurity r,w

92
 Interfaces

Configuring Security for OPC Server

The OPC Server connects to a PI Server using both the PI SDK and PI API. The PI SDK is
used to read data from the PI Server, and the PI API is used to write data to the PI Server.
The following connection options are available for the OPC Server:
• [recommended] Connect to the PI Server via a PI Trust set up with a PI Identity. This will
allow both the PI SDK and the PI API to connect. With this method you can have read
and write access permissions granted to that PI Identity. See How to Create a Trust (page
31) for more details.
• Connect to the PI Server via Windows Security with a PI Identity. Because the PI API
does not support Windows Security, this option only allows the PI SDK to connect;
therefore, the OPC Server will only have read access to the PI Server.
• [recommended] Connect to PI 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 recommended, but slightly more complicated to set up.

Configuring PI Server Security 93

Product Access Permissions Reference and Configuration Issues

PI APS

Database Security PI APS Sync Sync Trigger PItoPI_APS

Configuration Engine
Utility
PIDS None for read- r,w: for r
only mode; automatic
r,w: to set/state
interactively creation
create or edit and edits
digital (for digital
sets/states(for points);
digital points) r: for non-
automatic
modes
PIModules r: to review APS r,w r,w
configuration;
r,w: to change
APS
configuration
PIPOINT None for read- r,w: for r
only mode; automatic
r,w: to point
interactively creation;
create or delete r: for non-
points automatic
modes

Point Database PI APS Sync Sync PItoPI_APS³

Configuration Engine± Trigger²
Utility
PtSecurity r: to display r,w: to r
existing automatical
interface points; ly edit or
r,w: to delete
interactively edit points;
or delete r: for non
interface points automatic
modes
DataSecurity

Module Database PI APS Sync Sync Trigger PItoPI_APS

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

* Generic Client application permissions that can operate on any module

94
 Interfaces

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).
² Synchronization Trigger is also a service and therefore requires some form of automatic log
on. Without write permission for the Module Database, Synchronization Trigger is non-
functional. Synchronization Trigger only uses the Module Database (no point access).
³ The PItoPI_APS Connector requires read permission to points on the source PI Server.
Since PI APS Connectors run inside the Synchronization Engine process, which is a service,
some form of automatic log on to the source PI Server is required. That is, the
Synchronization Engine that is running the PItoPI_APS Connector requires automatic log on
to two PI Servers: the target PI Server and the source PI Server. The method of connection
and the access rights granted do not need to be the same for both PI Servers. The
Synchronization Engine only needs read access to the PIPOINT and PIDS tables on the
source PI 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 Server. For non-automatic modes, only read access is needed (on the
target PI Server).

Configuring PI Server Security 95

Product Access Permissions Reference and Configuration Issues

Configuring Security for PI APS

In order to run PI APS, you must configure the PI Server to allow connections from the
PI APS Configuration Utility, PI APS Synchronization Engine, and PI APS Synchronization
Trigger service. This section provides the information that you need to configure:
• connection methods for the PI APS programs, and
• PI Server security to grant the required access rights to these connections.

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

The PI APS 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 Server. The PI APS Configuration Utility is an interactive application, so you
can use either a PI Trust, a PI Mapping, or an explicit login to a PI Server User account. PI
Mappings are the most secure option; explicit logins are the least secure. Use PI Mappings
where possible (PI Mappings require PI Server version 3.4.380 and PI SDK 1.3.6 or later).

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 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 PI APS Configuration Utility creates the module AutoPointSync under the %OSI
module. PI APS configuration settings are stored in a hierarchy of modules under this
module. Other information also is stored in the modules used by PI APS. For example, the
last synchronization time (stored by the PI APS Synchronization Engine) and the
SyncImmediately flag (set by the PI APS Synchronization Trigger service or PI APS
Configuration Utility) are stored in the AutoPointSync hierarchy.
The PI APS Configuration Utility requires:
• Write access for the PIModules table (Database Security) in order to create modules
• Write access for the %OSI module in order to create the AutoPointSync module
• Write access for the AutoPointSync hierarchy to register interface instances with PI APS,
to change configuration settings, or to manually initiate a synchronization scan. Read
access is sufficient to view configuration settings.
The PI APS Synchronization Engine and PI APS Synchronization Trigger service require
write access for modules in the AutoPointSync hierarchy for normal operation.

Point Database Permissions

To create or delete points, the PI APS Synchronization Engine or PI APS Configuration
Utility requires write access for the PI Server PIPOINT table. To edit points, the PI APS

96
 Interfaces

Synchronization Engine or PI APS Configuration Utility requires write access for individual
points.
The PI APS Synchronization Trigger service does not access the PI Server 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. PI APS needs write access for point
attributes of the points that are associated with interface instances registered for
synchronization.
PI APS does not access point data.

Digital State Table Permissions

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

Configuring PI Server Security 97

Product Access Permissions Reference and Configuration Issues

PI ICU

Database Security Permission Notes

PIDS r,w w: to create

"InterfaceStatus
" digital set if it
does not exist
PIModules r,w

PIPOINT r,w w: to create or

delete Perfmon
Performance
Counter Points,
UniInt
Performance
Points, or UniInt
Health Points

Point Database Permission Notes

PtSecurity r, w

Module Database Permission Notes

Module Security* r,w

* Generic Client application permissions that can operate on any module

98
 Interfaces

Configuring PI ICU
When PI ICU is installed on an Interface node, the PI ICU obtains permissions to access PI
Server objects by logging on with some form of credentials. The PI 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 Server object has access control
information. Authorization for a client program to access a securable PI Server object is
determined by comparing information in the security context with the access control
information for the object.
Several methods are available for logging on:
• Explicit Login
• 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 Server
can be used.
If the PI 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 Server 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 Server 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 Server digital state table (PIDS).
The ICU Controls for some Interfaces have the ability to create specific digital sets that are
needed by the Interface. Since ICU Controls run inside the PI ICU process, the PI ICU
requires write access for the PI 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.

Configuring PI Server Security 99

Product Access Permissions Reference and Configuration Issues

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 Server
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 Server PIPOINT table for an
ICU Control to create points.

100
Appendix C

New SMT Highlights

Here are the highlights of the latest version of PI SMT:
Useful New Features:
How am I connected? SMT now tells you exactly how you are connected to each PI
(What Users, Groups, and Server (whether through a Trust, a Mapping, or an explicit login).
Identities?) The lower left corner contains an information panel with this
information. Click to get more complete information.
How can I connect as a You can now connect as a specific user by right-clicking on a PI
specific PI User? Server in the Collectives and Servers panel. Choose the
Connect As... option. (This will not work if explicit logins are
disabled.)
New Tools

Backup Tool A new tool that allows you to view backup history and run quick
backups (not for scheduling regular backups)
Security Settings Tool A new tool that allows you to choose a security level for PI Servers
(for Server versions 3.4.380 and later only)
Firewall Tool A new tool that allows you to configure the PI Server Firewall

Tool Changes:

Users and Groups tool The Users and Groups tool becomes the Identities, Users, and
Groups tool. When connected to a new-model PI Server (version
3.4.380 and later) it includes a PI Identities tab. The PI Identities
tab does not appear unless you are connected to at least one new-
model PI Server.
Trusts tool The Trusts tool becomes the Mappings and Trusts tool. When
connected to a new-model PI Server (version 3.4.380 and later), it
includes a PI Mappings tab. The PI Mappings tab does not
appear unless you are connected to at least one new-model PI
Server.
Message Log tool The Message Log viewer has been greatly enhanced with new
filtering and searching options and fields.

Configuring PI Server Security 101

Appendix D

Checklist: Configure Windows Authentication for

Upgrades
This table lists the basic steps for configuring an upgraded PI Server for Windows
authentication.
Step Notes
Review Existing Access Permissions See Step 1. Review Access Permissions (page
38)
Create a List of Unique Access Strings See Step 2. Create List of Unique Access Strings
(page 39)

Identify PI Groups and PI Users that will be See Step 3. Create a Configuration Plan (page
retained 41)

Create New Identities to Fill Gaps See Step 4. Create PI Identities to Fill Gaps
(page 43)

If using AD, determine which AD groups are (AD only) See Step 5. Review AD Group (page
needed and which Identities to map them to 43)
If using local Windows security, determine (only if using local Windows security)
which 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 Server and client workstations
Create Mappings See Step 6. Create Mappings (page 44)

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

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

Upgrade the SDK to 1.3.6 or later on Client (required for Windows authentication)
Computers

Configure clients that connect through an (if any) See Products that Connect to an
application server (for example, PI DLES and PI Application Server (page 60)
WebParts)
Upgrade Administrative Applications: See Administrative Client Applications (page 61)
 PI SMT version 3.3.1.3 or later
 Tag Configurator version 2.1.3 or later
 Module Database Builder version 1.2.1.3 or
later
 PI ICU 1.4.7 or later

Configuring PI Server Security 103

Checklist: Configure Windows Authentication for Upgrades

 PI APS 1.2.5.0 or later

Disable explicit logins (Optional) See Disable PI Password

Authentication (Explicit Logins) (page 52)

Replace SDK Trusts with PI Mappings (Optional) Retire SDK Trusts (page 54)

Retire Obsolete PI Users and PI Groups (Optional)

104
Appendix E

Checklist: Configure Windows Authentication for

New Installations
This table lists the basic steps for configuring a new PI Server for Windows authentication.
Step Notes
Identify User Access Categories Identify User Access Categories (page 15)
Create a PI Identity for each Create PI Identities (page 16)
access category (you can also use
built-in Identities, Users, or Groups,
such as piadmins)
If using AD, determine which AD (if using AD) See Review AD Configuration (page 17)
groups are needed and which
Identities to map them to

If using local Windows security, (only if using local Windows security) See Configure
determine which local Windows Windows Groups (page 26)
groups are needed and which
Identities to map them to
If using local Windows security, (only if using local Windows security) See Use Local
configure matching Windows user Windows Security (page 21)
accounts and passwords on PI
Server and client workstations
Create the Mappings for AD: Map AD Groups to PI Identities (page 20)
for local Windows security: Create Mappings (page 27)
Configure access permissions Configure Access Permissions (page 21)

Configure authentication for Configure PI Interface Connections (page 30)

Interfaces

Check custom API applications, if (only for installations with existing clients & interfaces)
any See Check for Unauthenticated API Connections (page
60)
Upgrade the SDK on Client (only for installations with existing clients & interfaces;
Computers to 1.3.6 or later required for Windows authentication

Configure clients that connect (if any) See Products that Connect to an Application
through an application server (for Server (page 60)
example, PI DLES and PI
WebParts)
Upgrade Administrative (only for installations with existing clients & interfaces)
Applications: See Administrative Client Applications (page 61)
 PI SMT version 3.3.1.3 or later

Configuring PI Server Security 105

Checklist: Configure Windows Authentication for New Installations

 Tag Configurator version 2.1.3 or

later
 Module Database Builder version
1.2.1.3 or later
 PI ICU 1.4.7 or later
 PI APS 1.2.5.0 or later
Disable explicit logins (Optional) See Disable PI Password Authentication
(Explicit Logins) (page 52)

106
Appendix F

Technical Support and Resources

You can read complete information about technical support options, and access all of the
following resources at the OSIsoft Technical Support Web site:
http://techsupport.osisoft.com (http://techsupport.osisoft.com)

Before You Call or Write for Help

When you contact OSIsoft Technical Support, please provide:

• Product name, version, and/or build numbers
• Computer platform (CPU type, operating system, and version number)
• The time that the difficulty started
• The message log(s) at that time

Help Desk and Telephone Support

You can contact OSIsoft Technical Support 24 hours a day. Use the numbers in the table
below to find the most appropriate number for your area. Dialing any of these numbers will
route your call into our global support queue to be answered by engineers stationed around
the world.
Office Location Access Number Local Language Options
San Leandro, CA, USA 1 510 297 5828 English
Philadelphia, PA, USA 1 215 606 0705 English
Johnson City, TN, USA 1 423 610 3800 English
Montreal, QC, Canada 1 514 493 0663 English, French
São Paulo, Brazil 55 11 3053 5040 English, Portuguese
Altenstadt, Germany 49 6047 9890 English, German
Manama, Bahrain 973 1758 4429 English, Arabic
Singapore 65 6391 1811 English, Mandarin
86 021 2327 8686 Mandarin
Perth, WA, Australia 61 8 9282 9220 English

Configuring PI Server Security 107

Technical Support and Resources

Support may be provided in languages other than English in certain centers (listed above)
based on availability of attendants. If you select a local language option, we will make best
efforts to connect you with an available Technical Support Engineer (TSE) with that language
skill. If no local language TSE is available to assist you, you will be routed to the first
available attendant.
If all available TSEs are busy assisting other customers when you call, you will be prompted
to remain on the line to wait for the next available TSE or else leave a voicemail message. If
you choose to leave a message, you will not lose your place in the queue. Your voicemail
will be treated as a regular phone call and will be directed to the first TSE who becomes
available.
If you are calling about an ongoing case, be sure to reference your case number when you call
so we can connect you to the engineer currently assigned to your case. If that engineer is not
available, another engineer will attempt to assist you.

Search Support

From the OSIsoft Technical Support Web site, click Search Support.
Quickly and easily search the OSIsoft Technical Support Web site's Support Solutions,
Documentation, and Support Bulletins using the advanced MS SharePoint search engine.

Email-based Technical Support

techsupport@osisoft.com
When contacting OSIsoft Technical Support by email, it is helpful to send the following
information:
• Description of issue: Short description of issue, symptoms, informational or error
messages, history of issue
• Message logs: See documentation for your PI System for information on obtaining
message logs pertinent to the situation.

Online Technical Support

From the OSIsoft Technical Support Web site, click Contact us > My Support > My Calls.
Using OSIsoft's Online Technical Support, you can:
• Enter a new call directly into OSIsoft's database (monitored 24 hours a day)
• View or edit existing OSIsoft calls that you entered
• View any of the calls entered by your organization or site, if enabled
• See your licensed software and dates of your Service Reliance Program agreements

108
 Remote Access

From the OSIsoft Technical Support Web site, click Contact Us > Remote Support
Options.
OSIsoft Support Engineers may remotely access your server in order to provide hands-on
troubleshooting and assistance. See the Remote Access page for details on the various
methods you can use.

On-site service

From the OSIsoft Technical Support Web site, click Contact Us > On-site Field Service
Visit.
OSIsoft provides on-site service for a fee. Visit our On-site Field Service Visit page for more
information.

Knowledge Center

From the OSIsoft Technical Support Web site, click Knowledge Center.
The Knowledge Center provides a searchable library of documentation and technical data, as
well as a special collection of resources for system managers. For these options, click
Knowledge Center on the Technical Support Web site.
• The Search feature allows you to search Support Solutions, Bulletins, Support Pages,
Known Issues, Enhancements, and Documentation (including user manuals, release
notes, and white papers).
• System Manager Resources include tools and instructions that help you manage: Archive
sizing, backup scripts, daily health checks, daylight savings time configuration, PI Server
security, PI System sizing and configuration, PI trusts for Interface Nodes, and more.

Upgrades

From the OSIsoft Technical Support Web site, click Contact Us > Obtaining Upgrades.
You are eligible to download or order any available version of a product for which you have
an active Service Reliance Program (SRP), formerly known as Tech Support Agreement
(TSA). To verify or change your SRP status, contact your Sales Representative or Technical
Support (http://techsupport.osisoft.com/) for assistance.

Configuring PI Server Security 109