Deploying CEP/ CES using a gMSA

The Certificate Enrollment Policy Web Service (CEP) and the Certificate Enrollment Web Service (CES) were introduced with Windows Server 2008 R2 in order to simplify the request for certificates, especially for devices that were not member of a Active Directory domain.

The “classic” way of requesting a certificate from a Active Directory Enterprise CA involves LDAP and RPC/ DCOM, which was okay in the early days of Active Directory, but today, with a CA as a tier 0 asset, this is some kind of a problem. Today you want to avoid clients being able to talk directly to your CA using DCOM/ RPC.

How does CEP/ CES works

To get a around this issue, you can use the Certificate Enrollment Web Services (CEP and CES). Using CEP and CES, an identity (a client or a user), uses HTTPS to talk to the CEP. CEP authenticates the identity, and gets a list of accessable templates, for which the identity is entitled to enroll, using LDAP. The identity then connects to the CES using HTTPS. The identity submits the CSR to the CES, and CES connects to the CA using RPC/ DCOM. This allows you to open only HTTPS to CEP/ CES and the identity will still be able to request certificates. This is essentialy when it comes to segment your tier 0, tier 1 and tier 2 devices. This graphic suggests that CEP and CES must be placed on the same server, but this is not true. Furthermore: You can have multiple CEP and CES servers and load-balance them if required.

Source: Microsoft

Why should I use a gMSA??

The concept of the gMSA, a group-managed service account, was introduced with Windows Server 2008 R2 and it`s a totally underrated features and a key for more security when it comes to service accounts. The key feature of a gMSA is that the password is managed by Active Directory. Only specified accounts can read the password. Furthermore, you can’t use a gMSA for interactive logins. This makes a gMSA perfect for running service accounts, tasks etc.

Ususally, the CEP and CES application pools are running with the computer identity or a service account. If you want to use a gMSA for CEP/ CES, you have to jump over a few hurdles. Make sure that you use the same account for CEP and CES if both services run on the same server.

Steps to create a gMSA for CEP and CES

First of all: Create the gMSA.

New-ADServiceAccount -Name gmsa-cepces -PrincipalsAllowedToRetrieveManagedPassword CG_
GMSA_gmsa-cepces -DNSHostName gmsa-cepces.domain.tld

I always recommend to use a group for -PrincipalsAllowedToRetrieveManagedPassword. Specify the right scope (domain-local, global or universal) for the group, depending on where the identies reside that should be able to retrieve the managed password!

I always recommend to use a DNS A-Record to connect to CEP/ CES. Typically use something like cepces.domain.tld. This can be the DNS name of your Active Directory domain, or when using split-dns, an external FQDN.

setspn -S HTTP/cepces.domain.tld DOMAIN\GMSA-CEPCES$

If you use a specific A-record, make sure to adjust the msPKI-Enrollment-Servers, because it uses the servername of the CES. You can simple change it using adsiedit.msc (Configuration Partition, properties of the Enterprise CA object under CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com)

You can’t configure the required constrained delegations using the Active Directory User and Computer MMC. You need to configure this using PowerShell! You can use the same gMSA for multiple CAs. Make sure to add rpcssand host for each CA. And use the FQDN and NetBIOS name of each CA.

$AllowedToDelegateTo = @(
 "rpcss/CA01",
 "rpcss/CA01.domain.tld",
 "HOST/CA01",
 "HOST/CA01.domain.tld"
)

Get-ADServiceAccount -Identity gmsa-cepces | Set-ADObject -Add @{"msDS-AllowedToDelegateTo"=$AllowedToDelegateTo}

I avoid the unnecessary Install-ADServiceAccountgmsa-cepces You don’t need this, even if it’s part of most documentations. Also -TrustedForDelegation $false and/ or -TrustedToAuthForDelegation $false are not needed to be set to $true.

Now add the gMSA to the IIS_IUSRS group on the CEP/ CES server. If you have multiple CEP and CES servers you need to repeat this step on each server.

Add-LocalGroupMember -Group IIS_IUSRS -Member DOMAIN\gmsa-cepces$

Last step is to change the account which is used to run the CEP and CES application pools (WSEnrollmentPolicyServer and WSEnrollmentPolicyServer). You can do this using the IIS MMC or you can install and import the WebAdministration PowerShell module.

Set-ItemProperty IIS:\AppPools\WSEnrollmentPolicyServer -name processModel -value @{userName="gmsa-cepces$";password="";identitytype=3}
Set-ItemProperty IIS:\AppPools\WSEnrollmentPolicyServer -name processModel -value @{userName="gmsa-cepces$";password="";identitytype=3}

Restart the IIS using iisresetand your gMSA enabled CEP/ CES and ready to go!

A word of warning

If you have a multi-domain Active Directory forrest, please make sure that the CA and the gMSA are in the same domain. In most cases this is often the root domain. I spend a good amount of hours in troubleshooting Kerberos errors when CEP/ CES were placed in a sub-domain, as well as the gMSA, but the CA was placed in the root domain. The webserver, running CEP/ CES can be places in a sub-domain. In this case, the group used for -PrincipalsAllowedToRetrieveManagedPassword should be a universal-group and it must be located in the same domain as the gMSA. If you want to avoid any obstables, place CA, gMSA and CEP/ CEs server(s) in the same Active Directory domain.