0

While deploying ADCS, on the documentation Microsoft recommends using service accounts for the services making up ADCS. The problem is that it doesn't address if these should be individually managed, if they could share a host, nor it is addressed the losing access from a remote Server Manager because Kerberos delegation is involved.

I learned how to fix this a while back because it's the same issue when ADFS* is deployed: control of the computer is stolen by the service account but, as you probably know, it can be gained back by simply adding Active Directory aliases (CNAMEs) to the machine account. e.g;

        …if the CA were called LOCKSMITH…

netdom computername locksmith /add:ceslocksmith.domain.tld
netdom computername locksmith /add:ceplocksmith.domain.tld
netdom computername locksmith /add:nedeslocksmith.domain.tld

        …or maybe even subdomains; (I've never tried this thought)

netdom computername locksmith /add:ces.locksmith.domain.tld
…

So I was wondering that, if I add aliases for each of the service accounts ADCS might use (CES, CEP, NDES) I could run each one as per recommendation but in the same machine — probably against best practices, but y'know — except I found this thing in some forum-type-place where it said that multiple instances of CES (I assume in a farm) should all run with the same service account. No mention of the other services was made. But should they too share the same service account, or is it OK for individual services tied to a single Enterprise CA to each run under their own service account?

Thanks.

*: actually it's worse for ADFS because for several years the documentation has wrongly indicated to use the wrong Kerberos service/PRINCIPAL. It indicates host, instead of the http service. Giving control of http to an account at most locks you out of remote admin/PowerShell remoting, but giving control of host away from the machine's account leaves it orphaned from the domain. What's worse is that this is repeated verbatim by MVPs and others in their own blogs.

Vita
  • 111
  • 1
  • 1
  • 7

1 Answers1

0

This is probably irrelevant by now, given the time delay and not a complete answer, but here we go:

The NDES connector (for SCEP) shouldn't be installed on an issuing CA server, so it means that's out of the equation. It should run as its own service account with the appropriate "Issue certificate" rights delegated on the CA plus the other requirements, per the documentation.

For CES/CEP, you'd only install those as required - e.g. for cross-domain or non-domain-joined machines/external user cert enrolments. Personally, I'm happier if they're not on the CA server, but you can deploy them there. By default, they use the application pool identity for the web service, but you can (and should) change that to a domain user account. Also note you can use a (g)MSA to run the services. This documentation is fairly old, but is still the most complete.

The documentation notes that if you install CES/CEP on the CA, you may encounter the following problem. This is why I'd personally run these services elsewhere, if they're required.

If other Kerberos authenticated http/https services are running on the same host as an Certificate Enrollment Policy Web Service or Certificate Enrollment Web Service configured for Kerberos authentication, enrollment failures may occur because of an SPN collision. The resolution is to configure all of the services to run as the same user account

Finally, it's not clear what documentation you might be following or what version of ADCS you're deploying, but remember to secure the CA servers against NTLM relay attacks, per KB5005413. Ideally this means disabling NTLM auth on the domain controllers (pretty difficult in most enterprise environments) or, alternatively, on each CS server (i.e. CA or CES servers). The minimal workarounds are requiring https and configuring Extended Protection for Authentication (EPA) on the enrolment web services.

LeeM
  • 1,388
  • 9
  • 14