计算机账户SID重复的谣传

 

这篇是Mark刚写的文档，原文为 http://blogs.technet.com/markrussinovich/archive/2009/11/03/3291024.aspx

主要就是告知大家其实重复的计算机账户SID无论是在域内或者是在工作组状态下并不会造成什么问题。大家这些年来一直用到的newsid其实没什么作用的。

为了方便大家，同时也提升俺的翻译能力，对此文进行了翻译。没兴趣的人请看英文版。

---不华丽的开始线---

2009-11-03，sysinternals工具集中去除了Newsid工具。该工具可以用来修改计算机的主机SID。1997年，newsid被开发出来的时候还叫ntsid。开发的原因很简单，因为当时只有微软的syspre tool可以修改主机SID，可是它却不支持修改已经安装了应用的计算机。主机SID是在Windows安装过程中创建的唯一标示符。Windows使用它作为管理员定义的本地账户和组的SID基础。当用户登录到系统后，他们将使用账户和组的SID来进行对象授权（权限检查）。如果2个主机拥有同样的SID，那么这两个系统上的用户或组就可能拥有同样的SID。于是，我们就可以推断出下面的结论，同一网络中存在多个拥有相同主机SID的计算机是一个安全威胁，对吧？

之所以考虑隐退NewSID的原因是：尽管很多人都声称NewSID可以在Vista和windows server2008上运行成功，但Mark并没有全面的进行测试，而且有部分人声称用过NewSID后会导致部分Windows组件运行失败。所以尽管大部分人都认为肯定会出现问题，Mark重新审视这些情况后，他还是决定找找重复的SID会造成什么问题。随着深入，他越来越觉得重复的主机SID其实并不会造成任何问题。带着这个结论，他到Windows security and deployment teams询问，结果没有一个情景可以证明在域或者工作组环境中，2个拥有同样的主机SID的系统会造成什么问题。于是隐退NewSID就成为了顺水推舟的事情了。

不过对于这样的结果，大部分人肯定都很惊讶。尤其是修改镜像系统的SID是从Windows NT以来的基本准则。所以下面就来揭露真相。从主机SID的描述，揭示Windows 如何使用SID以及Windows 从来不将本机SID暴露到外部，三点来证明他的观点。

SID

Windows使用SID来表示所有的安全对象（ security principals）。安全对象包括主机，域计算机账户，用户和安全组。名字Name是用来代表SID的一个方法，可以允许用户改名儿无需更新ACL（access control list）。SID是一串数字代码包含了架构版本数字，一个48位的ID权威值，一个32位的子全位置或者RID值。权威值识别颁发出SID的代理，这个代理一般是windows 本地系统或者域。子权威值识别颁发权威的委派，RID则是Windows用来创建唯一SID用到的一个普通SID。

使用Sysinternals PsGetSid 可以查看主机SID，可下载版本1.43，mark用到的是1.44

版本号是1，权威值是5，后面接着4个子权威值。Windwos NT的设计中，主机SID可能会用来作为网络便是，所以为了保持它的独一性，安装的时候，SID会有一个固定的子权威值21和3个随机生成的子权威值。 所以通常你都会看到S-1-5-21这个固定值。

在用户创建第一个账户之前，Windows已定义了几个内置的用户和组，包括管理员和Guset账户。与生成随机sid的方法不同，windows为了确保他们的唯一性，直接在主机SID后添加了一个每账户唯一值，也称之为RID （关联ID）。初始账户的RID是预设的，比如administrator账户拥有的RID都是500.

安装完成后，Windows赋予新的本地用户和组的SID将从1000起派发.

除了这些动态创建的SID，windows还定义了一些只用固定SID的账户。比如everyone组，Local System 账户

加入域的机器还会有一个基于域SID的计算机域SID。查询域test.com的sid以及2台域内机器的sid

fulltest是手动创建的计算机账户，而test02则是一台实际的机器，来自于dc的镜像clone。大家可以注意到其实也没什么区别，加域一样成功。所以其实有问题的状态时重复的域SID。

SIDs and Access Control Lists

账户登录到Windows系统后，Local Security Authority Subsystem (LSASS -Llsass.exe)会创建一个登陆进程以及对应该进程的票据。票据是由windows内核定义的数据架构来表示账户，期内包含了账户的SID，，账户登录时所属组的SID，以及赋予该账户已经相应组的安全权限。当某个登录进程的最后一个票据删除后，LSASS就会删除该登录进程，用户就算是logoff了。

使用Sysinternals LogonSessions 直接运行就可以查看了。

以及查看登录的票据。

以及查看到相应的权限

当一个程序要打开系统对象，比如文件，注册表时，安全子系统就执行权限检查，对对象ACL中的条目与程序票据中包含的SID进行比对。

