André Åsheim

PI Security

Blog Post created by André Åsheim Champion on Dec 11, 2014

Setup security on a new PI environment. As simple as this might sound it's absolutely not straight forward.

 

First of all, plan what you are doing.

Secondly, Do not take any shortcuts during the installation and testing. The cleanup afterwards takes more time than you would have used to set it up correctly the first time.

 

Preparation tasks

Who should have access to what

PI Administrators, should have administrative access to everything

PI Users, should only work as a base group, logon only

Site X Read/Write, should be provide access to it's site and it's site only.

 

Service Accounts

AF_Service (AF server and Analysis service)

PINO_Service (PI Notifications Scheduler Service)

PIWebAPI_Servcie (PI WebAPI service)

PIBuffer_Service (runs the PI Buffer Subsystem service on all servers that sends data to PI)

Interface_XXX_Service (one service account for each interface)

 

Create AD groups

We started up with creating the two main AD groups that will be the base of the security model.

PI Administrators

PI Users

Site 1 Read/Write

Site 2 Read/Write

 

The PI Administrator group should give full administrative access to any PI component in the network. Local Administrators (and local users on the PI Data Archive) should NOT get access to the PI Environment.

PI Users group is a base group that should only provide a valid login to the PI environment. On the AF server this would mean that they can connect, and read the top level structure (which does not contain any data). On the Data Archive server this should only provide login, not able to read any tag/data etc.

 

The "Site X Read/Write" groups should only give access to the sites PI tags and AF structure. They should not be able to read data from ANY other site or data source, including other AF Databases, elements in the same database that's not part of it's site.

 

Asset Framework Security

What we discovered in the AF security model is that it somehow uses "and" security for both read and write operations.

We couldn't just give access to create element (write) directly on the parent element, the group needed to have access to write on the database level as well.

 

The AF security by default is poor. When would you ever give "Everyone" access to read your production data?

I'd like if AF did the same thing as Coresight on a new installation. Create a local group "PI AF Users" which is mapped into AF, replacing the existing default security where Everyone have access.

What would been even better is that they also created a "AF Administrator" group replacing the existing "Local Administrator". Why should the IT maintenance have full access, shouldn't this be restricted to only the users that absolutely need it?

 

 

PI Data Archive Security

The PI Data Archive security is not exactly simple.

 

Disable API trusts.....

Sorry we couldn’t do this. We tried and failed. We are importing most of our data using self-developed interfaces that only uses windows authentication, and we are using OSIsoft interfaces to backfill older data.

I thought that we could be able to disable the API trusts when the backfilling was completed but what we discovered surprised me.

PI Notifications was the major party pooper (if I'm allowed to say). It turn out that PI Notifications is able to create it's tags with Windows authentications (SDK) and the notifications starts and runs as normal, it even sends the notifications as expected. But what it didn't do was to save the history. It turs out that PI Notifications uses API to write data to PI. So we had to enable API trusts again and create a trust for PI notifications (application name "PIAnE")

PI Backup also requires PI trust due to it's use of PI Diag. This we could have worked around by running a third party backup solution, but when we first needed to enable the API trusts again we figured out that the best way was to use the built-in backup solution.

 

Yeah, I disabled !Proxy_127! trust, still working, still running and most important, People that logon to the server don't get access to the PI server. As a backup I created a local group and mapped that to piadmin.

 

PIPOINT database access

In order to list tags the user needs access to the top level PIPOINT database. This is easier said than done.

As I mentioned earlier, we have different sites which shouldn't have access to each other’s data. So what we ended up doing is not removing "PIWorld" from the default security, because the users should have access to list the tags.

We are now creating tags that PIWorld has access to and then we are replacing PIWorld with the sites user-groups.

 

Kerberos authentication

In order to use Kerberos authentication we did the following configuration changes on the service/computer account

PI Server

Server name: PI_Server01$  - Allow Computer for delegation to any service

SPN "PIServer/PI_Server01" and "PIServer/PI_Server01.domain.com" (FQDN)

 

AF Server

Service account: AF_Service - Allow User for delegation to any service

Server: AF_Server01

SPN "AFServer/AF_Server01" and "AFServer/AF_Server01.domain.com"

 

PI WebAPI

Service account: PIWebAPI_Service - Allow User for delegation to any service

Server: AF_Server01

SPN "HTTPS/AF_Server01" and "HTTPS/AF_Server01.domain.com"

 

IPsec

  1. Well.. We entered the planning stage on this step but figured out that it might was a bit overkill

But if you're interested in configuring IPsec, send me a message! Andre Johnsen

 

Nice to have

AF: Not use Everyone and local administrator as default security on new/clean installations

PI Notifications: Write data with SDK!

PI Buffer Subsystem: Impersonated buffer writes

PI Data Archive: Backup that does not require API trust

Outcomes