There a few other ways to get to a hack of this sort. These also assume a
compromised DC in one domain of a multidomain Forest.
In the organization I work for we have not discovered a satisfactory resolution to
these exposures. We may be heading towards the implementation of multiple forests.
Some partial resolutions are as follows:
Use DNProtect to keep site-connection objects secured against access by SYSTEM
context. Problem is, you need to rerun DNProtect every time any change occurs to the
object and it isn't offiially supported. Additionally, the only published info on
this utility seems to be a mention of it in "Notes from the Field"
Promote Replica DCs using the Domain Admin of that domain, not Domain Admin of the
empty root domain. This prevents some issues with ownership of objects being marked
as the BUILTIN\Administrator account. If ownership is flagged to this account Admins
in other DCs can manipulate the objects. This is easy to prevent but runs counter to
MS's recommendations.
It appears that keeping separate domains from sharing the same sites has some positive
effect, but that is ridiculous. Unfortunately, the only means of clearly providing
the fault isolation one would expect from separate domains appears to actually be
separate forests. Maybe we just don't get this product. It seems fine for smaller
organizations, or organizations which already use a single centralized group for all
IT administration. In a decentralized environment, it appears to demand either a
change in the administrative structure or separate forests.
