这篇文章主要介绍了怎么在多域林中恢复活动目录根域,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。
我最近处理过一个需要对整个林根域进行恢复的情况。结构本身是相对比较简单的,包含两个域,一个空的林根以及一个包括所有用户、计算机等的子域。其中也只有大约4000个用户。
但存在两个(几乎是致命的)问题。首先,该组织在根域中仅仅建立了一个域控制器。第二,更不幸的是,那个域控制器已经有超过10个月没有进行备份了。尽管根域控制器是一个RAID-5的磁盘配置,在同一天内,灾难发生了而且驱动器里面有两个挂掉了。
这种类型的配置可能是承袭了微软在Windows 2000的早期所信奉的一种***做法。当时的建议是创建一个空的根域,这样在子域名字被更改时,可以对其进行添加或者移除(不能在一个域被定义后再对其进行改名)。
这种方法没有得到延续,但是,因为多个域林会有其它的复杂性:在一个交叉域组中恢复组和用户之间的后端链接,在全局目录服务器只读上下文中存在的延迟对象,以及其它的相关问题。为了避免这些问题,一些组织不得不把多域结构拆为单域。
在这个例子中,两个域分别为Corp.com和EMEA.Corp.com,其中Corp-DC1是根域中的域控制器,而EMEA-DC1和EMEA-DC2为子域中的域控制器。
请注意,所有的客户——包括用户、工作站以及服务器——没有被这个问题所影响,这使得我们有时间去指定并颁布一个处理计划。
挑战
这种情况下有若干问题和挑战,包括:
我还没有见过林根域需要被恢复的例子,并且我也找不到谁见过
恢复10个月以前的备份会在工作良好的子域控制器的林中引入延迟对象
当恢复1月份的备份时,在根域控制器中修改系统时间的话会遇到什么问题?
是否需要对Corp.com和EMEA.corp.com两个域之间的信任关系进行修复?同样地,是否需要重置安全隧道密码?
是否有必要使用一个授权的备份?
当还原Corp.com 1月份的备份时,会遇到什么样的复制问题?
尽管如此,在这次灾难中也有一些正面的因素:
在根域中没有用户或者工作站——仅仅包括管理账户和域控制器。因此,当还原10个月以前的备份时,延迟对象的危害很小。
没有对根域控制器进行过任何修改(比如活动目录对象)(尽管需要关注配置容器的更改)
域名服务器被委托给子域。因此,对于客户而言,EMEA.corp.com是域名独立的,而且在父域中没有资源。
恢复计划
最初的想法是将EMEA域控制器恢复到1月份的备份,还原Corp域的域控制器,前滚子域控制器,然后调整到当前时间。这个20步的处理过程需要停机若干天,并且因为其复杂性和破坏性被驳回了。
我们***采用了下面这种更简单的计划:
还原两个子域控制器的当前备份(以及根域控制器1月份的备份),将三个域控制器变为一个私有网络上的三台计算机。
解决问题,然后重复生产林的步骤。
在Corp.com域中添加第二个域控制器。
备份两个域中的所有域控制器。
整个过程花费了大概3周时间,大部分的时间都用在研究日志、进行还原等等上面。我们对该过程进行了详细的考虑,并有条不紊的对其进行实施,以确保任何事情都能合适地完成。另外,用户不会遇到停机。这意味着,尽管没有根域,林看起来岌岌可危,对于用户认证和我们进行的还原,它都运作良好。我们进行的生产恢复是在不影响用户的情况下,在上班时间里进行的。
恢复过程
恢复过程包括下面的步骤:
1.获取三台计算机,并在私有子网上对其进行配置。
2.在测试计算机上重建EMEA-DC1和EMEA-DC2上当前系统的状态备份。
3.将Corp-DC1 1月份的备份还原到测试计算机。
4.将Corp-DC1的1月份备份上的系统时间设为当前的日期/时间。
5.将墓碑生命期设为365(***)以消除暂时的延迟对象问题。通过ADSIEdit修改cn=Directory Service,cn=WindowsNT,cn=Services,cn=Configuration, dc=pp上的墓碑生命期属性
6.将注册表键严格复制一致性(strict replication consistency)的值设为“1”(严格),以避免复制过程中的延迟对象。
HKEY_LOCAL_MACHINE/System/CurrentControlSet/ Services/NTDS/Parameters ValueName = Strict Replication Consistency Data Type = Reg_DWORD Value Data =1
7.取消检查Corp-DC1上的全局目录参数。在复制完成后再重新启用。
8.使用HPSReports对域控制器进行体检。逐个检查出现的任何错误,直到所有错误都得到了清理:
Netdom Trust/verfy,以验证Corp和EMEA域之间的信任关系。
C:>netdom trust Corp /domain:EMEA.corp.com /verify
The trust between Corp and EMEA.corp.com has been successfully verified.
Repadmin/Replsum /bysrc /bydest /sort:delta,以对林中所有域控制器的复制进行测试。
DCDiag /test:DNS /e /v,以测试林中所有DNS NS的DNS问题。
所有的事件日志。
确保应用程序事件日志显示组策略(the Application event log indicating Group Policy)中的1704(SCECLI)事件都得到应用。同时,检查每个机器的GPResult输出以检查GPO是否正常。
确保您可以通过一个Corp.com账户登录到EMEA域的一个计算机 – 并可以反过来进行 – 以进一步的验证信任关系。
将生产EMEA域中的客户添加到测试EMEA域,并查看是否能被识别。
在每一个域中的域控制器里添加用户和站点,并查看它们是否能复制到所有的域控制器。这对域进行了测试并对NC复制进行了配置。
9.当所有的问题都得到解决后,在生产林中重复这些步骤。
10.在生产根域控制器(Corp-DC1)被还原以后,在那个域中设立第二个域控制器(根域中的第二个域控制器能防止最开始遇到的问题的产生)。
11.对所有的4个域控制器有计划的进行备份。
12.将墓碑生命期属性重置为最小的120到180天。确保严格复制一致性(the strict replication consistency)的值仍为1。
结果
最初,在事件日志中显示了大量的错误和警告,在Repadmin/showrepl报告中也有一些错误。其中很多错误是因为试图修复系统而发生的。在运行一夜之后,大部分的错误都自己得到了修复。我们接下来对剩余的事件进行了处理,直到它们都得到解决。测试和生产环境产生了相似的结果。
1.因为没有启用动态注册,会存在一些DNS问题。结果是我们不得不手动的对一些DNS记录进行配置。
2.在对根域的Corp-DC1域控制器进行最初的还原之后(从旧的备份),可以在目录服务事件日志中找到一个事件分类,包括:
1869 – 在Site-LAN(指的是EMEA-DC1)中发现了GC
1655 – 不能在其中一个站点(指的是EMEA-DC)中找到GC
事件1869和1655是按EMEA和Corp-DC1服务器的顺序记录的
一些1311事件。
一些涉及DNS查找失败的复制不成功
许多1869和1865事件是在查找全局目录时遇到了困难。对所有的这些事件置之不理,复制仍然可以进行,我们可以通过运行Repadmin /replsum /bysrc /bydest /sort:delta来发现这一点:
3.通过DCDiag /test:DNS /e /v报告,我们发现DNS按照预期进行工作。
4.存在许多W32时间事件 – 事件ID为29、24和22 – 不需要采取进一步的措施,就会随着时间而消失。
5.在旧的被还原后的Corp-DC1被放到线上之后,最初会有大量的警告和错误事件。12个小时后,它们都自己得到了修复。
总的来说,还原工作进行得相当好,并且相对没有差错。这是在没有停机时间,而且环境风险极小的情况下得到完成的。不必使用授权备份,并且信任关系也不需要被修复。由于我们已经在测试环境中进行了测试,所有我们有信心将这个计划放到生产环境中。尽管如此,这对您只是“这应该可行”的一个假设,直到尝试过您才可能真的对其进行掌握。
感谢你能够认真阅读完这篇文章,希望小编分享的“怎么在多域林中恢复活动目录根域”这篇文章对大家有帮助,同时也希望大家多多支持亿速云,关注亿速云行业资讯频道,更多相关知识等着你来学习!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。