ADPREP Bug in Windows Server 2016

When I upgraded a domain to Windows Server 2016 DCs I noticed a bug in the adprep program that I have reproduced in my lab and wanted to share it here.

In Active Directory 2016 there is two new groups introduced.
Key Admins
Enterprise Key Admins

If you create a new domain with Windows Server 2016 the groups will be created and given Read and Write access to the ms-DS-Key-Credential-Link attribute on all child objects from the domain root.

There isn’t much public documentation about this attribute, and that isn’t what this blog post is about.
But it seems to have something with Windows Hello for Business providing key-based or certificate-based authentication. That is still not fully implemented in Active Directory, it’s on the roadmap for future release. You can read more about it here: Manage identity verification using Windows Hello for Business

I have also noticed the ADFS 4.0 installation wizard tries to add the service account as member of the Enterprise Key Admins group. You can read about it here: Upgrading the ADFS farm behavior level

When I upgraded a domain, and ran adprep.exe to prepare the domain for Windows Server 2016 DCs I noticed after running adprep.exe /domainprep two new SIDs representing the two new groups.

SID-FullControll

The one with RID 526 is the Key Admins group and RID 527 is Enterprise Key Admins group. And this is interesting since the 527 group now has Full Control on the domain root and all child objects with inheritance, which is a lot.

Adding a Windows Server 2016 DC and moving the FSMO role PDC Emulator to that DC, the groups gets created and you can see it in the Security tab.

enterpriseKeyadmins

In this case, the default Users container was redirected to an Organizational Unit and giving other users control of this group (Otherwise default, it ends up in the Users Container).

redirected2

So, the bug is simply that when running adprep from a Windows Server 2016 install media the new group Key Enterprise Admins gets Full Control permissions in the domain. This also happens in child domains, and even when using PowerShell Install-ADDSDomainController triggering a forest/domain prep if it’s not done before promoting a new 2016 DC.

I wrote about the security implications of having too much permissions in the domain root last year and can be read here.

That post was more general about what can go wrong when delegating access. Here is a more precise example.

Why do I think this bug is bad?

This is high level access granted.

First, the only other group that is granted Full Control in the domain root object is Enterprise Admins (and the other principal is SYSTEM) and this is also true for child domains.But Enterprise Admins is part of the protected groups guarded by AdminSDHolder.

The Enterprise Key Admins group is treated like any regular group in the domain. Default granting Account Operators Explicit Full Control on the Enterprise Key Admins group opening for a lot of other users which could abuse these permissions and e.g. sync all password hashes from the root domain and child domains.

AccountOperatorsACLEntKeyAdmins

The group has inheritance enabled, depending on where it ends up, opening for other possible OU admins having access modifying the membership. Since it doesn’t have any extra protection like other high-privileged groups like BA,DA and EA, this is an easier target for malicious user to compromise the entire forest.

This has been accepted by Microsoft as a bug only and will be fixed in a future version of Windows.

Since I think the principle of Least Privilege should be applied, we can fix this by our own with two simple steps.

DSACLS:

Remove the ACE with Enterprise Key Admins group:
dsacls "dc=dev,dc=secid,dc=se" /R "dev\Enterprise Key Admins"

Add a new ACE with Enterprise Key Admins group only granting Read and Write Property on the ms-DS-Key-Credential-Link attribute:
dsacls "dc=dev,dc=secid,dc=se" /G "dev\Enterprise Key Admins":RPWP;msDS-KeyCredentialLink /I:T

And now it feels more comfortable having that group around. Still wondering if Account Operators will need full control of that group. Hopefully, that will be more clear in the future.

Edit 2017-07-28 to add:

People have asked me (latest in this blog post comments section) if I have reported this to Microsoft and what the answer was.

This was reported to MSRC 12/29/2016.
They opened a case and we had a few discussions about it and 1/23/2017 they decided it’s not a true vulnerability since:

Quote MSRC: The reason being is that customers should not be adding new members to groups of high-privilege without full understanding of what they are doing.

I don’t know if there are any new guidance for their customers, but I haven’t seen anything on this subject.

And I still think it should be protected as all the other Default High-Privileged groups or be removed.

Edit 2017-08-11:

Michael Frommhold @ MSFT has released a PowerShell script to manage this: Enterprise Key Admins group FullControl remediation

10 thoughts on “ADPREP Bug in Windows Server 2016

    1. Daniel Post author

      Thank you for your question. Yes I have reported this to MS and they only accepted it as a bug. I have updated the post at the ending that I have reported this to MSRC with a small quotation of the reason “The reason being is that customers should not be adding new members to groups of high-privilege without full understanding of what they are doing.”

      Reply
  1. Anon

    Great post.

    Ned, so what happens to all the forests upgraded pre 1709? 🙂

    The bit that concerns me from the Microsoft response isn’t customers adding users to “groups they don’t understand” it’s rogue admins self elevating to EA level via a DSA console / powershell and this very handy, poorly secured group.

    That much should be obvious and I find the official reply to this situation extremely concerning – it at least reads that Microsoft do not appreciate what they’ve done to customer’s forests by introducing this huge vulnerability.

    Reply
  2. Pingback: IT Security Weekend Catch Up – November 19, 2017 – BadCyber

  3. Chad Simmons

    Thanks for the incredibly helpful tip about moving the FSMO role to the Windows Server 2016 domain controller.

    Reply
  4. Anonymous1

    Well, i’d consider it a big deal considering that our domain was just pen-tested and we got owned due to this vulnerability.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

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