Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Anonymous (anonymousANONYMIZER.COM)
Date: Sun Feb 25 2001 - 19:46:00 CST
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.