本文解释了将AD设置复制到隔离networking中的testing机器的一个简单过程。 显而易见的问题是，如果孤立的森林物理连接到生产你拧。
我怎样才能安全的防范呢？ 有没有可能更改林根域名？ 如果连接到生产，这甚至足以防止冲突吗？
The obvious issue is that if the isolated forest gets physically connected to production your screwed.
不仅仅是因为你把它连接到你的生产networking，而是因为它有和你的生产DC一样的IP地址，生产域客户可以通过DNSfind它并试图与它通信。 所有的DC通信都以DNS开始。 域客户端通过查询DNS查找DC的SRVlogging来查找DC。 如果您要更改testing域控制器的IP地址，则生产域客户端将无法find它，并且不会尝试与其通信。
现在，我不是说把这个重复的DC连接到你的生产networking是一个好主意，即使你改变了IP地址，我只是澄清，没有“魔术”在引擎盖下进行。 如果生产客户端无法通过DNSfind此DC，则无法与其通信。
克隆域控制器以防止生产损坏时，Microsoft支持部门有一个最佳实践。 我假设您的testing环境中有一个DC：
打开pipe理命令提示符，重置testing域控制器的计算机帐户密码（TWICE）：netdom resetpwd / server：/ userD：Administrator / passwordD：*
如果有任何Forest信任，请打开pipe理命令提示符重置信任密码。 如果没有AD信任，则可以跳过。 请记住，对于任何儿童领域，这需要做到每个孩子，并从每个孩子到根。
netdom trust / domain：/ resetOneSide / passwordT：/ userO：administrator / passwordO：*
使用“Active Directory用户和计算机”，“查看高级”，find禁用的krbtgt帐户（默认情况下位于用户容器中）。 重新设置密码两次。 使用复杂的密码，并取消选中“用户必须在下次login时更改密码”框。 此密码的logging不需要logging，因为帐户始终被禁用。 但是，密码用于派生Kerberos密钥。
正如joeqwerty所说，要小心IP地址。 另外，您只需要在testingnetworking上进行服务的DNS服务器。 确保DC正在该服务器上注册，而不是生产DNS。 如果正在使用，您还需要考虑WINS。
虽然我们没有连接到生产networking，但当我们进行模拟森林恢复时，上述过程是众多步骤的一部分。 我们现在将虚拟机保留在专用networking上，以便进行有风险的AD更改时进行紧急恢复。