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.

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.

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).

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.

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