After preparing AD and installing the first Windows Server 2019 DC into an existing AD environment, it was noted that there were unresolved SIDs listed at the root of the domain. This was corelated to the AD 2019 upgrade as permissions had been audited and cleaned up prior due to previous issues in the environment. Previously all DCs were Windows Server 2012 R2 with all updates installed.
After running ADPrep, these new "Account Unknown" entries were present at the root of the domain. The screenshot below is a reproduction of the original issue.
These entries are added with a limited set of permissions, so the UI shows them as a special permission.
What Are They?
A clue is obtained by looking at their Security ID (SID). The SIDs are listed below:
(S-1-5-21-761248450-4132719768-284217924-526)
(S-1-5-21-761248450-4132719768-284217924-527)
For reference, if you want to know more about these special SIDs then take a look at Well-Known SID Structures
If we look in that article then we can see that these SIDs are listed as:
KEY_ADMINS
S-1-5-21-<domain>-526
A security group for delegated write access on the msdsKeyCredentialLink attribute only. The group is intended for use in scenarios where trusted external authorities (for example, Active Directory Federated Services) are responsible for modifying this attribute. Only trusted administrators should be made a member of this group.<15>
ENTERPRISE_KEY_ADMINS
S-1-5-21-<domain>-527
A security group for delegated write access on the msdsKeyCredentialLink attribute only. The group is intended for use in scenarios where trusted external authorities (for example, Active Directory Federated Services) are responsible for modifying this attribute. Only trusted enterprise administrators should be made a member of this group.<16>
That's Great, But Where Are They?
Now that we know the names of these build in SIDs, Let's go look for them in AD DS.
But that draws a blank. Nothing to be seen here
As you can see, there are no groups that match the search of *key* in AD DS.
Why?
Well, that is because they have not yet been created. DOH!
No, I Am Your Father
<link to what Vader actually said>
What creates those groups then? Who or what will create them?
Well, it is not a manual task. Windows will create them, but only a Domain Controller running a newer version of the OS knows anything about these groups. That means if your Primary Domain Controller Emulator (PDCe) is an old version of Windows, then it has nothing to do. The PDCe needs to be running at least Windows Server 2019.
If we look at the existing PDC emulator role holder, DC-1, that explains what is happening. This is a Windows Server 2012 R2 machine.
Time to transfer the PDCe FSMO role holder to a Windows Server 2019 machine.
The name you see below is a clue that it runs on Server 2019.
NOOOOOOOOOOOOOOOOOOO
<the correct response to what Vader said>
Now that the PDC emulator is running on Windows Server 2019, it knows that the Key Admins group should be created.
If we then check AD again for the group, it is now present and correct!
The same is true, unsurprisingly, if we check the ACLs at the root of the domain. The <account unknown> is no longer visible.
Cheers,
Rhoderick