远程登录进程会有类似的检查，比如访问远程计算机的共享。为了成功的连接到一个共享，用户需要使用远端系统知晓的账户来通过远端系统的验证。也就是说，如果远端计算机是一台工作组内机器，那么用户输入的凭证就得是远端系统本地的账户，而对于域内计算机而言，凭证可以是远端系统本地的账户或者域账户。当用户访问共享上的一个文件时，远端系统上的文件服务器驱动就会使用登录进程中的票据来应对权限检查，这种方法就称之为扮演 impersonation。

重复的SID

创建一个Windows安装来对一组计算机进行部署受微软支持的方法在一台参考计算机上安装Windows然后使用sysprep工具来进行克隆前的准备。也就是常说的生成镜像。当用户启动已创建好的镜像后，Sysprep工具在安装过程会创建一个新的主机SID，去除即插即用设备的检测，重置产品激活时钟，修改其他的配置信息，比如新的计算机名。

但是，一些IT管理员装完Windows系统，安装并配置应用，使用部署工具的时候，并不会去重置那些clone系统的SID（麻烦，而且容易出错）。所以现在最佳实践就成了适应SID重置工具，比如NEWSID去重置SID。这些工具生成一个新的主机SID，找到系统上所有包含了主机SID副本的位置，包括文件系统和注册表ACL，然后更新它们到新的SID。微软不支持这种系统修改方法的原因是，这些工具并不一定完全知道Windows藏匿主机sid的所有位置。一个混合了新旧主机SID的系统的安全性和可靠性是无法得到保证的。

所以多个计算机使用同一个主机SID就是问题了么？出现这种问题的唯一办法就是Windows使用了主机SID去与其他计算机比对。比如，当用户连接到远端主机上时，本地主机SID需要传送到远端主机并在全县检查中使用，这样重复的SID就成为了一个安全问题。因为远端主机无法辨别拥有同样SID的入站远端账户和本地账户（相同的SID包括相同的主机SID和相同的RID）。可是Windows只允许用户在远端计算机上使用只有本地计算机知晓的账户信息来做验证。用户必须使用远端主机上的本地账户或者远端主机信任的域用户来做验证。远端主机从本机的SAM中获取本地账户的SID，或者从DC的ad信息中获取域账户的SID。远端计算机从来就不验证连接计算机的SID。

也就是说，SID并不是通往计算机的永恒之门，其实是账户的用户名和密码。知道一个远端计算机上的账户SID并无法去访问到远端计算机以及其上的资源。还有一些其他证据，还记得内置的账户，比如本地系统账户在所有的计算机上都拥有同样的SID，如果真如上一段的疑问所说，这早就是一个安全问题了。

不过尽管如此还是有例外的，那就是DC。每个域都有一个唯一的域SID，这个SID就是第一台域控的主机SID，而且所有的DC主机sid都和域SID相符合。

有时候，其他计算机会验证DC的主机SID。也就是说，域内计算机不可以拥有和dc以及域相同的主机SID。和所有成员计算机一样，每个DC都有一个域的计算机账户，那是他们用来被远端主机验证的ID。域内所有的额账户包括计算机，用户，安全组，所用到的SID都是基于的域SID，而本地账户的SID则是基于的主机SID，这两者并没有什么联系。

对于一些关于SID重复的文档，包括 KB article 都警告多个计算机如果使用同样的SID，可移动存储上的资源对于本地账户来说并不安全。但是他们忘记提到的一件事，移动存储上的权限毫无安全性可言。因为用户可以随意在任何计算机上插入他们，并不需要遵循NTFS权限。移动存储倾向于赋予访问权限给已知的SID，比如所有的计算机上都有相同SID的管理员组。这是物理安全的基本准则，也是Windows 7提倡是用Bitlocker-to-go的原因。Bitlocker-to-go可以加密移动存储。

最后一个问题，一个分发应用使用主机SID来识别计算机会因为SID重复出问题么？非微软软件使用主机SID来做验证是无法工作的。因为所有的DC拥有有同样的主机SID。基于唯一计算机ID的软件要不是用计算机名要不就是用计算机域SID。

新的最佳实践

于是，SID重复的问题就这样消失了。这又是一个典型的我以为你以为他以为我知道你知道我知道他知道的循环谣传。 所以NewSID从来就没有做任何有意义的事情，也必要再怀念这个工具了。微软官方针对SID重复的策略也将修改。未来Sysprep会升级并跳过SID生成的部分。注意Sysprep重置了那些如果重复可能导致问题的计算机指定状态， 比如相同SID导致的WSUS报错。所以受微软支持的策略依然会要求镜像系统需要使用Sysprep重置成唯一的。

----终于完成的插花线---

用了3个小时总算翻译完成了，虽然里面可能有一些计算机名称的错误，但是大体意思大家应该能明白了吧。还有就是大家不要仅仅局限在这个问题是否被说清了。大家要有这样的心态就是没有什么东西是永远正确的，跳出某个思维才能理解。

 

原文： http://xunyangit.spaces.live.com/blog/cns!F934535AFC3723BA!2623.entry