The Advantage of Using an RODC Rather Than a DC

Q: Will the new read-only domain controller (RODC) feature in Windows Server 2008 address the risks of domain controllers (DCs) that are placed at remote sites, such as branch offices, that aren’t as physically secure as the corporate data center?

A: You can now configure DCs as RODCs in Server 2008, which will address some, but not all, the risks. RODCs receive one-way replication from other DCs, thereby maintaining a local replica of the Active Directory (AD) domain. RODCs will fill the need to have a replica of AD locally at branch offices for fault tolerance, conservation of bandwidth, and performance reasons. Because the DC is read-only, an attacker that takes over the DC can’t change group memberships or user accounts in such a way that they replicate back to DCs at the data center and beyond. However, RODCs don’t address every risk. Someone very skilled or equipped with malicious programs created by a skilled programmer still might be able to exploit physical access, take over the RODC, and succeed in making the DC authenticate them to other computers on the network as an administrator or other privileged user. Although an attacker won’t be able to exploit the RODC to permanently change anything in AD, he could temporarily exploit the RODC to break into other computers in the domain or forest. Nevertheless, RODCs are a very important step in the right direction. . . .

Excellent Article

sharath_hp2003@yahoo.com April 17, 2008 (Article Rating:

)

Thanks for taking the time to give us your feedback. Glad you found this article helpful!

AnneG_editor May 02, 2008 (Article Rating:

)

Note that the statement regarding attacking an RODC is misleading as it doesn't account for all the extra measures that were built into RODC to ensure that attacks that happen within a site don't have any reach to resources elsewhere. Note that a site is typically a branch site that only contains resources from a single domain (even in a multi-domain deployment). The main measures are the enhancements in the Kerberos authentication logic, that are ignored by the author. The fact is that RODCs don't share the same krbtgt account and password as writeable DCs do - instead every RODC has its own krbtgt account. So when a computer or user that has been authenticated by an RODC wants to access a resources outside of the scope of that RODC (for example a resource in a different site), it will - as always - have to request a Kerberos service ticket for that resource. Since the RODC can't generate this, the request is forwarded to a writeable DC, which strips away the whole PAC of the Kerberos ticket coming from the RODC (as it could include a forged group membership) and regenerates it based on its own AD data.

Se even if a site contained resources from multiple domains (let's say DOM1 and DOM2), a successful attack of RODC of DOM1 would only allow to elevate privileges on computers in THAT site from THAT domain - i.e. from DOM1. For example, a skilled attacker might be able to add himself to an AD group on the RODC that grants access to DOM1 computers in that site. However, a computer from DOM2 does not trust the RODC of DOM1 and thus would not be vulnerable to this attack. Instead - to receive a service ticket for the resource from DOM2 (even if it's in the same site), the RODC of DOM1 would forward the request of the kerb service ticket to a hub-DC, which would re-generate the kerberos ticket and then follow the trust path to a DC from DOM2.

So while an attacked RODC doesn't save you from every harm, it saves you from much more than the author suggests.

winntmag@grillenmeier.de October 09, 2008 (Article Rating:

)

You must log on before posting a comment.

If you don't have a username & password, please register now.