Submitting your feedback...
Knowledge Base Article
KB01222 - Types of Kerberos Delegation
Product: PI Manual Logger / PI Vision / PI Web API
Version(s): All
 

Topic

Kerberos delegation is a feature of the Kerberos authentication protocol typically used in multi-hop security scenarios. There are a few different delegation options, each of which will be discussed below.

Note: this material is instructional only, consult your IT/security experts when making decisions that have security implications for your company

Background

Delegation allows a service to act on your behalf when connecting with other software or services. It is a form of impersonation and is disabled by default.

Typical scenario, user on computerA requests information from a service on computerB, but the requested data lives on computerC. Using Kerberos, delegation would need to be configured for whatever account the service was using.

Currently 4 delegation options exist:
  • Constrained Delegation - Kerberos Only
  • Constrained Delegation - Any Authentication Protocol
  • Resource Based Constrained Delegation
  • Unconstrained Delegation (not recommended)

One of the above options can be enabled for a service, user or computer* account within Active Directory (AD). Typically this is done on the Domain Controller (DC) by a domain admin. Manage AD by launching dsa.msc. In the Computers or Users folders for a particular domain, right-select an object and go to its properties. Assuming the object in question has a Service Principal Name (SPN) assigned to it you will see a tab called Delegation, where you will see the above bulleted options.

To explain the delegation options below it's necessary to understand a few base concepts of Kerberos. There are two types of tickets: a TGT and a service ticket. A TGT, or ticket-granting ticket, is an encrypted ticket used to authenticate a user when requesting service tickets (use command klist tgt to view the TGT). A service ticket contains information for requesting access/information from a specific resource (use command klist tickets to view service tickets).

* trusting the computer for delegation actually means you are trusting an identity that represents the computer (e.g. computerName$ ) which is used by LocalSystem and Network Service

Constrained Delegation

Constrained delegation is more secure because it limits delegation to a specified list, rather than allowing delegation to any service as in unconstrained delegation. It requires additional configuration compared with unconstrained delegation. You must ensure SPN's are setup on the account (use command setspn -L accountName to list SPN's for an account), and add the services the account is allowed to delegate to.
 

Kerberos Only

The Kerberos only options ensures that there is no protocol transition from a non-Kerberos authentication method. For instance, transitioning from claims authentication to Kerberos authentication is considered a protocol transition and would not be allowed.

Constrained kerberos only delegation option for a custom service account or user account.

st-widget-{image: constrained_kerberos.png}


Any Authentication Protocol

Any authentication protocol allows for protocol transitions.

Constrained any authentication protocol for a custom service account or user account.

st-widget-{image: constrained_any.png}

Resource Based Constrained Delegation

Note: (March 2017) This section mentions PI Coresight, which has since been renamed to PI Vision. See AL00314 for more info.  

When resource based constrained delegation is configured, an attribute is set on the identity of the back end service which specifies which front end service identities are allowed to send delegated credentials to it.  There are several benefits to resource based constrained delegation.  Most notably:
  1. Permission to delegate associated with back end instead of front end identity.
  2. Domain administrator privileges are not required.  Only 'Write Account Restrictions' permission on the specific back end resource (AD User or Computer) is required.
  3. Functions across domain and forest boundaries.
This is excellent news for non-IT administrator users as it allows for the administrator of the back end resource, such as PI Administrators for the PI Data Archive and PI Af Server, to control whether or not these resources receive delegated credentials.  However, there are also some requirements for resource based constrained delegation to work.  
  1. Both the front and back end account domains must have Server 2012 level or higher KDCs
  2. The front end server must be running on Server 2012 or later OS
To configure resource based constrained delegation, use the Active Directory cmdlets in PowerShell.  In order to access the Active Directory cmdlets in PowerShell, you will need to have the Remote Server Administration Tools installed (for installation instructions, see https://technet.microsoft.com/en-us/library/dd378937(WS.10).aspx).  
Once installed, the module must be loaded with the Import-Module cmdlet.
Import-Module ActiveDirectory

To execute the code, open Administrative PowerShell (right click the PowerShell icon > Run as administrator). First get the front end and back end identities.  When the service is running under a domain account use Get-ADUser.  If it is running under a machine account such as Network Service or a virtual account, use Get-ADComputer.

The example below is for a PI Coresight web server running under a domain account picoresight and AF Server PIAF01 running under the default virtual account NT Service\AFService. 
$frontendidentity = Get-ADUser -Identity picoresight 
$backendidentity = Get-ADComputer -Identity PIAF01

Next assign the front end identity to the PrincipalsAllowedToDelegateToAccount property of the back end identity.
Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity

At this point the configuration is complete, though it may be helpful to view the updated PrincipalsAllowedToDelegateToAccount property for the back end identity to verify that it is set properly.
Get-ADComputer $backendidentity -Properties PrincipalsAllowedToDelegateToAccount

We can allow multiple principles to delegate to the same back end by setting the PrincipalsAllowedToDelegateToAccount with all the desired identities.
Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity1, $frontendidentity2

When there are multiple domains involved, you may need to specify more criteria when executing the Get-ADUser cmdlet.  The example below includes the -Server parameter to specify a DC of the domain where the identity resides.
$frontendidentity = Get-ADUser -Identity picoresight -Server piDC01.picorp.int

Configuring unconstrained delegation for an account means you are granting that account permission to delegate to any service, provided all other steps necessary to initiate delegation are met. This option is the least secure from an IT security standpoint and therefore not recommended. 

Any time you use unconstrained delegation for a multi-hop scenario you are, in essence, passing your TGT to the next service. With your TGT that service can request any service ticket as though it were the original, requesting user...hence unconstrained.

Unconstrained delegation option for a computer account (NETWORK SERVICE, LOCAL SYSTEM and virtual service accounts will use the identity of the computer account for Kerberos).

st-widget-{image: unconstrained.png}
Article ID: KB01222 Created: 2015-06-16
Article Type: Informational Last Updated: 2018-10-05