运维开发网

聊聊VDI虚拟桌面的重复SID问题(下)

运维开发网 https://www.qedev.com 2020-07-26 09:22 出处:51CTO 作者:HaoHu
上一篇聊到VDI厂商说重复SID不是个事儿,可毕竟多年AD的经验在这,重复SID到底有没有问题?

​ 上一篇聊到了主流VDI厂商官方KB告诉咱们,重复SID不是个事儿。可毕竟多年AD的经验在这,SID相同还是不大放心对吧?没问题,咱们往微软的知识库和文档文章去找找答案。

​ 开始寻找最终答案之前,我们来聊一下曾经非常强大的一个“黑科技”工具——NewSID。上一篇咱们也说过,微软官方建议对于复制的计算机,推荐的步骤就是sysprep,关于这一点,可以通过一片官方支持文档来确认:

​ The Microsoft policy for disk duplication of Windows installations

​ 其实我们聊到这里,很有可能您还不是特别了解SID/RID的具体含义。借助这篇支持文章,可以了解一下SID的基本概念。实际上我们说的SID包含了两部分定义,计算机SID(Computer SID)和用户/组账户SID(user account and group account SID),用户/组账户SID是以计算机SID开始的,附加一个后缀。当把Windows通过网络连接在一起时,如果没有这种机制,我们就无法区分不同计算机上相同名称的账户,因而也就无法避免不适当的越权访问。这也是传统上 ,为何批量管理Windows必然需要使用AD活动目录的原因。

​ 所以,当使用复制磁盘的方式来“复制”Windows的时候,微软建议在复制之前使用sysprep的原因。可是,sysprep必须在抽象化之后重启一次,才能生成新的SID,有时我们忘记了这个步骤,或者觉得太麻烦,这时,大神 Mark 提供了一个神奇的工具——NewSID,来直接生成替换新的SID。在以往的很多项目中,我都会使用这个工具快速复制Windows系统。实际上,上一篇Citrix的KB,并没有解释为何重复SID不会影响VDI的制备,而是直接引用了NewSID的微软文章。可以在这里查看:

​ NewSID v4.10

​ 大神后来去了微软,来句题外话,Mark 现在也为Azure做了很多工作,每年我们也会参与Mark发起的Global Azure Bootcamp活动。之后不久呢,大神就停止了NewSID的更新,其原因在一篇文章中进行了描述,原因是在跟Windows研发沟通之后,认为其实不再需要分区分场景一定去做SID的更新。这篇文章发表于之前TechNet Blog站点:

​ NewSID Retirement and the Machine SID Duplication Myth

​ 很可惜,这篇文章貌似不能访问了。记忆退化的我,当年看完了现在印象也不是很深刻。所以只能通过别的方式来进行求证。用这个标题搜索的话,很容易就能发现一些相应的文章,其中一篇非常不错的:

​ The SID debate: To Sysprep or not to Sysprep

​ 我们所担心的,主要是重复SID会不会造成域内账户登录验证的安全风险。那么,重复SID会导致多个账户使用相同SID登录域导致安全漏洞吗?

​ 不会。实际上当尝试从一台计算机连接到另一台计算机时,Windows既不允许使用基于发起连接计算机的SID进行身份验证,也不引用该SID。相反,它要么查看自己的本地安全帐户数据库,允许使用远程系统上的本地帐户进行远程身份验证,要么检查另一台计算机是否绑定到域。如果是后者,它将确定用户是否拥有具有权限的域帐户,或者该域是否是系统设置为信任的域。

​ 本地帐户的SID由计算机的SID和附加的RID(相对标识符)组成。 如果您曾经是AD活动目录的管理员,一定会记得域控制器中有一个角色,叫做RID池主机。是的,域账户的RID由这个角色集中生成并分发。RID从一个固定值开始,并为创建的每个帐户增加一个。这意味着,如果使用本地账户,一旦计算机SID相同,一台计算机上的第二个帐户将获得与克隆上的第二个帐户相同的RID,结果两个帐户会具有相同的SID。这样,在工作组环境,重复SID就会带来问题。而在基于域的环境中,重复的SID不是问题,因为域帐户的SID基于域SID。

​ 如果您觉得这篇文章来自于第三方,取信度不高,那么这里还有两篇文章能够帮助我们了解上述事实。

​ Machine SIDs and Domain SIDs

​ 这篇文章对计算机SID和域SID做了较为详细的阐述,也能够帮助我们理解域内的账户,不论是计算机账号还是用户/组账号,其实都是基于域SID的,所以计算机本身的SID并不会参与到这些账户的验证过程中。

​ 那么,是不是我们就可以忘记SID这件事情,将Sysprep置之脑后呢?当然也不是啦。

​ Sysprep, Machine SIDs and Other Myths

​ 这篇文章其实也说明了,Sysprep做的不仅仅是处理SID,其实还会对Windows系统的其他制备做准备,例如:禁用/启用系统还原、删除/重新生成TAPI设置、清理设备数据库/重新启动完全即插即用设备检测、删除/重新生成网络设置、重设用户首次运行设置等。此外,除了内部任务外,复制阶段还调用外部“提供者”,允许Windows组件开发人员和第三方应用程序供应商为复制准备组件。

​ 实际上,这也是链接克隆支持Sysprep/QuickPrep脚本文件的原因,当我们需要进行一些复杂的安装动作时,依然可以使用sysprep来帮助实现,尽管通过镜像的快照更新和版本控制,这样的步骤越来越少。

​ 当我们的VDI环境位于一个复杂的IT基础架构时,考虑重复SID问题的时候,也需要同时考虑其他系统的集成整合,例如,在架构中使用了“传统”的WSUS/SCCM进行Windows管理时,由于Client ID使用的GUID在复制Windows的时候并不会重新生成,这时会看到存在冲突的GUID。可以在社区的这篇讨论中看到相关的内容。

也提供两篇延伸阅读的文章:the-machine-sid-duplication-myth , Do SIDs matter anymore? Do we really need Sysprep for VDI?

所以,在一个VDI架构中,除了VDI/RDS使用的虚拟机的资源池,其他的服务器强烈不建议使用除了Sysprep之外的方式进行复制,尤其是AD的域控制器——域SID搞重复了就麻烦大了……

聊到这里,我们又回到了上一篇文章那个引申的问题:VDI仅仅是PC的虚拟化吗?以我的意见,VDI带来的是Windows桌面完全不同的运营模式。如果不考虑标准化、不考虑“船新”的制备、更新、升级方法,VDI项目将会给管理员带来无法摆脱的噩梦……所以,在我看来,VDI场景下,Windows不再是需要进行管理的系统、需要更新升级的系统,而是由管理员集中控制、集中更新升级的服务——Windows as a Service。

0

精彩评论

暂无评论...
验证码 换一张
取 消