First published on TechNet on Mar 15, 2013
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.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa378170(v=vs.85).aspx
“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:
http://technet.microsoft.com/en-us/library/cc753223(v=WS.10).aspx
“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 {$_.name -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.
Cheers!