前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >AD域整合的注意事项

AD域整合的注意事项

作者头像
嘉为蓝鲸
修改2019-08-15 14:42:09
1.2K0
修改2019-08-15 14:42:09
举报

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

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

跨林访问的授权方式

背景

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

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

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

授权问题

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

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

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

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

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

问题原因

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

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

迁移的类型

B域新建用户

迁移到B域的用户

本地域组

加入迁移过来的本地域组不能访问A域资源

能访问A域资源,访问权限以其在A域的所在组为准

全局组

加入迁移过来的全局组能访问A域资源

能访问A域资源,访问权限以其在B域的所在组为准

通用组

加入迁移过来的通用组能访问A域资源

能访问A域资源,访问权限以其在B域的所在组为准

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

迁移后用户无法登入

背景

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

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 筛选命令没有效果,而英文版本则可以正常运行。中文版的解决方法可以是下载英文语言包,将系统语言全部调整为英文语言则可以正常执行。


往期文章

1.【干货】DevOps的演进与落地价值

2.运维大数据平台落地构想

3.浅谈企业如何建设云管理平台(CMP)

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-08-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 嘉为科技 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 跨林访问的授权方式
    • 背景
      • 授权问题
        • 问题原因
        • 迁移后用户无法登入
          • 背景
            • 问题分析解决
            • 其他注意问题
            相关产品与服务
            迁移服务平台
            迁移服务平台(Migration Service Platform,MSP)是帮助客户将系统从源平台迁移到腾讯云的工具。为迁移上云项目提供源端资源调研、上云规划、目标资源创建、批量迁移实施等能力,帮助降低客户迁移上云的复杂度,提升迁移效率。迁移服务平台 MSP 不收取任何额外费用,您只需为购买的资源及 DTS 数据迁移工具付费。
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档