Escalating from child domain’s admins to enterprise admins in 5 minutes by abusing AD CS, a follow up

Hello everyone, long time no see. I’m still extremely busy on my main job stuff, specifically PKI Spotlight commercial product development, so my blogging has slowed, and I’m here again!


Disclaimer: This post contains steps and information that can lead to legal issues with your employer and lawsuits if you execute them in a production environment.

Today I’ll talk about how you can escalate from Domain Admins in child domains to Enterprise Admins in your Active Directory forest where no PKI is deployed yet. This post is based on a great article From DA to EA with ESC5 by Andy Robbins. I strongly recommend you read that article first, I enjoyed it extremely and the vast majority of credit from this post go to Andy!

In short, any writable domain controller in the forest (literally, any) can write into Configuration Naming Context AD partition which is replicated across all domain controllers in the forest. As long as you can escalate yourself to a local system account (hi, psexec!) on a DC (assuming you are one of admins on a writable DC, no matter what domain it is located in), then you can utilize default “System = Full Control” permissions and write whatever you want in these containers.

Coincidentally, Microsoft PKI stores critical and sensitive information to Configuration Naming Context. Not actual secrets, but it is a trust store for the entire Active Directory forest. Enterprise CAs are registered there as enrollment services. Enterprise CAs store a list of certificate templates they support and it contains a store of unconditionally trusted private PKIs. If you can write into Configuration Naming Context, you can install your fake root CA certificates and do really mad things. Andy’s blog post I referenced contains all the detailed information about what and how. This blog post is more like a “follow up”, because the referenced blog post ends with:

The next question I want answered: What if ADCS isn’t already deployed? Can we bootstrap the necessary LDAP objects and issuing CA to turn DA into EA if we have, for example, full control of the “Public Key Services” container but there are no CAs?

And the answer is:

Hold my beer Tee shirts | Tshirt-Factory

Actually, don’t watch, just read.


Let’s continue where Andy ended: What if AD CS isn’t already deployed? If no one did this, you will deploy this yourself and be able to do really, awful, nasty things. My vanilla brand environment consists of two domains:

  1. – forest root domain
  2. – child domain


All steps provided in this blog post are executed on a writable DC in child domain only. There is nothing to do in forest root domain. Since it is a vanilla brand install, no PKI is deployed yet:


No Enterprise CAs yet, no certificate templates, no nothing.

Installing Enterprise CA in child domain without Enterprise Admins permissions

Let’s add some. First, you need to download a psexec tool from Sysinternals and execute a PowerShell under local system account by calling psexec /s /i powershell. Then in elevated PowerShell console install AD CS components and your first Enterprise CA with default settings:

PS C:\> Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

