SID历史保留需用ADMT工具并启用双向信任及域策略，PowerShell等无法实现；它仅保障资源访问延续，不迁移用户配置或绕过硬件绑定许可。
用户账号迁移时保留 sid 历史，核心目标是让新域账户能继承旧账户在文件权限、共享资源、组策略应用等方面的访问能力——不是“复用”旧 sid，而是让系统识别“这个新账户等同于那个旧账户”。这需要工具支持与策略配合，不能靠手动改注册表或复制文件实现。
ADMT 是唯一支持原生 SID 历史保留的官方方案
Active Directory Migration Tool（ADMT）是微软唯一内置 SID 历史（SID History）写入能力的工具：
- 迁移时勾选“启用 SID 历史”，ADMT 会将源账户的 SID 写入目标账户对象的 sidHistory 多值属性中；
- Windows 认证过程自动检查该属性：用户登录后，访问令牌不仅包含新 SID，还会带上 sidHistory 中的所有旧 SID；
- 这意味着对 NTFS 权限、共享文件夹 ACL、打印机权限等依赖 SID 的资源，无需重新赋权即可继续访问；
- 必须提前在源域与目标域之间建立双向信任，并在目标域 DC 上启用 “为受信任域启用 SID 历史” 策略（默认禁用，路径：组策略管理 → 域控制器策略 → 安全选项）。
PowerShell 或 CSVDE 无法保留 SID 历史
这类轻量级同步方式本质是“新建账户”，不涉及身份延续性：
Handsfree Windows Control
下载
通过 handsfree-windows CLI控制 Windows 本机应用 (UIA) 和浏览器 (Playwright) 的引导技能，用于自动化或测试桌面应用。
- New-ADUser 创建的是全新安全主体，SID 完全由目标域生成，与源账户无任何关联；
- CSVDE/LDIFDE 只导出/导入属性文本，sidHistory 是二进制安全属性，无法通过纯文本方式写入；
- 即使手动用 Set-ADObject 尝试添加 sidHistory，也会失败——该属性只能由域控制器在受信迁移上下文中写入，普通管理员无写入权限。
SID 历史不是万能钥匙，有明确使用边界
它解决的是“访问延续”，但不等于“配置继承”或“状态同步”：
- 用户配置文件（AppData、NTUSER.DAT）、注册表设置、本地证书、已映射驱动器等仍需单独迁移（如 Profile Wizard 或 USMT）；
- 软件许可证若绑定机器 SID 或硬件特征（如加密狗、TPM 绑定），sidHistory 无效；
- 跨林迁移时，sidHistory 默认被禁用，需额外启用林信任的“允许 SID 历史”选项，并确保目标林功能级别 ≥ Windows Server 2003；
- 启用 sidHistory 后，建议定期审计：用 Get-ADUser -Identity user -Properties sidHistory 查看是否写入成功，且值非空。
替代思路：不用 SID 历史，也能减少权限重配工作量
若因安全策略禁止启用 sidHistory，可采用间接方式维持访问连续性：
- 迁移前，把旧账户加入目标域中对应的安全组（如 “Finance-Access”），再将新账户加入同一组——权限实际落在组 SID 上；
- 对关键共享文件夹，用 icacls 批量替换 ACL 中的旧账户 SID 为新账户 SID（需先获取双方 SID，命令如：icacls D:\share /replace:s-1-5-21-xxx-1001:s-1-5-21-yyy-1002 /t）；
- 借助 subinacl.exe 或 PowerShell 的 Set-Acl 脚本，批量更新注册表项和文件系统的权限继承链。
