Coresight Squared

 

This series consists of three parts:
1. Server Core Installation and Configuration
2. PI Coresight Installation

3. Extras: Kerberos and more << you're here!

 

 

At this point, Coresight Squared is ready to rock. But what’s next? Surely we can’t end here!

 

Meet everyone’s favorite three headed friend – Kerberos.

Disclaimer:
We will not go into technical details about how the Kerberos protocol works, nor will we cover Kerberos troubleshooting. Maybe next time!

Instead, we’ll look into how to leverage Kerberos authentication and Kerberos delegation to enhance security configuration of the PI System.

 

 

 

Coresight - IIS Settings

 

Before configuring Kerberos, make sure Kerberos Authentication with PI Coresight is possible:

 

1. Enable Windows Authentication

Select Coresight Web Application > Authentication Settings:

 

 

2. Enable Kernel-mode Authentication
Right-click Windows Authentication > Advanced Settings... > make sure Kernel Mode is enabled:

 


As per the description above, Microsoft recommends keeping Kernel-mode Authentication enabled. Some hard data on performance benefits of Kernel-mode Authentication can be found here.

 

If Kernel-mode authentication is Enabled, Kerberos tickets are decrypted using the password hash of the computer where the service we're accessing is running (i.e. the Coresight Web Server in this case). As such, if the Coresight AppPools run under:

 

  • Virtual or Machine account (such as Network Service) - no further action required

 

  • Custom Domain Account - In IIS Manager, select the Coresight Web Application > Configuration Editor > navigate to system.webServer/security/authentication/windowsAuthentication > set useAppPoolCredentials to True. This ensures that the password hash of the Coresight AppPool account is used to decrypt incoming Kerberos tickets, allowing Kerberos Authentication to work properly.

 

3. Make Kerberos Authentication possible

Right-click Windows Authentication > Providers... > make sure the Negotiate provider is listed as the first option. For example:

 

 

 

 

 

Kerberos Simplified: The Three Heads

 

To simplify as much as possible, let's consider the three main points of interest:

1. Front-end Service Principal Name  - Coresight end-users need to be able to use Kerberos Authentication to log in to Coresight (the front-end service)

2. Back-end Service Principal NamePI or AF Server (the back-end service) needs to be able to receive Kerberos requests (delegated credentials)

3. Kerberos Delegation - Coresight service account (the front-end service identity) needs to be allowed to delegate end users' credentials to the back-end service (PI or AF Server)

 

 

The First Head: Front-end Service Principal Name


A Service Principal Name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service account.

SPN can be broken down into two parts (I am purposefully leaving out the port number and service name as they’re not relevant to our context):

 

ServiceClass/TargetHost, which is assigned to the appropriate ServiceAccount.

 

ServiceClass – a string indicating the general class of a service. Well-known service classes pertaining to the PI System include:

PI Data Archive – PIServer

PI AF Server – AFServer

PI Coresight – HTTP

Regardless of whether SSL is enabled for Coresight, the ServiceClass is always HTTP!

 

TargetHost- Hostname and Fully Qualified Domain Name of the computer on which the service is running. Always create one SPN for the hostname and one more for the FQDN of the Coresight server!

 

ServiceAccount – The account running the service. In case of:

Domain Account - the SPN is assigned to the actual domain account running the service

Virtual or Machine accounts (Network Service, NT Service\Service etc.) – the SPN is assigned to the computer object (on which the service is running)

 

SPNs can be created using the setSPN.exe tool (available from the Command Prmompt). In most environments, a Domain Admin access is needed to create new SPNs.

 

To create SPNs for PI Coresight running under OSI\CoresightSVC on Core01.it.local machine:

setspn -S HTTP/Core01.it.local OSI\CoresightSVC
setspn -S HTTP/Core01 OSI\CoresightSVC

 

To create SPNs for PI Coresight running under Network Service on Core01.it.local machine:

setspn -S HTTP/Core01.it.local Core01
setspn -S HTTP/Core01 Core01

 

 

 

Use setSPN.exe to verify whether the SPNs are created and assigned correctly.

 

To list all SPNs assigned to a particular domain\account:

setspn -L domain\account
Example: setspn -L OSI\CoresightSVC

 

To check whether a particular SPN exists:

setspn -Q SPN
Example: setspn -Q HTTP/Core01

 

 

 

The Second Head: Back-end Service Principal Name

 

The same principles applied to front-end Service Principal Names apply to the back-end Service Principal Names as well. Make sure the appropriate (PIServer/TargetHost and AFServer/TargetHost, respectively) SPNs are assigned to the correct service account (PI Network Manager ServiceAccount for Data Archive; PI AF Application Service ServiceAccount for PI AF Server).

 

 

 

 

The Third Head: Kerberos Delegation

 

Once Kerberos Delegation is enabled, the front-end service (PI Coresight) can delegate end users’ credentials to the back-end service (PI Data Archive or PI AF Server) and thus ensure that end users access resources (data) of the back-end service in a secure way.

 

In our case, the Coresight service account needs to be allowed to delegate end-users’ credentials to PI Data Archive. Starting with PI Coresight 2016, Keberos Delegation to AF Server is required for annotating Event Frames.

 

There are three main types of Kerberos delegation:

 

  • General (Unconstrained) Delegation
  • Constrained Delegation
  • Resource Based Delegation

 

For additional details, please consult KB01222 - Types of Kerberos Delegation. We’ll go for the cutting edge option – Resource Based Delegation.

 

There are several benefits to Resource Based delegation. Most notably:

  • Permission to delegate associated with back end instead of front end identity
  • Domain administrator privileges are not required
  • 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.

  • Both the front and back end account domains must have Server 2012 level or higher Kerberos Distribution Centers
  • 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.

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.

 

Step-by-step guide:

 

1. Get the front-end and back-end service identities. If 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.

 

$frontendidentity = Get-ADUser -Identity picoresight
$backendidentity = Get-ADComputer -Identity PIAF01

 

 

2. Assign the front-end identity to the PrincipalsAllowedToDelegateToAccount property of the back-end identity:

Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity

 

 

3. View the updated PrincipalsAllowedToDelegateToAccount property for the back-end identity to verify that it is set properly:

Get-ADComputer $backendidentity -Properties PrincipalsAllowedToDelegateToAccount

 

 

 

Extras:

 

To allow multiple principals to delegate to the same back end, set the PrincipalsAllowedToDelegateToAccount with all the desired identities, separated by a comma:

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

 

If there are multiple domains involved, 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.pidoge.local

 

 

 

 

Recommended Kerberos reading (and you guessed it, it’s three links ):

OSIsoft: Kerberos Authentication and web browsers

How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 1

How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2

 

 

What's next? Look into Coresight High-Availability!

 

 

Since you've made it all the way here, chances are you're interested in assessing the security posture of your entire PI System, not just Coresight, so please do check out the PI Security Audit Tools on GitHub!