Service accounts, Kerberos and gMSA in PI System environments

Meta description: Practical guidance on PI System service accounts, Kerberos and gMSA in Active Directory: design choices, pitfalls, and a hardening checklist.

PI System outages rarely stem from a single “authentication is broken” event. They usually result from early identity decisions made for expedience—shared local admin, a domain user with a non‑expiring password, or “whatever works” as the service identity—becoming difficult to unwind. Months later you face intermittent trust failures, double‑hop issues, or audit questions about who performed which actions.

This article targets PI administrators, engineers and OT/IT architects. It explains how Kerberos behaves in practice, the trade‑offs between local accounts, domain users, MSA/gMSA, and practical gMSA design patterns that reduce risk and operational toil.

For broader context on how identity fits into controls such as segmentation, patching and monitoring, see the PIAdmin pillar on securing the PI System: Securing the AVEVA PI System in Modern Enterprise Environments

Why service accounts matter in PI deployments

The PI System is a collection of services—PI Data Archive, PI AF Server, PI Analysis, PI Notifications, PI Web API, interfaces, connectors and custom integrations. Each service identity determines:

• file and registry access,
• the ports it can bind to,
• whether it can use Windows integrated authentication,
• what remote systems it can access.

Operational goals that must be balanced: least privilege to limit impact of compromise; reliability so password changes don’t break data flow; and traceability so actions can be attributed. Choice of local account, domain user, MSA or gMSA directly affects all three.

Key components: AD, SPNs, Kerberos and NTLM fallback

Kerberos is preferred for integrated Windows authentication because it supports mutual authentication and avoids resending reusable secrets. Kerberos succeeds only when a few conditions align:

• the client can reach a domain controller and is in a trusted domain,
• DNS resolution matches the Service Principal Name (SPN) registered in AD,
• the service runs under an account that can decrypt the ticket (SPNs are tied to the account), and
• the client uses the exact name (short name, FQDN or alias) the SPN expects.

If any condition fails, Windows commonly falls back to NTLM or the connection fails outright depending on policy. Symptoms in PI estates include “works from this machine but not that one”, “works with short name but not FQDN”, or the classic double‑hop (works when RDP’d to the server but not from the desktop).

Kerberos is not a PI switch—its correctness depends on Windows/AD configuration and consistent naming. DNS aliases, load balancers, or changing a service account without cleaning up SPNs commonly break it.

Service account options and their implications

Local accounts (including LocalSystem, NetworkService, LocalService)

• Pros: simple, usable on non‑domain interface nodes without AD connectivity.
• Cons: identities don’t traverse the network. If a service must authenticate to remote SQL, file shares or Windows services with integrated auth, you end up embedding credentials elsewhere or granting excessive local privileges. LocalSystem often accretes privilege and should be used only when the host is strongly hardened and tightly scoped.

Traditional domain user accounts

• Pros: familiar, works with Kerberos and network resources.
• Cons: password lifecycle and rotation are operational burdens. In OT environments this often yields “password never expires”, which is a compliance and security risk. Common anti‑patterns: reusing a single account across services, temporary Domain Admin elevation, or adding the account to local Administrators to avoid proper privilege design.

MSA and gMSA (Managed Service Accounts)

• Purpose: Windows‑managed passwords rotated automatically. A standalone MSA is tied to one computer; a gMSA is designed for multiple hosts and is managed by AD.
• When gMSA makes sense: Kerberos is required, you want to remove manual password duties, you run the same service across multiple nodes, or you need stronger auditability.
• Constraint: organisational buy‑in and host prerequisites. Servers must be domain‑joined and able to contact a domain controller to retrieve the managed secret.

Where Kerberos appears in PI “real life”

PI Web API and web tiers

• Typical chain: browser → web server → PI Data Archive/AF → SQL Server. If the web tier must access backend systems on behalf of the user you need Kerberos end‑to‑end and a deliberate delegation model; otherwise backend calls use service accounts and the authorisation model changes.

AF Server and SQL Server

• AF uses SQL Server. If AF uses integrated authentication, the AF service identity and correct SQL SPNs matter. Incorrect or duplicate SQL SPNs often masquerade as AF instability.

Interfaces and connectors

• Interfaces using OPC DA/DCOM, AD‑integrated message brokers, file ingestion or custom .NET code may require Kerberos. Often the first barrier is account hygiene; gMSA helps where the same interface pattern is widely deployed and you want to avoid distributing secrets.

gMSA design patterns that hold up in audits

A defensible gMSA design should be understandable to both auditors and on‑call engineers: “This identity runs this service on these hosts, it can do these actions, and no one knows a human‑managed password.”

Guidelines

• One gMSA per service boundary, not per server. Use separate gMSAs for different services on the same host to limit blast radius.
• Grant minimal rights: “Log on as a service” and only required file/registry permissions. Avoid local Administrators membership unless justified and mitigated.
• Limit AD retrieval scope: explicitly list the computers permitted to retrieve the gMSA secret. This is often overlooked but vital to prevent unintended hosts from using the identity.
• Treat SPNs as deployment artefacts: register SPNs against the gMSA when inbound Kerberos is needed and avoid duplicates. Duplicate SPNs cause intermittent authentication failures that surface after changes.

Common mistakes observed in PI estates

• Using DNS aliases or load‑balanced names without aligning SPNs. Kerberos matches names literally—alias versus actual hostname matters.
• Reusing one domain user for all PI services. It simplifies setup but creates a single point of lateral movement and destroys accountability.
• Assuming gMSA is a magic fix while ignoring operational prerequisites. If servers cannot reliably contact a DC (common in segmented OT zones), gMSA can be brittle. Align identity with connectivity, not policy alone.
• Beginning Kerberos troubleshooting by tweaking PI settings. Start with Windows fundamentals: domain trust, time synchronisation, DNS, SPNs and whether the service account matches the registered SPNs.

Hardening checklist (identity‑focused, PI‑relevant)

• Prefer managed identities where feasible. If AD supports gMSA and hosts can reach a DC, gMSA is typically safer than long‑lived domain passwords.
• Separate identities by function. Differentiate accounts for PI Data Archive, AF, web tiers and interfaces. Separation enables containment and easier rotation.
• Govern SPNs. Document required SPNs, the client names used (short name, FQDN, aliases) and verify SPNs after service account changes. Include SPN checks in change procedures.
• Minimise local admin membership. Grant explicit rights for file paths, certificate stores, DCOM and firewall rules rather than defaulting to Administrators.
• Make password rotation and restart behaviour predictable. Test rotation and validate service restart behaviour and AD connectivity in OT zones. If using domain users, have a tested rotation process with rollback.
• Log with intent. Ensure Windows Security, service and PI logs allow correlation of actions to identities. Focus on useful logging for incident investigation, not maximal noise.

For broader operational guidance, see Running the PI System Day-to-Day: A PI Admin’s Playbook

Kerberos troubleshooting approach that saves time

1. Confirm the authentication used. Check Windows Security logs and ticketing tools. If NTLM appears where Kerberos was expected, use that as a cue to check DNS and SPNs first.
2. Confirm the name the client is using (short name, FQDN, alias). Load balancers and CNAMEs usually require SPN alignment.
3. Validate SPN uniqueness. Duplicates are common after migrations or uncoordinated fixes.
4. Review delegation only when you need true end‑to‑end user identity across hops. Prefer constrained delegation to limit abuse.

Getting specialist help

If you are standardising PI identities across sites or need a Kerberos/delegation design that reconciles OT constraints with enterprise policy, consider a short review by a practitioner. Browse PI System integrators and consultants at: https://piadmin.com/directory