Skip to content
Software AthleteSoftware Athlete
0
Configure Kerberos Authentication & Delegation for PI Vision & PI Web API

PI System administration guide

Configure Kerberos Authentication & Delegation for PI Vision & PI Web API

Configure Windows authentication, HTTP service principal names (SPNs), and constrained delegation so PI Vision and PI Web API can authenticate users and reach PI AF Server and PI Data Archive.

Updated September 1, 2026 · Originally published May 9, 2024 · Reviewed by Software Athlete PI System engineering

Before you begin

This procedure applies to Windows Integrated Security deployments. It does not apply when end users authenticate only through OpenID Connect. Follow the PI Vision Installation and Administration Guide for your installed version when its service names or account model differ from the examples below.

Prerequisites

  • A stable short hostname and fully qualified domain name (FQDN) for each PI Vision or PI Web API endpoint that clients use.
  • A chosen service identity: the default machine account, a dedicated domain account, or a group Managed Service Account (gMSA).
  • Permission to change IIS, Windows services, PI Web API configuration, and Active Directory SPNs and delegation.
  • The actual AFServer and PIServer SPNs for every PI AF Server and PI Data Archive that the web tier must access.
  • A maintenance window to restart the affected application pools or services and a non-administrator test account with representative PI permissions.
Security boundary: Use constrained delegation to the required backend SPNs. Do not enable unconstrained delegation as a troubleshooting shortcut. SPNs and delegation also do not grant PI permissions; the user or mapped identity still needs the required AF and Data Archive access.

Kerberos has two hops: the browser authenticates to the HTTP endpoint, then PI Vision or PI Web API delegates the user identity to PI AF Server or PI Data Archive. Test those hops separately.

1. Confirm the service identity and endpoint names

Record the account used by the PI Vision application pools and the PI Web API Windows service. Also record every hostname users and applications enter, including DNS aliases.

  1. In IIS Manager, open Application Pools and note the identities for the PI Vision application pools.
  2. In the Windows Services console, open the PI Web API service and note the account on the Log On tab.
  3. Resolve each client-facing name in DNS and decide whether users will use the short name, FQDN, or an alias.
  4. Confirm that the client, web server, domain controllers, AF Server, and Data Archive have synchronized time.

If PI Vision and PI Web API share one hostname, the account that owns its HTTP SPN must match the service design. Do not register the same HTTP SPN on two accounts.

IIS application pool identity configured for PI Vision
Record the identity of each PI Vision application pool before creating SPNs or delegation entries.
Windows Services console showing the PI Web API service account
The PI Web API service identity must match the account design used for HTTP SPNs and backend delegation.

2. Configure PI Vision Windows authentication in IIS

  1. Select the PIVision application in IIS Manager and open Authentication.
  2. Enable Windows Authentication. Disable Anonymous Authentication for this Windows-authenticated application unless your documented design requires it.
  3. Open the Windows Authentication providers and place Negotiate before NTLM.
  4. Keep Enable Kernel-mode authentication selected.
  5. Open Configuration Editor, select system.webServer/security/authentication/windowsAuthentication, and set useAppPoolCredentials to True when PI Vision uses a custom domain account.
  6. Apply the change and recycle the affected application pools or restart IIS during the maintenance window.
Why both settings matter: With a custom application-pool identity, useAppPoolCredentials=true lets IIS use that identity to decrypt the Kerberos ticket while retaining kernel-mode authentication. Disabling kernel mode is an alternative workaround, not the preferred companion setting.
IIS Windows Authentication settings with Negotiate before NTLM
Verify that Windows Authentication is enabled, kernel mode remains enabled, and Negotiate precedes NTLM.
IIS useAppPoolCredentials setting enabled for PI Vision
Set useAppPoolCredentials to True when the PI Vision application pools use a custom domain account.

3. Enable Kerberos for PI Web API

Confirm the PI Web API service runs under the intended account, then check its authentication configuration in the AF Configuration database.

  1. Open PI System Explorer with permission to edit the configuration database used by PI Web API.
  2. Open Configuration\OSIsoft\PI Web API\<instance>\System Configuration.
  3. Open AuthenticationMethods and confirm that Kerberos is present.
  4. Apply the change according to the administration guide for the installed PI Web API version, then restart the PI Web API service if that version requires it.
Do not mix authentication methods casually: Multiple allowed methods can change how browsers or clients authenticate. Keep this guide's test endpoint Kerberos-only unless your documented client design requires another method.
PI Web API authentication methods configuration including Kerberos
Check the configuration for the target PI Web API instance, not a different instance in the same AF Configuration database.

4. Register the HTTP SPNs

Register each client-facing HTTP name on the account that runs the corresponding web service. The SPN class remains HTTP even when users browse to an HTTPS URL.

Check for existing owners before adding anything:

setspn -Q HTTP/<web-short-name>
setspn -Q HTTP/<web-fqdn>

Then add the required names with -S, which checks for duplicates:

setspn -S HTTP/<web-short-name> <domain>\<service-account>
setspn -S HTTP/<web-fqdn> <domain>\<service-account>

