上一篇聊到了主流VDI厂商官方KB告诉咱们,重复SID不是个事儿。可毕竟多年AD的经验在这,SID相同还是不大放心对吧?没问题,咱们往微软的知识库和文档文章去找找答案。
开始寻找最终答案之前,我们来聊一下曾经非常强大的一个“黑科技”工具——NewSID。上一篇咱们也说过,微软官方建议对于复制的计算机,推荐的步骤就是sysprep,关于这一点,可以通过一篇官方支持文档来确认:
The Microsoft policy for disk duplication of Windows installations
https://support.microsoft.com/en-us/help/314828/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
https://docs.microsoft.com/en-us/sysinternals/downloads/newsid
大神后来去了微软,来句题外话,Mark 现在也为Azure做了很多工作,每年我们也会参与Mark发起的Global Azure Bootcamp活动。之后不久呢,大神就停止了NewSID的更新,其原因在一篇文章中进行了描述,原因是在跟Windows研发沟通之后,认为其实不再需要分区分场景一定去做SID的更新。这篇文章发表于之前TechNet Blog站点:
NewSID Retirement and the Machine SID Duplication Myth
https://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx
很可惜,这篇文章貌似不能访问了。记忆退化的我,当年看完了现在印象也不是很深刻。所以只能通过别的方式来进行求证。用这个标题搜索的话,很容易就能发现一些相应的文章,其中一篇非常不错的:
The SID debate: To Sysprep or not to Sysprep
https://www.infoworld.com/article/2628004/the-sid-debate--to-sysprep-or-not-to-sysprep.html
我们所担心的,主要是重复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
https://docs.microsoft.com/en-us/archive/blogs/aaron_margosis/machine-sids-and-domain-sids
这篇文章对计算机SID和域SID做了较为详细的阐述,也能够帮助我们理解域内的账户,不论是计算机账号还是用户/组账号,其实都是基于域SID的,所以计算机本身的SID并不会参与到这些账户的验证过程中。
那么,是不是我们就可以忘记SID这件事情,将Sysprep置之脑后呢?当然也不是啦。
Sysprep, Machine SIDs and Other Myths
https://docs.microsoft.com/en-us/archive/blogs/deploymentguys/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
https://tech.slashdot.org/story/09/11/04/0040203/the-machine-sid-duplication-myth
Do SIDs matter anymore? Do we really need Sysprep for VDI?
https://searchenterprisedesktop.techtarget.com/opinion/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。