If you've opted to run the gateway service as an Active Directory service account, there are some differences in the way delegation is configured. Before configuring delegation, you must first configure a service principal name for the service account you are using for the gateway service (see Configure Kerberos with an Active Directory Service Account).
If either of these scenarios is true in your environment, you will need to configure Kerberos delegation to the AnyCAGateway DCOM from the Keyfactor Command server hosting the Keyfactor Command Management Portal:
- You wish to use the option in Keyfactor Command to allow management interactions with the Keyfactor Command via Keyfactor Command (e.g. certificate approval or revocation) to be done in the context of the user authenticated to Keyfactor Command rather than in the context of the Keyfactor Command service account under which the application pool is running.
- You wish to use the option in Keyfactor Command to allow enrollment
Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA). requests to the Keyfactor Command via Keyfactor Command to be done in the context of the user authenticated to Keyfactor Command rather than in the context of the user configured in Keyfactor Command with the Use Explicit Credentials option.
Configuring Kerberos delegation in Active Directory allows the user’s Kerberos credentials to be delegated from the Keyfactor Command server to the AnyCAGateway DCOM to allow the Keyfactor Command server to act on behalf of the user.
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 application pool runs and the machine account of the Keyfactor Command server to be allowed to delegate to each of your CAs, including the AnyCAGateway DCOM.
- With the resource-based constrained delegation introduced in Windows Server 2012, you configure each of your CAs and the AnyCAGateway DCOM to be allowed to receive delegation from the service account under which the Keyfactor Command 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 better, though there can be 2008 or 2008 R2 domain controllers in the mix.
Traditional Delegation
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 gateway 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 steps, below, and then skip the remainder of the steps in that set of instructions. For assistance configuring traditional constrained delegation using ADSIEdit, contactKeyfactor 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:
- Open Active Directory Users and Computers and browse to locate the machine account of the Keyfactor Command server and open its properties.
- 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.
- In the Add Services dialog, click Users or Computers and browse to locate the computer account of the gateway server.
Figure 597: Configure Kerberos Constrained Delegation on the Keyfactor Command Machine Account
- In the Add Services dialog once the available services have populated, highlight the rpcss service and click OK.
- Back on the Delegation tab of the machine account Properties, click Add again. Click Users or Computers and search for the service account name your gateway service is running as. Click OK and OK to return to the Delegation tab of the machine account Properties.
Figure 598: Add Gateway Service for Kerberos Constrained Delegation
- Back on the Delegation tab of the machine account Properties, you should see the rpcss and KFGW (or other defined name if you picked a different name) services populate the "Services to which this account can present delegated credentials box". The server names may not appear as fully qualified domain names until you close the properties dialog and open it again.
Figure 599: Add Kerberos Constrained Delegation for the Keyfactor Command Machine Account
To configure Kerberos constrained delegation on the service account under which the Keyfactor Command application pool is running:
- Open Active Directory Users and Computers and browse to locate the service account under which the Keyfactor Command application pool is running and open its properties.
- 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 for the Keyfactor Command application pool service account.
- In the Add Services dialog, click Users or Computers and browse to locate the computer account for the gateway server.
- In the Add Services dialog once the available services have populated, highlight the rpcss service and click OK.
- Back on the Delegation tab of the service account Properties, click Add again. Click Users or Computers and search for the service account name your gateway service is running as. Click OK and OK to return to the Delegation tab of the service account Properties.
- Back on the Delegation tab of the service account Properties, you should see the rpcss and KFGW (or other defined name if you picked a different name—see Configure the Service Principal Name for the Gateway Service in the Gateway Configuration) services populate the “Services to which this account can present delegated credentials box”. The server names may not appear as fully qualified domain names until you close the properties dialog and open it again.
Figure 600: Configure Kerberos Constrained Delegation on the Keyfactor Command Service Account
Resource-Based Delegation
To configure Kerberos resource-based constrained delegation:
- If you haven't done so already, create at least one Active Directory security group that will be used for granting delegation permission. You may wish to use the same group to configure delegation for both the gateway and any Microsoft CAs in your environment.Tip: The type of group to use and domain to place it in will vary depending on your forest 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), Microsoft CA 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), gateways 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), gateways, 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), gateways, 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 and gateways in the parent domain or child domain B with no cross-forest involvement: Create a universal group in the domain with the CAs and gateways (the parent domain or child domain B).
- Keyfactor Command server(s), application pool service account and CA(s) and gateways 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.
Note: The AnyCAGateway DCOM cannot be installed in a separate forest from the Keyfactor Command server(s). - Add the service account under which the Keyfactor Command application pool runs to this new security group.
- Add the machine account for the Keyfactor Command server to this new security group. Repeat for additional Keyfactor Command servers.
- 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 and gateways exist.
- In the PowerShell window, run the following commands, where KerberosDelegationGroup is the name of your group for Kerberos delegation and MyGateway is the machine name (no trailing $) of the gateway you wish to delegate to:$mygroup = Get-ADGroup -Identity KerberosDelegationGroup
Set-ADComputer MyGateway -PrincipalsAllowedToDelegateToAccount $mygroup - Repeat the Set-ADComputer step for any additional CAs or gateways.
- In the PowerShell window, run the following command for each CA or gateway to confirm that the group has been associated with the PrincipalsAllowedToDelegateToAccount property on the gateway computer account:Get-ADComputer MyGateway -Properties PrincipalsAllowedToDelegateToAccount