Configuring PI Data Archive Security between untrusted domains or in a workgroup

Document created by aabeijon on Apr 22, 2016
Version 1Show Document
  • View in full screen mode

I often come across the question if whether the PI Data Archive can be setup to be accessed within a workgroup, or accessing it across untrusted domains. This is possible, but we recommend having the PI Data Archive and the users on the same domain whenever possible:

3246OSI8 - Can you run the PI Server in a Windows Workgroup

KB00354 - Windows Security Requirements for PI Server 3.4.380.36 and later

KB00833 - Seven best practices for securing your PI Server


If this is not possible, here is an outline of the different types of security that can be used in this type of environment. I will start from the most secure to the least secure option- but first I want to explain the server security slider in SMT:


These are options that can be enabled or disabled to prevent older security protocols from connecting. By default, we will have explicit (legacy) logins disabled on the newer releases of the PI Data Archive. You will have to lower the slider to enable this option.


As an overview here are the 3 methods:

  • Mappings: Uses windows security- NTLM or Kerberos.
  • Trusts: Connection rules using IP, Hostname, or FQDN. Also able to filter out by windows username and application names.
  • Explicit Login: Non-windows usernames and passwords managed on the PI Data Archive. (Legacy)


1. Using Mappings for windows security (Most secure method)

Without a domain or between untrusted domains, this will default to using the workgroup security model, communicating using NTLM. Both usernames and passwords will need to match on both machines. This connection option will use high-level encryption via NTLM. In the example below I have two untrusted domains (DomainA and ABEIJON), but this will also work the same way within a workgroup. To find out more information about how to configure mapping, visit the following video on the YouTube Learning Channel:


Client Machine: (DomainA domain)




PI Data Archive: (ABEIJON domain)





2. Using Trusts

Trusts are typically configured to whitelist certain IPs or a single Hostname. These are more difficult to troubleshoot/identify problem users since you may only be seeing an IP on the inbound connection. You are not limited to whitelisting a single IP, a trust can grant entire subnets of an IP should you desire. In my example below I allow the entire 192.168.x.x subnet pidemo (read-only) access to my test PI Data Archive. For more information of this authentication method, visit the video on our YouTube Learning Channel:


Client Machine:

IP will fall within 192.168.x.x range


PI Data Archive:
Trust Configuration



(This netmask will allow all IPs of 192.168.x.x to connect)



Network Manager Statistics

Additionally, you can tighten the trust to only allow certain OS users:
Or limit it to only allow certain applications:


Alternatively, you can specify a Hostname/FQDN instead of an IP:


     (Leaving the IP and netmask with zeros and having the network path filled will use network path)


3. Explicit Login (Less Secure)

This allows for the creation of (non-windows) user accounts on the PI System. You can use SMT to create accounts, manage passwords, and manage access. You can create PI groups to put these users in and manage access in an easier format. Passwords are sent through the network through low level encryption. For more information on PI Users and PI Groups, visit the following video in our YouTube Learning Channel:

Client Machine:





PI Data Archive:
User creation


PI users




Password Management



4. Blank Passwords (Least Secure)

You can configure the above explicit login accounts to have blank passwords, and all you need to know is the user account to connect. If saved in the SDK, certain applications will not even prompt you for login- (eg. Processbook). Note: Datalink 5+ will prompt you for the username each time, and it will not save the username.