With the release of PI API 2016
for Windows Integrated Security, it is now possible
to authenticate PI API connections using
PI Mappings with Windows Integrated Security instead of less
secure PI Trusts. To demonstrate how to
implement PI API for Windows Integrated Security in a simple environment
let's upgrade an existing interface
node to use the PI API for Windows Integrated Security.
For additional information including
system requirements, please refer to the on screen alert
and Knowledge Base article. Also please note
PI API for Windows Integrated Security requires PI
Server 3.4.380 or later.
Let's start by looking at the current setup of our
interface node PI Int01.
We have two
interfaces running on PI Int01,
random and rampsock sending data to our PI
Data Archive PISRV01. However
these could easily be the PI Interface for OPCDA,
OPCHDA, RDBMS or
any other interface or PI API application
that authenticates to the PI Data Archive using an
API connection. Let's click on tools
and buffering and check the status of our buffer.
We can confirm that our buffer is healthy and sending data with no events
in queue.
Finally let's check the current version of our
PI API by going to programs and features.
As you can
see, this computer has
the 64 bit version of PI API installed. But
you may also have the 32 bit version as
well. Our PI API version is 1.6.8.22
which is before the PI
API 2016 for Windows Integrated
Security which is v2.0.1.35. So I
expect our connections to the PI Data Archive
to be authenticating using PI Trusts. To check this, let's
go over to the PI Server and open System
Management Tools.
Go to operation,
network manager statistics and we'll sort by peer
address.
I know that my
interface node ends with an IP address
of .5 and I can see that I have four connections.
PI Buffer Subsystem,
two interfaces and PI ICU. If I
scroll to the right I can see how they are
connecting. I can see that they are all
coming in with the PI Trust, PI INT01
and are receiving the identity PI Admin. Also at
this time, let's confirm the data
flow. I'll check current values for
my tags from this interface.
And I can see that they are receiving
current timestamps.
Let's summarize our overall
starting setup and where we would like
to end up. On our interface
node, we have API applications random
and ramsoke as well as an SDK application,
PI Buffer Subsystem. They are currently both authenticating with
Trusts and receiving the identify PI Admin.
We would like our API application to use a mapping.
To do this, we will require an upgrade to the
PI API for Windows Integrated Security.
And as a best practice, we would also like our SDK application to use a
mapping. We will also setup minimum
permissions required for the interfaces and buffer.
Note that the PI API for Windows Integrated Security
is not required to configure the
SDK application to authenticate using a mapping.
However we will configure this since it is a best
practice. Let's take a look at the steps that we will use to
complete this.
First, we will determine what identities we need
to create. We will also provide these
identities with the minimum permissions on the PI Data Archive.
This includes the PI Point table, Point
security and Data security on the individual
tags. To complete this, we will use the
KB Seven best practices for securing your PI Server.
We will map the identities to service
accounts that will be used to run the interface and
buffer. And we will change the interfaces and
buffer to run as service accounts. We will install the
PI API for Windows Integrated Security on PI INT01,
our interface node. And also disable the
open trust that was used previously. Finally,
we will verify the interfaces and buffer connections
and data flow. Let's
that are required by taking a look at this
KB.
Best practice
number five includes information on configuring the minimal
permissions for interfaces. If I continue to scroll down,
I can find our specific scenario where
we have an interface with buffering but no output points.
I can see that the required permissions for the interface
and buffer are different. And since I want to configure
minimum permissions, I will need to create an identity for the
interface and a separate identity for the buffer. To do
this, let's go to the PI Data Archive machine.
Go to security.
Identities. And we'll create these
two new identities.
First we'll create one called PI
Interfaces.
And another called PI Buffers.
As a best
practice, I'm also going to disable PI World because all
users attain this identity by default. I
know this is safe for me to do since I do not have
any users who currently use PI World to receive their permissions to the
PI Data Archive.
Next we are going to provide these identities with the
minimum permissions on the PI Data Archive. Let's take a
look at the KB and the specific permissions
needed. First the interface identity will need read access
to the PI Point table.
This
is completed under database security.
And here is the PI Point table. I'm
going to add PI Interface's
Identity and provide it with read
access.
Next the interface needs read
permissions on Point Security. To
start configuring the tags, I'm going to select one tags
to do the permission changes on.
I'm going to search by my Point Source to
find one tag.
Under security, point security,
I'm going to add PI interface identity.
And make sure that this interface
has read permissions.
Also buffering needs write permissions
on data security.
I'll do this under data
security,
add my identity
and be
sure to give it write permissions.
I also need to hit
save
and notice the confirmational message at
the bottom that says Sinusoid
has been successfully edited.
Now let's use PI Builder in
Excel to change the security settings on all
the other tags.
I'm going to search by Point
Source because I know which tags are required to be
changed based on their interface point source.
I'm going to do this for point source R, 9 and L because I
know for my particular
interface setup, those are the tags that need to be
changed. I'm also going to add data
security and point security since those need
to be edited. I
will then publish these changes
using edit. I
will do this for my other point sources as
well.
Now
let's go to System Management Tools to check one of
the tags that we updated using PI
Builder. I'm going to search for a tag
with point source L. And
here you can see that the point
security is updated to have read access for PI Interfaces,
and PI Buffers is
updated to have write access for data
security.
We will be using service accounts to run the PI Interfaces
and Buffer. Leaving an application
to run as local system results in a large
surface area in Windows for attacks. We would like to
minimize this risk by using dedicated service accounts with least
permissions on the machine. This will also allow
us to identify the interfaces and buffer
as they need different permissions
during authentication. Let's first map those service
accounts to their appropriate identities using
mappings.
We go to System Management Tools, Security,
Mappings and Trust. We'll
create a new mapping and map it to the
Windows domain group that contains our service
account for the interfaces.
We will then map this to the
identity PI Interfaces which has the
correct permissions on the PI Data
Archive.
We will do the same for the PI Buffers
domain group.
And map to the PI Buffers
identity. We
will also create a new mapping for
student 01. This is the user logged into the
PI Interface machine and needs to
use PI ICU.
I'm going to provide this
user with PI Admin's privileges.
Next we are going to change the interfaces
in Buffer to run as service accounts. Let's go over to
PI Int01 and take a look at the current
settings.
Notice that the interfaces are
running as local system. For your specific interface
or API application, before
changing this account, you need to understand if there are any
other configuration changes required. As an example,
for the PI Interface for OBCDA,
this security setting may also affect access to your
OBC Server or your DCOM settings. Please refer
to your interface specific docuementation for
details. Let's change this service account at this
time. I do this by right clicking, going to
logon as and choose the service
account that I would like to use.
And I will do the same for
the other interface.
Notice that in our case, PI
Buffer Subsystem is already running as a service account.
So I do not need to change it. A service
account should be used so the buffer can authenticate to the PI Data
Archive using a mapping and also
identify itself and be authorized for specific permissions.
Before changing the service account on your
buffer, please refer to the buffering user guide since additional
security changes are required. At this point,
let's restart the interfaces to apply the changes
to the service account.
It is a good idea to go to the
PI Data Archive node to confirm that we are still
receiving data flow before we upgrade the PI
API for PI Windows Integrated Security.
This is important for such interfaces as PI OPCDA
because this could affect your security settings to
access your data source.
In System Management
Tools, I'll go to current values and refresh and
confirm that I did receive new data from the interface
restart.
We are now ready to upgrade to
PI API for Windows Integrated Security. This installation
kit is available from the tech support website as a separate
installation package.
Right click PI API 2016
for Windows Integrated Security and run as
administrator on your interface node.
You must acknowledge that you understand that this will disable the
use of trusts for all PI API connections
from this node including interfaces and
any custom API applications.
Note that prior
to installation, some running services
may be shut down and in our case, this
does include our buffer and our two interfaces.
Notice that our two interfaces
and Buffer Subsystem restarted after the installation.
This is important since this restart resulted
in them re-authenticating to the PI Data Archive
after the installation.
Now that the installation is
complete, let's disable the Open Trust PI INT01.
We will do this on the PI Server machine
under security, mappings and
trusts. Go to properties and disable the
trust.
Finally let's verify our interface and
buffer connections as well as data
flow.
First let's start by going into
ICU and checking the buffer
from the interface node.
You can see that we are sending data with no events in
queue.
We can check how the interface and buffer
re-authenticated by going to Network Manager Statistics. Clicking
refresh and again
sorting by IP address. We notice here that we have
PI Buffer and our two interfaces currently authenticating
to the PI Data Archive. If we
scroll to the right, we can see that they are receiving the identity
PI Buffers and PI Interfaces and are authenticating
using their Windows credentials.
If the buffer had still used the
PI Int01 trust, at this point we would
want to restart the PI Buffer Subsystem again to
force it to use the identity after
we disable that trust. Finally we want
to check our data
flow. Go to data, current values and refresh and
confirm that we are receiving current data
after the interface restarts after the PI
API for Windows Integrated Security was
installed. If you have
configured all connections to the PI Data Archive to use
Windows Integrated Security, you can consider
raising your security slider to the highest
level. Note that when this is done, you can no longer
authenticate to the PI Data Archive using the
loop back trust. Also, to continue to
use local interfaces such as PI Performance Equation
Scheduler or any other local applications
using PI API to connect to the PI Data
Archive, the PI API for Windows Integrated
Security must be installed locally on the PI Data
Archive machine.
With the release of PI API
2016 for Windows Integrated Security, PI API
connections are now able to authenticate to the PI Data
Archive using mappings through Windows
Integrated Security. PI API connections now share security
parity with AF client based applications, greatly
improving the security of your PI System by protecting the
integrity and privacy of data communications.
Additional resources can be
found in the PI Data Archive security configuration
guide, the buffering user guide,
and the KB Seven best practices for securing your PI Server.