Troubleshooting User Authentication Issues Across Multiple Domains in PI System Environments

Managing user authentication across multiple domains in an OSIsoft PI System environment can be a challenging task, especially when dealing with complex configurations such as DMZ servers and one-way external trusts. In this blog post, we'll delve into a common scenario involving authentication issues and explore solutions that can help ensure smoother cross-domain access to AF databases.

Scenario Overview

Imagine you have a simple website deployed on a DMZ web server, configured to use Windows Authentication. The website is intended to display all databases under a specified AF server. However, the setup spans two separate domains:

1. DMZ Domain: Where the web server and PI AF Server reside.
2. CORP Domain: Where the user accounts, such as CORP\corpuser, are managed.

The setup utilizes a one-way external trust from the CORP domain to the DMZ domain. This trust allows CORP\corpuser to access AF databases directly via PI System Explorer and PI Vision, albeit with some latency. However, when attempting to access the databases through a custom web application using the AF SDK, intermittent errors occur, specifically: "Cannot connect to server ‘DMZ AF Server’".

Diagnosing the Issue

The error message suggests a problem with connectivity to the remote PI AF Server, or with the delegation of the impersonated client user. Here are some steps to consider when diagnosing this issue:

1. Review SPN and Delegation Settings

Service Principal Names (SPN) and delegation are critical for Kerberos authentication. Although the IT team has confirmed that SPN and delegation are set up correctly, it’s essential to ensure that the configurations match those of PI Vision, where access is successful.

• SPN Registration: Verify that the SPNs for the AF Server service account are correctly registered. This can be done via the setspn command.
• Delegation Setup: Check that the web application’s service account is configured for the correct type of delegation (e.g., “Trust this user for delegation to specified services only”).

2. Consider Alternative Authentication Trusts

It’s important to be cautious with the use of one-way external trusts, as they can introduce complications with Kerberos delegation. Instead, consider:

• Implementing a two-way trust if organization policies permit.
• Using other authentication mechanisms supported by OSIsoft, such as certificates for HTTPS connections.

3. Monitor Network and Firewall Configurations

Network misconfigurations, such as improper firewall settings, can also contribute to connectivity issues:

• Ensure that the necessary ports for AF SDK communication are open between the CORP domain and the DMZ.
• Verify network latency and conditions to improve response times when accessing the databases.

Conclusion

Troubleshooting cross-domain authentication issues requires a thorough examination of network configurations, trust relationships, and authentication setup. By aligning your web application’s settings with proven configurations, such as those used in PI Vision, and refining your domain trusts and network settings, you can enhance the reliability of your PI System projects.

For more detailed guidance, consider reviewing KB01709, which provides insights into managing Kerberos delegation across domains. By understanding these fundamentals, OSIsoft PI System administrators and developers can better navigate the complexities of domain-based authentication.