跨域迁移后权限丢失若由sid history未启用或映射失效引起，核心是确保目标域能正确识别源域身份，需启用sid history、刷新kerberos令牌，并用admt安全翻译或subinacl批量更新acl中源sid引用。
跨域迁移后权限丢失，若确认由sid历史（sid history）未启用或映射失效引起，核心不是“修复旧sid”，而是让目标域系统能正确识别并信任源域身份——这依赖ad层面的机制设计，而非文件级手动调整。
先确认是否真为SID History相关问题
权限丢失但用户仍可登录，且访问共享、文件夹或应用时提示“拒绝访问”“无权查看属性”，同时事件查看器中出现大量ID 4670（权限被拒绝）、4624（登录成功但令牌含旧SID）事件，就需重点排查SID History：
- 在目标域DC上运行：Get-ADUser -Identity username -Properties "sidhistory"，若返回空值，说明迁移时未启用SID History
- 用whoami /all在客户端检查登录令牌，看输出中是否包含源域SID（如S-1-5-21-xxx…），没有则SID History未生效
- 检查迁移工具（如ADMT）日志：是否勾选了“启用SID History”、是否因权限不足跳过该步骤
补救：启用SID History并刷新令牌
若迁移已完成但未启用SID History，不能直接回滚。可行路径是补充启用并强制令牌更新：
- 确保源域与目标域之间已建立双向林信任（非外部信任），且信任属性中启用了“启用SID筛选器”（默认关闭，需手动清除）
- 在目标域DC以企业管理员身份运行PowerShell：
Set-ADUser -Identity "username" -Add @{"sidHistory"="S-1-5-21-源域RID-用户RID"}（RID需从源域查出，可用Get-ADUser -Server 源DC -Identity username -Properties objectSid获取） - 用户需完全注销再重新登录（仅锁屏或切换用户无效），系统才会拉取含SID History的新令牌；也可运行klist purge清空本地kerberos缓存后重认证
同步修复NTFS与资源ACL中的残留引用
SID History启用后，用户能通过身份验证，但原资源上的ACL仍指向源域旧SID——这些条目不会自动转换，需主动映射或替换：
- 对共享文件夹/DFS根目录，使用icacls配合subinacl或PowerShell的Set-Acl批量将源SID替换为目标域等效组，例如：
subinacl /subdirectories "D:\Share\*" /replace=s-1-5-21-源SID=s-1-5-21-目标SID - 更稳妥方式是用ADMT的“安全翻译”功能：在目标域GPMC中导入GPO前，先在ADMT控制台创建SID映射文件，再对已迁移对象执行“安全主体翻译”，自动更新ACL中所有源SID引用
- 数据库、SharePoint、TFS等应用层权限需单独处理：如SharePoint需运行stsadm -o migrateuser，TFS需在管理控制台重新映射域用户或使用tfsconfig identities
避免再次发生的关键设置
下一次跨域迁移前，必须把SID History作为默认启用项，而不是事后补救：
- ADMT迁移用户时，务必勾选“启用SID History”，并在“选项”页确认“允许使用SID History进行访问”已启用
- 目标域功能级别至少为Windows Server 2003 Native Mode（推荐2012 R2+），否则SID History不可用
- 禁用“SID筛选器”：在信任属性中取消勾选“启用SID筛选器”，否则DC会丢弃含源SID的令牌请求
- 迁移后立即验证：用普通用户登录，访问原源域共享路径、打开原个人文档库、尝试保存到原网络驱动器，三者全通才算闭环
