Jet Reports Homepage |  Community Forum |  Downloads |  Submit A Ticket |  Jet Express Support
Feedback

Jet Dashboard Builder - Configuring Windows IIS Double Hop Settings


Overview

This document is intended for a domain administrator attempting to configure Jet Mobile to work in the so-called “double hop” case.

A "double hop" occurs when the client/service/database architecture spans across three or more machines. No additional configuration is required if any of these three components are on the same machine.

Environment

The most common scenario encountered will likely be installing the Dashboard Builder, the Jet Service Tier, and SQL Server Analysis Services (SSAS) on different machines. The following terms will be used for each of these machines:

        Dashboard Builder Machine -> User Machine

        Jet Service Tier Machine -> Service Machine

        SSAS Machine -> Back-end Machine

   

                    The three types of accounts and the required steps to configure them for delegation.

And for each machine, there is a corresponding account which uses the same naming convention:

        Dashboard Builder Account -> User Account

        Jet Service Tier Account -> Service Account

        SSAS Account -> Back-end Account

Impersonation and Delegation

In Kerberos, there are two terms used to describe the permission for a service to access network resources on behalf of a client: Impersonation and Delegation.

Impersonation is the right to access remote resources to which the impersonated client has access, but only for the "single hop" case. The service is unable to "delegate" the access rights of the client on to additional machines/services. No additional configuration is required in Active Directory (AD) for impersonation.

Delegation is the right for the service to delegate the user's identity and access rights to machines beyond the first, which handles the "double hop" case. Configuring delegation in AD is required for Jet Mobile to work in the "double hop" case. 

Kerberos allows two types of delegation: constrained and unconstrained. Constrained delegation describes when services are permitted to delegate only to specified services, while unconstrained delegation permits delegation to any service. Using constrained delegation is recommended as it is more secure.

Service Principal Names (SPNs)

Simply put, Service Principal Names (SPNs) are a unique alias for a service in an AD forest. An SPN is associated with an account under which a service is running. One of the steps required to permit Kerberos delegation is to set SPNs on each of the service accounts, namely the Service account and the Back-end Account.

It is highly recommended that the reader has at least a basic understanding of SPNs before undergoing the steps in this document. More information about SPNs can be found in the documents linked in the Works Cited and Further Reading section.

Required Configuration for Delegation

Verify SPNs are registered for service account

NOTE: This step is only required if the service account is a machine account such as NETWORK SERVICE.

At a command prompt, type:

               setspn -L <Domain>\<Account>

where <Domain> is the name of the domain and <Account> is the name of the service account. If the service account is a built-in computer account such as NT AUTHORITY\NETWORK SERVICE, then <Account> will be the name of the computer.

There needs to be at least two SPNs listed, because the following two SPNs for the service account must be present for delegation to properly function:

               HOST/<Host>

               HOST/<FQDN>

where <Host> is the name of the host computer and <FQDN> is the fully qualified domain name of the host computer (i.e. <Host>.<Domain>).         

If both SPNs are not present, then add the appropriate SPN(s) using the setspn -A command. If there are duplicate SPNs listed, then remove them using the setspn -D command.

               setspn -A HOST/<Host>.<Domain> <Domain>\<Account>

               setspn -D HOST/<Host>.<Domain> <Domain>\<Account>              

Verify SPNs are registered for the back-end account

At a command prompt, type:

                setspn -L <Domain>\<Account>

where <Domain> is the name of the domain and <Account> is the name of the back-end account. If the back-end account is a built-in computer account such as NT AUTHORITY\NETWORK SERVICE, then <Account> will be the name of the computer.

There needs to be at least two SPNs listed, because the following two SPNs for the service account must be present for delegation to properly function:

                MSOLAPSvc.3/<Host>

                MSOLAPSvc.3/<FQDN>

where <Host> is the name of the host computer and <FQDN> is the fully qualified domain name of the host computer (i.e. <Host>.<Domain>).         

Again, if both SPNs are not present, then add the appropriate SPN(s) using the setspn -A command. If there are duplicate SPNs listed, then remove them using the setspn -D command.

                setspn -A MSOLAPSvc.3/<Host>.<Domain> <Domain>\<Account>

                setspn -D MSOLAPSvc.3/<Host>.<Domain> <Domain>\<Account>

Trust service account for delegation

To trust the service account for delegation,

  1. Open Active Directory Users and Computers.
  2. Locate the services account you are configuring, right-click the account, click Properties, then click the Delegation

                 

  1. Select one of the two Trust… options:
    1. To configure the account to use unconstrained delegation, select Trust this user for delegation to any service (Kerberos only). This option is not recommended.
    2. To configure the account to use constrained delegation, select Trust this user for delegation to specified services only.
      1. Click Add…
      2. Click Users and Computers… and use the AD dialog to select the service account.Select
      3. Select the MSOLAPSvc.3 SPN and click Ok.

NOTE: If the back-end account is a Managed Service Account (MSA), then you must configure the service account to use unconstrained delegation.

Verify user accounts are allowed to be delegated (no action required by default)

By default, the user account should be permitted to delegate. However, to ensure that this is the case check that the Account is sensitive and cannot be delegated option is not selected for the user accounts:

  1. Open Active Directory Users and Computers.
  2. Right-click the user account, and then click Properties.
  3. Click the Account

                

  1. In the Account options box, confirm that Account is sensitive and cannot be delegated is not selected.

Verify service account is allowed to impersonate (no action required by default)

By default, the service account should be allowed to impersonate. However, to ensure that this is the case check that the service account is listed in the Impersonate a client after authentication policy in User Rights Assignment:

  1. Open the domain security policy by clicking Start, Programs, Administrative Tools, and then Domain Security Policy.

NOTE: Follow the instructions in Step 1 if Group Policy is enforced by the domain controller. If policy if enforced by the local computer, then you must open Local Security Policy on the local computer.

  1. Click Local Policies, then User Rights Assignment, and then click Impersonate a client after authentication.
  2. Add the service account.

Works Cited and Further Reading

Much of the material and all images in this document are sourced from a white paper published by Microsoft on “Troubleshooting Kerberos Delegation.”

The Microsoft paper has a more detailed explanation of the Kerberos architecture, diagnostic tools for setting up double hop authentication, steps for configuring delegation on pre-Windows Server 2003 domains, appendices containing more information about the functions used, and much more.

It is highly recommended that you read though the Microsoft delegation paper linked below for a thorough understanding the steps taken in this document, with this document intended as more of a “How-to” than a complete synopsis.

 

Microsoft Corporation, Troubleshooting Kerberos Delegation, March 2004.http://www.microsoft.com/en-us/download/details.aspx?id=4754, Accessed May 2014 (deprecated).

Microsoft Corporation, Service Principal Names. http://msdn.microsoft.com/en-us/library/ms677949%28v=vs.85%29.aspx, Accessed May 2014.

Kerberos authentication and troubleshooting delegation issues, September 2012 https://support.microsoft.com/en-us/help/907272, Accessed June 2017 

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

Comments