Configure Kerberos Constrained Delegation (Optional)

Note:  These instructions apply only to Windows installations under IIS.

If you are using Active Directory as your identity provider, you must configure Kerberos delegation from the Keyfactor Command server to the CAClosed A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA.(s) when either of the following applies:

  • You want CA interactions performed through the Keyfactor Command Management Portal (such as revocation or CA-level certificate approval) to run under the signed-in user’s identity, rather than the Keyfactor Command service account or an explicit user defined in the CA configuration.

  • You want users to enroll for certificates in the Management Portal after signing in with Kerberos authentication rather than Basic authentication.

  • You want certificate enrollment to occur under the signed-in user’s identity rather than under the Keyfactor Command service account or an explicit user defined in the CA configuration.

Configuring Kerberos delegation in Active Directory allows the user’s Kerberos credentials to be delegated from the Keyfactor Command server to the CA(s) to allow the Keyfactor Command server to act on behalf of the user.

The types of interactions affected by delegation in the Keyfactor Command Management Portal include:

There are two different approaches to configuring constrained delegation:

  • With the traditional version of constrained delegation, you configure the service account under which the Keyfactor Command Management Portal application pool runs and the machine account of the Keyfactor Command server to be allowed to delegate to each of your CAs.
  • With resource-based constrained delegation introduced in Windows server 2012, you configure each of your CAs to be allowed to receive delegation from the service account under which the Keyfactor Command Management Portal application pool runs and the machine account of the Keyfactor Command server. This option requires at least one domain controller that's server 2012 or newer, though there can be 2008 or 2008 R2 domain controllers in the mix.

With both approaches to constrained delegation, you need to set the service principal name (SPN) for the Keyfactor Command server (see Configure the Service Principal Name for the Keyfactor Command Server).

Note:  If you're using a Keyfactor CA gateway and the gateway service is running as an Active Directory service account, delegation to that gateway is configured differently than is described below. Refer to the gateway documentation for more information.
Note:  Traditional constrained Kerberos delegation across multiple domains is only supported in newer versions of Windows Server for domain controllers. If yours is a multi-domain environment and you cannot locate your CAs following the below instructions, you may need to configure traditional unconstrained Kerberos delegation or configure traditional constrained delegation using ADSIEdit rather than the below method. To configure traditional unconstrained delegation, you would select “Trust this computer for delegation to any service (Kerberos only)” in each of the step 2s, below, and then skip the remainder of the steps in that set of instructions. For assistance configuring traditional constrained delegation using ADSIEdit, contact Keyfactor support (support@keyfactor.com). If none of the traditional constrained delegation methods work in your multi-domain environment, you may need to pursue resource-based constrained delegation instead, which is more forgiving of multi-domain environments.

To configure Kerberos constrained delegation on the machine account of the Keyfactor Command server:

  1. Open Active Directory Users and Computers and browse to locate the machine account of the Keyfactor Command server and open its properties.
  2. On the Delegation tab for the machine account, choose “Trust the computer for delegation to specified services only” and under that “Use any authentication protocol” and then click Add.

  3. In the Add Services dialog, click Users or Computers and browse to locate the computer account for one of the CAs to which you wish to delegate.

    Figure 600: Configure Kerberos Constrained Delegation on the Keyfactor Command Machine Account

  4. In the Add Services dialog once the available services have populated, highlight both the HOST and the rpcss services (hold down the CTRL key when clicking the second service to select both at the same time) and click OK.

    Figure 601: Add HOST and rpcss Service Types for Kerberos Constrained Delegation

  5. Back on the Delegation tab of the machine account Properties, you should see the HOST and rpcss services populate the “Services to which this account can present delegated credentials box”. The server names do not appear as fully qualified domain names until you close the properties dialog and open it again.
  6. Repeat steps 3 and 4 for any other CAs to which you wish to delegate and then click OK.

