Follow-up steps

After you have an initial Data Archive server configuration, you can continue to transition to the new model over time. This section discusses some measures that you should take.

• Check custom PI API applications

  A security loophole in earlier versions of the Data Archive server allowed world access to PI API connections, even if the authentication failed. You could disable that access explicitly but if you did not disable it, then you might currently have PI API applications that rely on this loophole. Current versions of the Data Archive server permanently disable that access and any applications that rely on that access will no longer have access to the Data Archive server. You will need to configure authentication for these applications. (This is typically only a problem for custom PI API applications.) See Check for unauthenticated PI API connections.

• 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 dministrative tasks (see Understand how to protect piadmin in PI SMT).

• Upgrade the SDK on client computers

  On computers running client applications, upgrade PI SDK to PI SDK 2016 to utilize Windows authentication and transport security. PI SDK version 1.3.6 and later support Windows authentication but not transport security. Versions earlier than 1.3.6 of the SDK do not support transport security nor Windows authentication.

• Configure application server clients

  If you are using applications where the client is accessing the Data Archive 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 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 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 Data Archive server authentication method and it is best to disable it entirely or at least partially. See Learn how to disable PI password authentication (explicit logins) for more information.

  Note: Remember that support for transport security and Windows authentication requires PI SDK 2016, while 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 Data Archive server will no longer use existing trusts anyway (see Learn about retiring SDK trusts).

• 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 Data Archive 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 Data Archive server). Additionally, PI users have associated passwords that are not secure. Ideally, you should plan to replace your PI users and PI groups with descriptively-named PI identities.

To further improve security, see Tightening security.