聊聊VDI虚拟桌面的重复SID问题（下）

Posted 2020-12-18

? 上一篇聊到了主流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。