Configure resource-based constrained delegation

Note: This section doesn't apply if installing in an environment whose end users only use OpenID Connect authentication.

There are several benefits to resource-based constrained delegation compared to traditional Kerberos constrained delegation:

• Permission to delegate to the back-end resource is associated with the back-end identity rather than the front-end identity.

• Configuring delegation only requires Write Account Restrictions permission on the specific back-end resource (Active Directory user or computer).

• Delegation works across domain and forest boundaries.

Resource-based constrained delegation is an excellent choice for non-IT administrators. It allows PI administrators to control whether or not resources like the Data Archive and PI AF servers receive delegated credentials. However, for resource-based constrained delegation to work, the following requirements must be in place:

• The domain of the front-end account (AVEVA PI Vision application-pool identity) must have a Windows Server 2012 level or higher Key Distribution Center (KDC).

• The domain of the back-end account (Data Archive machine account or PI AF server service account) must have a Windows Server 2012 or higher KDC.

• The front-end server must be running on Windows Server 2012 or later operating system.

For more information, see the Microsoft article Kerberos Constrained Delegation Overview.

To configure resource-based constrained delegation, you set an attribute on the identity of the back-end service. The attribute specifies the identities of the front-end service that can send delegated credentials to the back-end identity. To set this attribute, use Active Directory cmdlets in PowerShell. You can run these cmdlets from any machine with the Remote Server Administration Tools (RSAT-AD-PowerShell) feature installed. To run the cmdlets, you need write access to the attributes of the back-end Active Directory object. Use the cmdlets appropriate for your service account:

• If the service runs under a domain user account, use Get-ADUser and Set-ADUser.

• If the service runs under a group-managed service account (gMSA), use Get-ADServiceAccount or Set-ADServiceAccount. See the Microsoft article Group Managed Service Accounts Overview.

• If the service runs under a machine account such as Network Service or a virtual account, use Get-ADComputer or Set-ADComputer.

1. Open PowerShell.

2. Set variables that contain the front-end and back-end identities.

   For example, if the AVEVA PI Vision web server (the front-end service) runs under the domain user account PIVisionService, and the PI AF server PIAF01 (the back-end-service) runs under the default virtual account NT Service\AFService, then enter the following:

   $frontendidentity = Get-ADUser -Identity PIVisionService

   $backendidentity = Get-ADComputer -Identity PIAF01

3. Assign the front-end identity to the PrincipalsAllowedToDelegateToAccount attribute of the back-end identity.

   For example, if the back-end service runs under a machine account, then enter the following cmdlet:

   Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity

   To allow multiple principals to delegate to the same back-end resource, set the PrincipalsAllowedToDelegateToAccount attribute with all the desired identities.

   For example, if the back-end service runs under a machine account, then enter the following cmdlet:

   Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity1, $frontendidentity2

4. View the updated PrincipalsAllowedToDelegateToAccount attribute of the back-end identity to verify that it is set properly.

   For example, if the back-end service runs under a machine account, then enter the following cmdlet:

   Get-ADComputer $backendidentity -Properties PrincipalsAllowedToDelegateToAccount

   Note: If you are using an AVEVA PI Vision Service account, you must create service principal names (SPNs) for the account for resource-based constrained delegation to work. For more information on creating SPNs, see steps 1 and 2 in Enable Kerberos delegation when AVEVA PI Vision uses a custom domain account.