Success Restart Needed Exit Code      Feature Result
------- -------------- ---------      --------------
True    No             Success        {Active Directory Certificate Services, Ce...

PS C:\> Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CACommonName "My First CA"

Are you sure you want to perform this action?
Performing the operation "Install-AdcsCertificationAuthority" on target "LAB-CHILD-DC1".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

ErrorId ErrorString
------- -----------

PS C:\>

Do not close elevated PowerShell console and let’s validate if everything is up:


We see that CA is successfully registered as enrollment service. It is now trusted by **any** AD forest member, user, computer, domain controller. By default, no additional steps are required. Next step is to prepare a couple of templates. First, from elevated PowerShell prompt, type certtmpl.msc to open Certificate Templates MMC snap-in. We need to create a copy of a default User template and configure two tabs:

1. Subject tab

set radio button to “Supply in request”:


2. Security tab

grant yourself or your group Read, Write and Enroll permissions:


You can provide your own name to the template and save. Create additional templates as needed (I’m not going to use them in this blog post, it is up to you).

Now, let’s add this template to CA server. To do so, in normal command prompt or PowerShell, type: certsrv.msc. In the opened console, expand CA node and select Certificate Templates node. Delete everything except Domain Controller template. Then, right-click on Certificate Templates node, New –> Certificate Template To Issue. In the dialog, pick the user template you created a couple of steps before. It should look like this:


Why we left Domain Controller template? Well, it is necessary to automatically enable smart-card logons in entire forest. The beauty of this template is that AD domain controllers are hardcoded internally to automatically pick the certificate from this template once it is available. Other templates, like Domain Controller Authentication or Kerberos Authentication require autoenrollment policy configuration, which you may not execute easily. With Domain Controller template, everything is done automatically, no actions are required, all domain controllers in entire forest will enroll DC certificate. And, as I mentioned, this certificate is required to enable smart card logon globally.

The final step in our journey is to enroll a certificate for one of Enterprise Admins in your forest. To do so, in normal command prompt or PowerShell console type: certmgr.msc.

In the opened MMC, right-click on Personal, select All Tasks –> Request New Certificate. Follow the wizard until the list of templates appear:


Select checkbox and press on a “More information” link:

In the Subject tab, navigate to Alternative Name box and from drop-down list select “User Principal Name” name type. In the text box below, type target account’s UPN. It must be in a form accountname@domain.fqdn and press Add button, so the name is moved to the right:


Press Ok, then Enroll and voila:


You have a client authentication certificate for one of the enterprise admins.

Note: Be aware that the built-in Administrator account in every domain has no UPN by default. This means that you cannot spoof accounts without a UPN. This applies to built-in accounts only. Any newly created account will have a UPN and is subject for spoofing.


Although this article is somewhat entertaining, I need to ask closing question: How can you protect your AD from this sort of attack? Many attacks provided by the SpecterOps Certified Preowned report are somewhat imaginary and require reasonable efforts to prepare the ground for attack. But this one is quite serious, enabled by default and hard to protect from. One way I can imagine is to remove SYSTEM permissions from Public Key Services container ACLs and explicitly grant write permissions only to DCs from forest root. Wouldn’t this cause unfortunate side effects with replication? And permission inheritance is somewhat complex, it is easy to make a mistake and ruin your AD. Hope someone else will write mitigation steps.

And thanks, if you reached the end of the blog post!

About Vadims Podāns

Senior PKI Developer


  1. ThePKIGuy on May 25, 2023 at 4:18 pm

    You missed the best part Vadims – PKI Spotlight detects any new object added to the Enrollment Services container and sends real-time alerts to customers. That means even if someone started this attack, an administrator could receive the alert within minutes that something was added to this container – which is suspicious as it doesn’t happen often at all.

    • Vadims Podāns on May 26, 2023 at 7:05 am

      Good spot. Maybe we can add this to Spotlight marketing, because there are very few (I’m aware of none) user-friendly tools that detect changes in AD PKI containers and quickly alert IT staff about critical changes.

  2. Missing LDAPS on May 26, 2023 at 5:40 am


    For testing, how do I setup LDAPS on a forest root DC without ADCS installed in order to be able to authenticate using the client certificate?

    • Vadims Podāns on May 26, 2023 at 6:51 am

      This was covered in blog post where we left “Domain Controller” template on a CA. As I said, DCs are hardcoded to enroll for “Domain Controller” template once it is available on any Enterprise CA. And once enrolled, DC is ready to work with LDAPs. You don’t need to configure LDAPS specifically, it is ready by default and fully turned on once DC gets the matching certificate.

      • Richard Hicks on May 26, 2023 at 5:07 pm

        Are domain controllers also hard coded to enroll for the Kerberos Authentication certificate template if it is published?

        • Vadims Podāns on May 28, 2023 at 4:08 am

          AFAIK no. Domain Controller Authentication and Kerberos Authentication templates are V2 templates and are autoenrollment-enabled, so no need to hardcode them. Domain Controller template is V1 template is autoenrollment-disabled and it is reasonable to hardcode them in order to enable LDAPS and smart card logon functionality in environments where autoenrollment is not available (well, it is no longer the case, but the code was written for Windows 2000 and wasn’t changed/updated/removed since then).

  3. Daniel Yehezkel on May 29, 2023 at 3:23 am

    Great article, Thanks!
    Just a side note – If strong authentication is enabled on all DCs – I don’t think you can use the certificate you got.
    This of course doesn’t solve the main issue…

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.