If clients use a DNS alias, register the SPN for the name they actually enter and follow the alias guidance for the installed PI Vision version. Verify the final registration with:

setspn -L <domain>\<service-account>
setspn -X
Expected result: Every HTTP name used by a client resolves to exactly one SPN owner, and that owner matches the service identity design.
Active Directory service account with HTTP SPN configuration
Inspect the SPNs on the service account and confirm that short names, FQDNs, and required aliases are neither missing nor duplicated.

5. Configure constrained delegation to PI AF Server and PI Data Archive

  1. Open the web-tier service account in Active Directory Users and Computers.
  2. On the Delegation tab, select Trust this user for delegation to specified services only.
  3. Select Use any authentication protocol when protocol transition is required. This allows the web tier to delegate even when the first hop falls back to NTLM.
  4. Add the AFServer SPNs for each PI AF Server the application must access.
  5. Add the PIServer SPNs for each PI Data Archive the application must access.
  6. Apply the change and allow time for Active Directory replication before testing.

Select the computer account when the backend service runs under its machine identity. Select the backend service account when AF Server or PI Network Manager runs under a custom domain account. Confirm the owner with setspn -Q instead of guessing.

gMSA exception: A group Managed Service Account may not show the same Delegation tab. In that case, have the domain administrator set protocol transition only when required and populate msDS-AllowedToDelegateTo with the verified AFServer and PIServer SPNs. Do not copy placeholder SPNs directly into production.
Active Directory constrained delegation settings for backend PI services
The allowed services should contain only the required AFServer and PIServer SPNs for this deployment.

6. Configure the client for integrated authentication

Use Group Policy where possible so all supported clients apply the same intranet authentication settings.

  1. Add the actual PI Vision and PI Web API URLs to the Windows Local intranet zone.
  2. Confirm the browser is allowed to use integrated Windows authentication for those URLs.
  3. Close and reopen the browser.
  4. Browse with the same hostname used in DNS and the HTTP SPN. Do not switch between an alias, short name, IP address, and FQDN during one test.
Windows Local Intranet zone containing the PI Vision and PI Web API endpoints
The browser URL, DNS record, and registered HTTP SPN must refer to the same endpoint name.

7. Verify both Kerberos hops

Sign in from a separate client computer with a representative non-administrator account. Test one AF attribute and one PI Point before opening a complex PI Vision display.

  • Open PI Vision or the PI Web API endpoint with the registered hostname and confirm there is no unexpected credential prompt or HTTP 401 response.
  • Run klist on the client and confirm an HTTP/<web-name> service ticket exists.
  • Request one AF-backed value, then inspect PI System Explorer → File → Server Properties → Connections and confirm the expected user and Kerberos authentication.
  • Request one PI Point value, then inspect PI System Management Tools → Operation → Network Manager Statistics and confirm the expected identity and Kerberos path rather than an unintended PI Trust fallback.
  • Repeat the test with every supported hostname and with a representative account from each relevant user group.

If the HTTP ticket is missing, fix the client-to-web-server hop first. If the HTTP ticket exists but AF or Data Archive access fails, inspect constrained delegation, backend SPN ownership, and PI permissions.

Symptom Check first Likely boundary
Credential prompt or HTTP 401 Local Intranet policy, Negotiate order, hostname, HTTP SPN, and duplicate SPNs Client to web server
PI Vision opens but AF or PI data fails Delegation entries, backend SPN owner, service identity, and PI permissions Web tier to backend
Short name works but FQDN or alias fails DNS resolution and the HTTP SPN for the exact URL hostname Endpoint naming
Authentication falls back to NTLM klist, Negotiate order, SPN ownership, and kernel-mode/application-pool credential settings Kerberos ticket negotiation

Troubleshooting

No HTTP ticket appears in klist: confirm the client uses the registered hostname, the URL is treated as Local intranet, Negotiate is enabled, and setspn -Q HTTP/<name> returns the intended account.
Kerberos works after disabling kernel mode: restore kernel mode, set useAppPoolCredentials=true, recycle the application pool, and retest. Keep kernel mode disabled only when the installed-version guidance or a documented infrastructure constraint requires that alternative.
AF fails but PI Point data works: query the AFServer SPNs, confirm the correct AF service account or computer account is in the delegation list, and verify AF database permissions.
PI Point data fails but AF browsing works: query the PIServer SPNs, confirm the correct Data Archive service identity is delegated, and check mappings, trusts, and point permissions.
The gMSA has no Delegation tab: inspect TrustedToAuthForDelegation and msDS-AllowedToDelegateTo with the Active Directory team. Do not switch to unconstrained delegation.

Reference documentation

Continue reading
Synchronise Navigation Menu across displays
Read more
Navigation Menu+ synchronized across PI Vision displays using a shared AF attribute configuration store
Leave a comment

Your email address will not be published..

© 2026 Software Athlete, All rights reserved.

Cart 0

Your cart is currently empty.

Start Shopping
Trending Now