![Active Directory 迁移和配置文件安全转换(出现问题)](https://linux22.com/image/773509/Active%20Directory%20%E8%BF%81%E7%A7%BB%E5%92%8C%E9%85%8D%E7%BD%AE%E6%96%87%E4%BB%B6%E5%AE%89%E5%85%A8%E8%BD%AC%E6%8D%A2%EF%BC%88%E5%87%BA%E7%8E%B0%E9%97%AE%E9%A2%98%EF%BC%89.png)
这是一篇一般性的帖子,并不寻求针对特定问题的技术解决方案。我只是想提醒业内同事。20 年来,我的职业重点一直是 AD。我专注的领域是迁移和整合项目。我目前在一家组织工作,正在将 4 个域迁移到一个更大的域中。我们遇到了无数问题。我已经连续 6 个月应对了一系列挑战。我以前从未见过这样的事情。
似乎在 2021 年,从一个域迁移到另一个域的久经考验且值得信赖的方法(已有 15 年历史)在用户配置文件迁移(转换)阶段失败了。如果您熟悉 ADMT 或 Quest Migration Manager for AD 等工具,那么您将熟悉安全转换向导/代理,其工作是仔细检查每个文件/文件夹上的每个 ACL,以确保添加了目标域安全主体并赋予其与源域安全主体相同的权限。好吧,似乎在最新的 Windows 10 版本(可能还有之前的几个版本)中,安全转换工具根本无法修改某些文件/文件夹的安全性。这些主要与 Office365 Apps 配置文件文件夹有关。结果是您的用户最终得到的配置文件要么翻译了一半,要么完全损坏。Office 365 应用程序无法正确启动,这意味着您必须为所有受影响的用户重新配置每个 Office 应用程序。如果您有数千个要迁移的应用程序,则要避免这种情况。
除此之外,TPM(信任平台模块)、您的本地身份和云身份结合在一起,形成了一个安全层,传统迁移工具无法对其进行安全转换。基本上,它们锁定任何其他用户帐户即使该帐户对 profile\AppData 文件夹拥有完全权限,也无法访问您的 O365 应用程序配置文件数据。
它不是 100% 一致的,但在 500 多次配置文件迁移中,我看到 75-80% 的时间都是这种情况(可能是特定于构建/Office 应用程序)。摆脱这种情况的唯一方法是向用户提供全新的配置文件。所以各位,下次您执行域迁移并进行配置文件安全转换时,如果出现问题,那不只是您一个人的问题!数百人报告了这个问题,但微软没有给出明确的指示。Quest 将其归咎于“环境”问题。我认为微软的新时代开发人员已经完全失去了域迁移的概念。他们正在构建安全模型,却没有考虑如何保持用户配置文件的“可移植性”。用户配置文件一直是您可以分配给新用户帐户的东西,但现在不是了?
还值得注意的是,MS ADMT 并不正式支持 Windows 10 或 Windows Server 2016/2019。