MailBag: RODCs – krbtgt_#####, Orphans, and Load Balancing RODC Connection Objects



AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at (hosted at Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either as you do today, or at our new site Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!


Dougga here to answer a couple of quick RODC related questions.  I have been the fortunate PFE to perform ADRAPs (Active Directory Risk Assessment Program) that have had more than the average number of RODCs. I have also reviewed environments with only a few RODCs. During these risk assessments a couple of questions have come up regarding RODCs that I would like to share with you (including a bonus on orphaned krbtgt_##### accounts).

1. What is the krbtgt_###### account?

2. How can I verify the connection objects to the RODCs are balanced on the bridgehead servers in the hub site?

You should start off knowing what the krbtgt account is and then that knowledge will help you understand why each RODC has its own special krbtgt account. So let’s do some quick review.

I could try to explain what the krbtgt account is, but here is a short article on the KDC and the krbtgt.

“All instances of the KDC within a domain use the domain account for the security principal "krbtgt". Clients address messages to a domain’s KDC by including both the service’s principal name, "krbtgt", and the name of the domain. Both items of information are also used in tickets to identify the issuing authority. For information about name forms and addressing conventions, see RFC 4120.”

Likewise a snip for the RODC krbtgt_##### account:

“The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different krbtgt account and password than the KDC on a writable domain controller uses when it signs or encrypts ticket-granting ticket (TGT) requests. This provides cryptographic isolation between KDCs in different branches, which prevents a compromised RODC from issuing service tickets to resources in other branches or a hub site.”

So the answer to the first question after reviewing the previous two links is apparent. The krbtgt_##### account is unique to each RODC and minimizes impact if the RODC is compromised. The RODC does not have the krbtgt secret. It only has its own krbtgt_##### secret (and other accounts you have allowed). Thus when removing a compromised RODC, the domain krbtgt account is not lost.

<Bonus material: Orphaned Krbtgt_##### accounts>

I found some orphaned krbtgt_##### accounts in one of my ADRAPs. Orphans would be defined by krbtgt_##### without a backlink to an existing RODC computer account. The ADRAP tool does not look for these so I set off to my lab to find out how to discover them.

I attempted to cause krbtgt_###### accounts to be orphaned. I can create one, however, normal demotion and metadata cleanup process will remove the krbtgt_##### account. So in the end, I don’t see this as a common occurrence and if it does exist in your environment it is likely from a failed RODC that has not had the metadata properly cleaned up.

The following PowerShell commands can help you identify your krbtgt_##### accounts and if any are orphaned.

Import-Module ActiveDirectory

get-adobject -server <SERVER NAME> -filter { (objectclass -eq "user") -and ( name -like "krbtgt*") } -properties * | FT Name, msDS-KrbTgtLinkBl


In my lab the command is showing two accounts. The krbtgt account for the domain and it is not associated via a back link to any RODC and IS NOT an orphan. However, you can see my RODC (DC103-RODC) is linked to krbgt_28896 and in this case not orphaned either.

Warning: DO NOT delete the domain krbtgt account.

If you find an orphaned krbtgt_##### account verify the RODC is no longer a domain controller before deleting the orphaned account.

You can see the same thing using adsiedit.msc or your favorite LDAP browser:


The window on the left shows the properties of the krbtgt_38896 account. You will likely need to click on the “filter” button and select “BackLinks” to show the back linked attributes.

The window on the right is the properties of the RODC account. The highlighted attribute is the forward linked attribute, so no need to modify the filter to see that attribute.

So hopefully you can see the benefit of using the script to discover the krbtgt_##### accounts.

</End of Bonus material. >

The second question is regarding load balancing the RODC connection objects coming from the RWDCs in a hub site.

What if you have a lot of RODCs connected to a hub site. Are the connection objects load balanced? This is an improvement in Bridgehead servers that is not well known. This improvement removes a need to run any scripts to load balance RODC connections. To verify the connections are balanced you could count them – okay if you only have 4 or 5 RODCs that would be okay, but what if you have 50, or a hundred, or a couple hundred? Nope, I am not going to count them either.

Let’s count them with PowerShell.

Open PowerShell on a 2008 or 2008R2 member server and there are only two commands needed (if you count importing a module) to see the distribution of RODC connection objects. In the command where I am looking for the RODC connection objects, it will find the “automatically” generated connections named “RODC Connection*.” If for some reason someone has modified or manually created these objects, the command will likely not find those connection objects.

Command #1: import the active directory module

Import-Module ActiveDirectory

Command #2: Find, count, and group the RODC connection objects

get-adobject -filter {objectclass –eq "NTDSconnection"} -searchbase ‘CN=Sites,CN=Configuration,DC=contoso,DC=com’ -properties fromServer | Where-Object {$ -like ‘RODC Connection*’} | Group-object fromServer | FT -auto

The result will be a count of connections per bridgehead server and you will easily be able to see if the connection objects are evenly balanced across bridgehead server.