嵌套组迁移关键在于目标环境能否还原源端组结构、成员关系、作用域及权限继承逻辑，需确认作用域兼容性、分步迁移、启用sidhistory并验证令牌权限。
用户组（Group）本身不是“在用户组中”的对象，而是包含用户的容器。所谓“用户组中用户组”，通常指嵌套组（Nested Groups）——即一个组作为另一个组的成员。跨服务器账号同步时，要实现嵌套组的无缝迁移，关键不在“同步工具是否支持组中组”，而在于目标环境能否还原源端的组结构、成员关系、作用域（Domain Local / Global / Universal）及权限继承逻辑。
确认嵌套组类型与作用域兼容性
AD 中嵌套组受域功能级别和组作用域限制：
- 全局组（Global Group）可嵌套在其他全局组、通用组或域本地组中；
- 域本地组（Domain Local Group）只能被同域的其他域本地组嵌套（跨域不支持）；
- 通用组（Universal Group）支持跨域嵌套，但要求林功能级别 ≥ Windows 2000 本机模式，且所有参与域均启用通用组复制。
若源环境含域本地组嵌套，目标为跨林或新林，则必须提前重构为全局/通用组，否则同步工具会跳过或报错。
用ADMT或PowerShell还原嵌套结构
ADMT 默认支持组及其成员关系迁移，但不自动重建嵌套层级——它迁移的是“组对象 + 直接成员”，而不会递归解析“某成员是组，该组本身还有成员”。需分两步处理：
- 先迁移所有底层组（无嵌套依赖的组），确保其在目标域存在且 SIDHistory 已写入；
- 再迁移上层组，并在迁移选项中勾选“迁移组成员身份”+“迁移组嵌套关系”（ADMT v3.2+ 支持该选项）；
- 若用 PowerShell，需先导出嵌套树：
Get-ADGroupMember -Identity "Mgrs-Team" -Recursive | Where-Object {$_.objectClass -eq 'group'}，再按依赖顺序逐层新建并 Add-ADGroupMember。
注意SIDHistory与权限延续
嵌套组的价值常体现在权限继承上（如“A组 → B组 → 文件夹ACL”）。若目标域未启用 SIDHistory，或迁移后未刷新令牌（Logoff/Reboot），用户登录时将无法获得嵌套链路上的间接权限。
- ADMT 迁移组时默认启用 SIDHistory（需目标域 Forest Trust 启用 “Enable SID History” 属性）；
- PowerShell 新建组后，必须手动为每个嵌套组调用
Set-ADGroup -Replace @{"sIDHistory"="S-1-5-21-xxx"}（仅限企业版域控制器且有 Schema 权限）； - 验证方式：在目标域用
whoami /groups /fo list查看用户令牌中是否包含源组 SID。
第三方工具的预检与映射能力
如 ADManager Plus、Netwrix Advanced AD Repair 等工具提供“嵌套深度分析”和“依赖图谱可视化”，可在迁移前识别循环嵌套、跨域非法引用等风险点，并支持自定义映射规则（例如：将源域的 Finance-Local 组自动转为目标域的 Finance-Global 并保留嵌套路径）。这类工具适合中大型环境，避免手工梳理数百个嵌套关系。
