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.
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.
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.
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.
In order to use Kerberos authentication we did the following configuration changes on the service/computer account
Server name: PI_Server01$ - Allow Computer for delegation to any service
SPN "PIServer/PI_Server01" and "PIServer/PI_Server01.domain.com" (FQDN)
Service account: AF_Service - Allow User for delegation to any service
SPN "AFServer/AF_Server01" and "AFServer/AF_Server01.domain.com"
Service account: PIWebAPI_Service - Allow User for delegation to any service
SPN "HTTPS/AF_Server01" and "HTTPS/AF_Server01.domain.com"
- 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