Authentication

Before the PI Server 3.4.380 release, two methods of authentication were available: PI trusts and PI password authentication (also called explicit logins). Starting with PI Server 3.4.380, a third, and the most secure method of authentication becomes available: Windows authentication.

The three models for authentication on a Data Archive are:

• Windows authentication

  

Windows authentication allows users to log onto their Windows accounts and automatically become authenticated on the Data Archive server. Rather than requiring individual user accounts on the Data Archive server, in the new model you define user categories, called PI identities, on the Data Archive server. You then create mappings from groups of Windows users to the relevant user categories. PI identities and PI mappings are new objects in PI Server 3.4.380.

This authentication model provides single sign-on for PI users, requires less maintenance for PI administrators, and significantly increases security over the previous model. Both PI trusts and explicit logins remain as authentication mechanisms on the Data Archive server. However, the use of PI trusts and explicit logins progressively disabled except for backward compatibility with clients lacking support for Windows authentication. For example, a deployment scenario where an Interface node is located on a control system network which doesn't support Windows authentication.

Starting with the with the release of PI API 2016 for Windows Integrated Security, support for Windows authentication is extended to all PI API-based client applications, such as PI interfaces. Before this release, Windows authentication was not available for PI interfaces, even though Data Archive supported it as an authentication model for its users. With PI API 2016 for Windows Integrated Security and PI Server 3.4.380 or later, Windows authentication extends across the AVEVA™ PI System™ to the PI interface node or any other PI API-based application connecting to PI Server 3.4.380 or later, in the following deployment scenarios:

• Interface node and Data Archive on the same computer

• Interface node and Data Archive on the same domain

• Interface node and Data Archive on different but trusted domains

• Interface node and Data Archive on untrusted domains

• Interface node or Data Archive or both in a workgroup

We recommend upgrading your authentication model to Windows authentication from PI trusts or explicit logins for interfaces and other PI API-based client applications for Data Archive to take advantage of the most secure communication method available.

• PI trusts

  Prior to the availability for Windows authentication on PI API enabled by the release of PI API 2016 for Windows Integrated Security, PI trusts were typically used to authenticate PI API-based client applications that ran unattended, such as PI interfaces. Trust authentication works by comparing the connection credentials of the connecting application to the trust records in the trust database. Human intervention is not required at the time of connection.

  PI trust authentication is a weak form of authentication due to potential for fake credentials. Windows authentication offers more defenses and is the recommended approach for assuring PI Data Archive connections are legitimate.

  PI trusts are still available as a method for authenticating PI interfaces, or any other PI API-based client application. However, the use of PI trusts for interfaces should be reserved to cases where Windows authentication cannot be used.

  Note: PI API 2016 for Windows Integrated Security does not support PI trusts or explicit logins. Before upgrade, PI Mappings to a Windows logon or service account must be configured on the PI Data Archive to avoid any potential data loss.

• Explicit logins

  

  Users connecting to Data Archive through client applications were typically authenticated through explicit logins, which means that the user logs on to Data Archive by typing in a PI user name and password. Explicit logins have a number of drawbacks: They require users to log in separately to Windows and to Data Archive; they require system managers to maintain separate user accounts for every user on Data Archive; and they are not especially secure.

  Although the password mechanism performs as designed, public vulnerability disclosure CVE-2009-0209 is a weakness due to the use of a proprietary cypher developed in the 1990s that has been deprecated in favor of industry standard cryptography and password management policy enforcement by the Windows operating system. In short, explicit login as an authentication method is not secure from malicious actors.