我不是网络管理员；我在公司的 IT 部门担任完全不同的角色。然而，我对服务器管理方面越来越感兴趣。我了解 AD 的基本知识、域、森林和树、基本 ID 管理等……但没有任何实际经验或特别高级的 AD 知识。目前，我的公司有两个独立的 AD 系统，分布在不同的位置，这是公司历史的遗留问题；但它想将它们合并为一个。这似乎是一项巨大而昂贵的任务。然而，作为这类问题的外行，我想到的问题是 - 为什么？当然，这并不像复制和粘贴（即使在高级水平上）从一个系统到另一个系统那么简单。但究竟为什么会这样呢？究竟是什么让将两个独立的 AD 系统整合在一起成为如此艰巨的任务？任何见解都会有所帮助。
答案1
合并多个 Active Directory (AD) 部署需要规划和测试，但我不知道这是否特别“庞大”或“繁琐”。该产品的设计不允许在不同的 AD 部署之间进行简单的“剪切/粘贴”，但有一些工具可以使此类迁移相当简单（例如 Active Directory 迁移工具）。将来自 AD 的安全主体集成到域中的成员计算机上，可以实现相当复杂的配置，其中有许多边缘情况需要在任何大规模迁移中进行探索。
撇开技术问题不谈，我认为，对 AD 环境进行全面更改的犹豫不决很大程度上源于围绕产品而产生的神话和对可能依赖 AD 但没有充分记录的配置的实际担忧。我曾与一些相当大的 IT 运营公司（财富 1000 强公司）签订过合同，在这些公司中，由于担心“破坏”现有功能，几乎“瘫痪”到无法进行任何大规模更改（对任何系统——不仅仅是 AD）。在我看来，这是变更控制实践不佳和对产品无知的表现。
TL;DR - AD 中的配置信息“驱动”了许多功能，特别是在记录不全和控制不力的环境中，许多人由于害怕“破坏东西”而不愿意对 AD 进行更改。
答案2
合并（或其他转移）的问题之一是辅助项目由 AD 驱动但不受 AD 控制。这些需要全面的清单，并且通常需要单独的行动计划。考虑两个 SQL Server A 和 B，它们可能执行跨服务器功能（例如也涉及文件共享的日志传送），但也使用集成身份验证为多个网站提供服务。每个站点都有不同的用户（假设），他们在不同的时间迁移。用户对每个站点的访问必须在用户移动时得到适应，并且必须在服务器迁移时（再次）得到适应。随着每个服务器的迁移，如果 A 和 B 不一起迁移，跨服务器功能就会中断（或必须更改）。
对于（非常）小的公司来说，简单的解决方案是将所有东西都搬到一起。对于拥有移动计算机、多个站点等的分布式组织来说，实际的答案是，这可能需要几个月的时间，而且每次配置更改（例如服务器迁移）都必须解决一系列新问题。
最糟糕的通常不是微软产品，它们往往是应用程序。我已经这样做了三次，每次都会用硬编码的域假设清除（作为示例）应用程序。即使没有硬编码到域 X，它们也可能被硬编码为一次仅适用于一个域，因此在迁移期间会带来挑战。然后你会发现没有人再维护这些应用程序中的十几个，而且对于一些应用程序，没有人有源代码。但即使是微软的应用程序也各自带来了不同的挑战，需要单独的行动计划（例如，Exchange，因版本而异；还有 sharepoint、SQL Server）。
并且不要忘记大型组织中变更管理的 SOX 要求。
简单的思维实验 - 如果您需要搬家，您有多大可能想出每个需要发送地址变更的人，并且不会错过任何人？这几乎就是 AD 合并所需要的，除了整个企业。要成功进行迁移/合并，需要有一个全面的应用程序清单，并为每个应用程序确定 AD 的使用方式，以及如何缓解迁移/合并。
在大型企业中，这确实不是什么火箭科学，但需要查找和处理大量细节。而且总是有意外发生——例如，有人在恶意服务器上使用的应用程序从隐藏状态变为“如果我必须停止使用该 FoxPro 程序，整个公司都会停止运行”。
答案3
有许多因素使其变得困难，但我会尽量集中于最重要的几点并简短地说。
正如您已经指出的那样，我们之所以有两个不同的林/域，是因为“历史”问题，无论是业务并购，还是不同的业务部门希望对其环境进行不同的控制。结果呢？林/域代表不同的业务需求、安全义务和程序。合并两个林/域的大部分时间都花在了如何让不同方就应该如何做事达成一致，以制定一个通用标准上。
在技术层面，您需要考虑如何保留现有的身份验证和授权基础架构。如何确保所有环境中的用户无论身处哪个林/域，都能以最小的干扰访问所有文件/文件夹/作品。