0

Unresolved RID 526 and 527 After ADPrep

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.

Account Unknown Entries After Windows Server 2019 ADPrep

These entries are added with a limited set of permissions, so the UI shows them as a special permission.

Account Unknown Entries After Windows Server 2019 ADPrep - Advanced View

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

Search AD For Groups Containing The Element "Key"

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.

OS Version Of The Initial Primary Domain Controller Emulator FSMO Role Holder

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.

Primary Domain Controller Emulator FSMO Role Holder Transfered to a Windows Server 2019 Machine

 

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!

Search In AD For Group Containing Element "Key" Now Finds Match

The same is true, unsurprisingly, if we check the ACLs at the root of the domain.  The <account unknown> is no longer visible.

No Account Unknown Entries As PDCe FSMO Role Moved To Windows Server 2019

Cheers,
Rhoderick

Rhoderick Milne [MSFT]

Leave a Reply

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