To configure Kerberos constrained delegation on the service account under which the Keyfactor Command application pool is running:

  1. Open Active Directory Users and Computers and browse to locate the service account under which the Keyfactor Command Management Portal and Keyfactor APIClosed An API is a set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command. application pools are running and open its properties.

    Important:  In order to use Kerberos delegation with Keyfactor Command, the application pools for the KeyfactorPortal and KeyfactorAPI virtual directories must both run as the same service account.

  2. On the Delegation tab for the service account, choose “Trust the computer for delegation to specified services only” and under that “Use Kerberos only” and then click Add.

    Important:  This is a different configuration setting than for the machine account.
    Tip:  The Delegation tab only appears on the properties sheet after you have configured a custom SPN.
  3. In the Add Services dialog, click Users or Computers and browse to locate the computer account for one of the CAs to which you wish to delegate.
  4. In the Add Services dialog once the available services have populated, highlight both the HOST and the rpcss services (hold down the CTRL key when clicking the second service to select both at the same time) and click OK.

  5. Back on the Delegation tab of the service account Properties, you should see the HOST and rpcss services populate the “Services to which this account can present delegated credentials box”. The server names do not appear as fully qualified domain names until you close the properties dialog and open it again.

    Figure 602: Configure Kerberos Constrained Delegation on the Keyfactor Command Service Account

  6. Repeat steps 3 and 4 for any other CAs to which you wish to delegate and then click OK.

To configure Kerberos resource-based constrained delegation:

  1. Create at least one Active Directory security group that will be used for granting delegation permission.
    Tip:  The type of group to use and domain to place it in will vary depending on your forestClosed An Active Directory forest (AD forest) is the top most logical container in an Active Directory configuration that contains domains, and objects such as users and computers. structure and the location of the accounts and resources in the forest. If your Keyfactor Command server(s), CA(s) and application pool service account are all in the same domain, any type of group in that same domain will do. If your Keyfactor Command server(s), CA(s) and/or application pool service account are separated across multiple domains, it becomes more complicated. If you add one or more cross-forest trusts into the mix that you want to do delegation across, that adds another level of complexity. Universal groups cannot be used in a cross-forest scenario, as they are not supported cross-forest. Some possible scenarios include:
    • All components (Keyfactor Command server(s), CA(s) and application pool service account) in the same domain: Create a group of any type in the same domain as these components.
    • Keyfactor Command server(s) and application pool service account in child domain A and all CAs in the parent domain or child domain B with no cross-forest involvement: Create a universal group in the domain with the CAs (the parent domain or child domain B).
    • Keyfactor Command server(s), application pool service account and CA(s) for forest A in the same domain, CAs in a single domain in forest B, forests A and B in a two way trust: Create a group of any type in the forest A domain where the Keyfactor Command server(s) reside and a group of type domain local in the forest B domain where the CAs reside; follow the below instructions for both domains and groups.

  2. Add the service account under which the Keyfactor Command Management Portal and Keyfactor API application pools runs to this new security group.

    Important:  In order to use Kerberos delegation with Keyfactor Command, the application pools for the KeyfactorPortal and KeyfactorAPI virtual directories must both run as the same service account.
  3. Add the machine account for the Keyfactor Command server to this new security group. Repeat for additional Keyfactor Command servers.
  4. On an Active Directory domain controller running Windows Server 2012 or better, open a PowerShell window using the “Run as administrator” option. If you're in a multi-domain or cross-forest environment, use a domain controller in the resource domain where the CAs exist.

  5. In the PowerShell window, run the following commands, where KerberosDelegationGroup is the name of your group for Kerberos delegation and IssuingCA is the machine name (no trailing $) of the CA you wish to delegate to:

    $mygroup = Get-ADGroup -Identity KerberosDelegationGroup

    Set-ADComputer IssuingCA -PrincipalsAllowedToDelegateToAccount $mygroup

  6. Repeat the Set-ADComputer step for any additional CAs.

  7. In the PowerShell window, run the following command for each CA to confirm that the group has been associated with the PrincipalsAllowedToDelegateToAccount property on the CA account:

    Get-ADComputer IssuingCA -Properties PrincipalsAllowedToDelegateToAccount