AD域环境是微软整个产品体系中非常重要的一个系统，是大部分微软应用的基础。在某些情况下由于公司规划原因或并购，会需要做AD域的迁移整合工作，或是两个AD域跨林进行资源访问。

这部分由于微软官方有比较详细的资料说明和实施步骤，所以本文就不再对此进行详细描述，仅对实施AD整合过程中一些比较容易遇到的问题进行说明，丰富大家对此场景的了解。

跨林访问的授权方式

背景

最近笔者实施了一个域整合的项目，由于客户公司并购，需要将用户和组全部从以前所在的A域全部迁移到新的B域（使用微软ADMT迁移工具），但是由于一些其他原因，用户需要逐步迁移，并且持续时间会非常长，大约1年（账户组会提前全部进行迁移）。

在此期间将会有一部分用户仍然使用旧环境A域的账号继续使用，一部分已经迁移的用户则使用迁移到新环境B域的账号使用。

在此场景下，需要考虑在这个新旧环境都有用户，并且文件服务器资源都还在旧域A域的情况下如何规划用户的授权问题。

文件服务器一般为了方便管理都会对组进行授权，所以本文主要讨论对组授权的场景，也就是B域用户访问A域文件服务器的授权场景。单独的用户授权的场景比较简单，本文不做讨论。

根据AD中用户访问资源的工作机制，我们可以了解到，当用户访问文件服务器资源时，会首先和资源所在的域控进行身份认证，确认用户账户是否有权限。对组授权则是会查看用户账户信息的隶属组信息进行判断。

如果用户账户属性信息中，所属的组刚好在资源的权限中也有同样的组，则按设置的权限的进行访问。

根据上述的工作原理，我们可以得出结论，如果需要授权只需要在A域的文件服务器上对共享资源授予需要的组的权限，然后再到B域中将用户加入到对应的组中即可。（A域所有组都已经使用ADMT带SID History跨林迁移到B域）

但是在笔者实际测试的中，发现并和我们设想的不一样，部分用户加入到了B域对应的组成员中并没有获取到对应的权限，而是需要将用户在A域也加入到同样的组成员方才会有效果。反复测试都是如此。

经过详细的测试分析，发现其实这个问题非常简单，也并非我们理解的工作有问题，而是我们忽略了迁移的组的类型的问题。

因为组有本地域组、全局组、通用组几个类型，根据组的类型的定义，不同类型的组当然会有不通的情况。以下就将测试结果直接分享给读者：

通过上表可以看出，由于不同类型组的作用域范围不一样，只有全局组和通用组的类型是以用户自己所在域的权限为准，本地域组只能以资源所在域的权限为准。

同前面描述的项目中在完成用户迁移后，发现有部分用户无法登陆，登陆提示：

During a logon attempt, the user's security context accumulated too many security IDs

通过错误描述可以直接比较快找到线索，微软官方文档描述：

Windows****系统包含一个限制，限制用户的安全访问令牌不能超过1,000****个安全标识符（SID****）。当用户验证访问权限以与服务器建立新会话时，该用户不能是该域中超过1,000****个组的成员，如果超出此限制，则拒绝访问服务器

参考链接：

https://support.microsoft.com/en-us/help/275266/error-message-during-a-logon-attempt-the-user-s-security-context-accum

以此笔者检查环境并回忆项目实施过程，果然发现无法登陆的用户都隶属于大量的组的组成员。

虽然项目实施的某个国际大公司的AD环境，确实AD中有建立非常多的组，但还是比较难达到1000的限制。

最后笔者发现主因是本次项目过程中AD用户和组迁移进行了两次，而每次都会要进行带SID History进行迁移，所以每个用户的所属组的数量就都“乘3”了。那些本来就所属组较多的用户在迁移2次后也就达到1000的限制。

找到了原因，解决办法也就很简单了，对这些无法登陆的用户进行整理，将它从不需要的组中剔除，降低到1000个隶属组之下即可。

使用ADMT进行AD用户迁移时，如果林内迁移，那么用户账户是移动的方式，完成迁移后源域的用户账户将消失；如果是跨林迁移的方式，那么用户账户是复制的方式，源域的用户账户仍然将会保留。
使用ADMT迁移用户可以在多个域中迁移多次，只要是带SID History即可保留在源域的权限。
使用ADMT进行迁移时需要配置禁用SID 筛选功能，测试发现如果在Windows Server 2016中文版环境下禁用SID 筛选命令没有效果，而英文版本则可以正常运行。中文版的解决方法可以是下载英文语言包，将系统语言全部调整为英文语言则可以正常执行。

作者：范博文