盆盆的博客

Hyper-V RTM正式发布

ahpeng — Fri, 27 Jun 2008 01:08:38 GMT

今天Hyper-V正式发布了！

Hyper-V是Windows Server 2008中的一个最重要的特性，服务器虚拟化是当前IT领域中最热门的话题，可以实现服务器整合、可以实现业务延续性，可以实现高可用性，可以实现服务器资源的按需交付...

好处一时间说不完，等盆盆完成手头的《Windows Group Policy Resource Kit：Windows Vista and Windows Server 2008》一书的翻译工作，将会立即抽时间撰写一些Hyper-V应用测试的文章，尽情各位期待！

对了，中文版的下载地址如下：

http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=f3ab3d4b-63c8-4424-a738-baded34d24ed

7月8日（中国时间应该是9日），Hyper-V将会发布到Web，大家届时还可以从Windows Update获取该虚拟化产品。

成都的兄弟，请保重！

ahpeng — Mon, 12 May 2008 07:39:54 GMT

惊闻成都附近发生7.8级地震，在上海，也有挺明显的震感，当时我感觉电脑椅有晃动的感觉，还以为是自己头晕……

衷心祝愿成都的兄弟姐妹们都能够平安无事，还请大家保重身体，注意安全！

微软SCVMM管理VMware ESX Server

ahpeng — Thu, 01 May 2008 15:19:00 GMT

System Center虚机管理器（简称SCVMM）的最新Beta已经公开发布，其中包含许多非常有用的功能，例如可以管理Hyper-V虚机，物理机器到虚机的在线转化（P2V迁移），虚机在线自助银行服务，和SCOM结合实现性能和资源优化等等…

然而最吸引我的还是SCVMM 2008 Beta自带的第三方虚拟架构管理集成能力，举例来说，SCVMM现在可以管理VMware ESX Server主机！

附图所示的就是SCVMM 2008 Beta的主界面，可以看到和SCVMM 2007几乎如出一辙，可以看到其中添加了VMware的主机，而且保留了Data Center、Cluster、Host的层次结构。

SCVMM可以帮助“代办”VMware的大多数功能，甚至包括大家非常喜欢的VMotion功能！而且使用起来也非常简单。只需切换到“虚拟机”视图，选中所需迁移的虚机，然后单机右侧操作面板上的“虚拟机迁移”，即可开始迁移。

在打开“迁移虚拟机向导”对话框上可以看到可以迁移的目标主机，并且用星数来表示目标主机的等级，综合性能越高，星数越高，便于我们对目标虚机进行“海选”。如果该虚机不满足迁移条件，则可以在“级别解释”窗格上显示原因，附图表明目标虚机的CPU Affinity设置有问题。

问题解决以后，重新开始迁移向导，可以看到现在虚机已经符合迁移的要求，如附图所示。

一路“Next”以后，很快就可以开始迁移进程，而且非常有意义的是，所有的步骤可以自动生成相应的PowerShell脚本，方便今后快速操作。

    在迁移的时候，如果打开VMware Virtual Center的主界面，可以看到当前正在进行迁移，而且虚机继续保持运行，如附图所示。


    在SCVMM 2008 Beta的作业窗格里，也可以看到迁移的进程，如附图所示。很快迁移就可以完成，非常方便。


    实际上，SCVMM是利用VMware Virtual Center所提供的API进行工作的，其中大部分的工作，都可以借助SCVMM来完成，相当不错。毕竟我们可以借助单一的平台，来对企业里的不同虚拟架构进行管理，非常方便。

SYSTEM帐户、登录会话和窗口站（三）

ahpeng — Sun, 20 Apr 2008 01:06:00 GMT

盆盆在写上篇文章时，就在纳闷：为什么Windbg不能转储完整的WinSta0窗口站的安全描述符？为什么会少了登录会话SID和登录帐户的对应ACE？

盆盆很快发现，原来是自己的问题。为了方便，直接用远程桌面连接到另外一台实验Windows Vista机器，这时候由于是远程桌面登录的，拿到的是会话2。但是在Windbg里检查的却是\Sessions\1\Windows\WindowStation\WinSta0。

也就是说，盆盆实际上是检查的会话1里的WinSta0窗口站，而不是远程桌面里的WinSta0窗口站（会话2）！！

难怪检查出来的结果，发现WinSta0窗口站里居然没有登录SID和Admin的对应ACE！！

1. 完整的WinSta0安全描述符

为了验证这个结果，盆盆重新做实验，这次直接控制台登录（会话1），再查看WinSta0的安全描述符，果然发现完整了，有附图为证！

图中棕色加粗的部分，就是登录会话SID和登录帐户Admin所拥有的ACE，这里可以看到登录会话SID拥有所有可能的权限，而Admin则几乎没有任何访问权限。

问题到这里并没有结束。

为什么会出现先前那篇文章里的错误？从中可以猜测到哪些结论？

2. 为什么只允许一个交互用户登录？

这里盆盆大胆假设Windows Vista（XP）为什么只能允许一个交互用户登录到系统（包括远程桌面）。原来是和WinSta0窗口站的权限有关！

当新的用户登录进来后，原来用户会话里的WinSta0的安全权限会发生变化，登录SID和登录帐户的ACE（访问控制项）会被删除。难怪我们看不到先前登录用户的桌面！

可以在远程桌面的环境里打开Process Explorer，查看一个在先前用户环境里打开的进程（例如Explorer），可以发现其句柄列表里没有WinSta0窗口站，如附图所示。

从图中可以看出，当前的用户桌面，会话2里的Explorer进程句柄表里包含WinSta0窗口站，所以可以和用户进行交互；而先前的登录用户，会话1里的Explorer进程句柄表里，没有WinSta0窗口站，所以虽然这些进程还在运行，但是无法和用户进行交互。

为什么先前的用户会话里的进程没有WinSta0的句柄，现在应该很明白了，因为该会话里的WinSta窗口站对象的ACL定义发生了变化，现在不再授予登录会话SID访问。

这一切看来和WinSta0窗口站的安全权限有关。可见，登录会话、窗口站的概念有多重要了。

知道了这个原因，从理论上，我们可以通过修改先前会话里的WinSta0窗口站的安全权限，来突破同一时刻只能允许一个用户交互登录的限制。但是实际上没有那么简单，盆盆既然能够想到，微软肯定早就已经想到了。

网上貌似有通过替换一个文件（termsrv.dll）的方法，让Windows Vista支持多个用户交互登录。如果这个方法能够成功，其原理也许还是和WinSta0窗口站的权限有关。

SYSTEM帐户、登录会话和窗口站(二)

ahpeng — Sun, 20 Apr 2008 01:04:00 GMT

上篇文章的内容隐藏了这样一个事实，为什么Local SYSTEM进程有能力加入到WinSta0窗口站？

大家可以回想一下，在Windows 2000/XP下，只有以Local SYSTEM运行的服务，可以选择“允许服务与桌面交互”。这实际上就是让该服务运行在WinSta0窗口站里，而不是运行在默认的Service-0X0-3e7$窗口站里。

但是为什么以其他帐户身份运行服务，不能选择这个选项？甚至连以当前登录帐户身份运行的服务都不行？例如当前以Admin用户帐户身份登录到系统，而系统中存在着一个服务，也以Admin身份运行。

这里我们可以查看一下WinSta0窗口站的安全权限。可以用Process Explorer，或者调试工具（例如Windbg）进行查看。

1. 用Windbg查看WinSta0的ACL

这里首先介绍用Windbg查看WinSta0窗口站的安全权限（更加完整）。由于Windows Vista默认禁用Kernel Debug，所以必须运行以下命令手动打开Kernel Debug选项：

bcdedit -debug on

盆盆评注：注意，如果安装了Demon Tools之类的工具，请不要打开Kernel Debug的选项，以免产生冲突。

下图是利用Windbg所dump出来的WinSta0安全描述符的完整记录：

我们主要关心日志中最后三个棕色加粗显示的结果：Local System帐户拥有0x000f037f权限组合；Administrators组帐户拥有0x00020166权限组合；还有一个SACL的ACE为S-1-16-4096。

0x000f037f和0x00020166，看上去甚是古怪，但搞开发的兄弟应该很容易理解，这实际上是安全权限的组合掩码。

咱IT Pro不需要理解这到底是什么意义，只需要知道0x000f037f代表拥有WinSta0的所有可能权限；而0x00020166代表拥有大多数可能的权限，但是无法读取屏幕内容。

还有一个SACL的ACE为S-1-16-4096。这又是什么意思？

嘻嘻，这里就要请大家参考MVP小青蛙s兄弟的大作《Windows Vista UIPI和窗口消息的故事》。原来在Windows Vista里，每个安全对象，包括窗口站，都有MIC等级的概念。这里可以看到WinSta0窗口站的MIC等级就是S-1-16-4096，实际上就是Low Integrity Level。当然在盆盆的多篇拙作里也曾经多次提及，例如《Windows Vista有趣的标签SID》。

WinSta0窗口站的MIC级别为什么会是低级？这可能是为了方便IE浏览器这样的Low MIC进程也能够读写WinSta0里的内容。

2. 用Process Explorer查看WinSta0的ACL

用Windbg查看WinSta0的ACL，可以得到比较丰富的信息，但是有一点小缺点，无法查看当前登录帐户的权限（相当于查看无用户登录时的WinSta0的安全权限）。

所以这里借助Process Explorer进行查看。

随便找到一个用户进程，查看其打开的句柄，可以发现其中有\Sessions\1\Windows\WindowStations\WinSta0这样的句柄，查看其安全权限。

可以看到当前登录帐户（本例是Admin）没有访问WinSta0的权限，如附图所示。

除了SYSTEM之外，还有一个古怪帐户S-1-5-5-0-148836具有所有可能的权限，如附图所示。

S-1-5-5-0-148836实际上就是Admin登录会话的SID。这样的结果非常有趣，WinSta0的权限是授予Admin的一次登录实例（登录会话），而不是Admin这个安全主体本身，很有意义。其实道理很简单，登录会话是经过LSA验证的一次登录实例，Windows可以信任。而以Admin身份运行的进程，并不一定都是由当前登录用户触发的，还有可能是以Admin身份运行的服务，从WinSta0的ACL可以看出，这些服务无法访问WinSta0，尽管它们的身份就是登录用户的帐户本身！

Process Explorer虽然可以看到完整的安全描述符信息，也可以看到更详细的权限。但是有两个小缺点，一是无法显示WinSta0的MIC级别，而是只显示所谓的常规权限，而没有显示针对窗口站的特定权限。可能Mark Russinovich还没有来得及更新，抑或这位大牛认为这太简单了，认为大家很容易理解，不想再修改了。

盆盆评注：如何理解登录会话的SID？可以用服务和服务SID的关系进行类比。

3. 小结

罗罗嗦嗦说了那么多，结论呢？

实际上很简单，查看WinSta0窗口站发现，只有System和登录会话SID拥有所有的可能权限。所以这就可以解释，为什么在Windows里，只有运行在System权限下的服务才可以选择“允许服务与桌面交互”，因为实在是只有System才有权限访问WinSta0窗口站啊！

SYSTEM帐户、登录会话和窗口站(一)

ahpeng — Sun, 20 Apr 2008 01:02:00 GMT

可能有不少读者兄弟还记得盆盆以前写过一篇文章《超级另类法用SYSTEM帐户登录系统》，描写如何以SYSTEM权限启动Windows XP中的Explorer进程，从而得以通过变相的手段以SYSTEM帐户身份登录系统。

在Windows 2000/XP下，我们可以有很多方法，以SYSTEM身份启动某个特定的进程，盆盆就曾经写过一篇《以System帐户身份运行应用程序的三种办法》。

SYSTEM帐户启动的实质

其实不管用哪种方法，其本质都一样。都是利用SYSTEM登录会话里已有的某个进程A，帮助我们创建一个子进程B，进程B会自然而然地在SYSTEM登录会话里运行--从而具有SYSTEM帐户的特权。

这里提到登录会话（Logon Session）的概念。

这个概念比较抽象，甚至连MSDN里都语焉不详。这里我们且不去管它（将会在后续的文章里给大家细述这个抽象概念）。在这里，我们只需要了解：登录会话用来代表特定安全主体（Security Principal）的一次登录实例，在Windows里，很多对象的访问权限，是基于登录会话，而非帐户本身。

盆盆注释登录会话和帐户之间的关系，有点类似于进程和程序。登录会话是一个动态的概念，有生命周期，帐户则是一个静态的概念。登录会话有自己的SID。通常来说，我们很少接触到登录会话，但是在某些特定的场合，这个概念非常重要。

每个进程，都必须运行在特定的登录会话里。

这里就有一个问题：在交互式用户登录之前，Windows系统里已经运行了一些进程（最起码是Winlogon进程），这些进程显然也应该运行在登录会话里，这就是所谓的SYSTEM登录会话，它所代表的安全主体就是SYSTEM帐户。

在Windows的安全机制里，特定登录会话里的某个进程所启动的其他进程，也会运行在该登录会话里，从而继承SYSTEM帐户的安全上下文。

《以System帐户身份运行应用程序的三种办法》这篇文章所描述的方法，都是运用这种原理。例如借助At命令以SYSTEM帐户身份启动某个任务，实际上该任务是由Task Scheduler服务启动的，而Task Scheduler服务的宿主进程svchost正是运行在SYSTEM登录会话，如附图所示。

图中所示的Task Scheduler服务的进程svchost所在的登录会话ID（Logon Session ID）是0x0-3e7，这就是代表SYSTEM登录会话。

而采用Sysinternals Suite里的Psexec命令，道理也一样，实际上启动进程的是PsexecSvc服务，该服务的进程运行在SYSTEM登录会话。

如何看到SYSTEM下的进程

在Windows 2000/XP下，这个不是什么问题。然而在Windows Vista下问题就来了。如果企图用AT命令启动某个Local SYSTEM进程，就会警告说不能和用户进行交互，哪怕加上/Interactive参数也不行！

原来在Windows Vista下，存在一个会话0隔离的问题。而AT命令所对应的Task Scheduler服务运行在会话0，而会话0是不能和用户进行交互的。

盆盆评注这里要注意，会话和登录会话，是两码事。具体的介绍，敬请期待后续的文章。

原来在会话0里，并没有WinSta0这个窗口站。天哪，又来了一个窗口站的概念，嗯，先不用管它，这里只需理解，窗口站用来保护进程的用户界面。只有WinSta0这个特殊的窗口站才可以接受用户的鼠标、键盘事件，才能和用户进行交互。

在Windows系统里，如果没有特别指定，SYSTEM登录会话里的进程，将会默认运行在Service-0X0-3E7$窗口站里，所以无法和用户进行交互。

所以很显然，要让以SYSTEM权限运行的进程，能够和用户进行交互，必须满足以下条件：

1. 必须不能运行在会话0下，例如可以运行在当前用户所在的会话下（例如会话1、2等）

2. 该SYSTEM进程必须运行在WinSta0窗口站。

而对于IT Pro来说，我们可以借助Mark Russinovich所写的Psexec工具，让任意指定的进程运行在SYSTEM权限下。

而对于Windows Vista来说，其实有好些Local SYSTEM进程本身运行在WinSta0下（非会话0），例如Winlogon进程、某个csrss进程，还有我们大家很熟悉的UAC提示对话框（consent进程），都运行在SYSTEM下，但是可以和用户进行交互。

Windows Vista安全原理深入探索

ahpeng — Sun, 20 Apr 2008 01:01:00 GMT

有不少朋友对Windows Vista的UAC功能不满意，所以特将以前给《程序员》杂志写过的一篇文章贴到这里，意图介绍一下Windows Vista这个安全功能的底层原理，也希望读者朋友能够理解Windows安全设计人员的苦心。

如果看过Mark Russinovich的博客，那么就会明白，UAC的主旨并不是要替代杀毒软件等工具，并不是为了消除病毒、木马等恶意软件，UAC是安全纵深防御体系中的一环，其主要设计目的是尽可能让应用程序运行在标准用户权限下，以减少所有应用程序（不管是合法软件，还是恶意软件）有意或者无意，对系统造成的危害。

盆盆评注笔者在探索和学习Windows Vista安全理论的过程，深受《Windows Internals》一书的启发。该书由Mark Russinovich和David Solomon所著，堪称IT Pro和Dev的圣经。

参考

用户帐户控制（UAC），是Windows Vista新引入的安全机制。管理员登录Windows时，系统会同时创建两个访问令牌，其中一个是完全的管理员访问令牌（Full Token），另一个是经过“过滤”的访问令牌，叫做标准用户访问令牌，如附图所示。当Windows系统启动Shell进程（Explorer.exe）时，LSA会把标准用户访问令牌连接到Shell进程，所以Windows Vista启动的用户进程，默认都只具有标准用户权限。如果某个进程需要管理员权限，则系统会提示权限提升，得到用户亲自确认后，系统会把完全的管理员访问令牌连接到该进程上。
单击看大图

准备知识

在《Windows Internals》的第八章“安全”部分，介绍了一个实例：当我们在Windows XP里启动“日期和时间”控制面板组件时，实际上启动的是“rundll32”进程，由该进程加载“Timedate.cpl”控制面板组件。用Process Explorer检查该“rundll32”进程的访问令牌，可以发现“SeSystemTimePrivilege”特权处于启用状态，如附图所示。
单击看大图

“SeSystemTimePrivilege”是“更改系统时间”特权的内部名称，所有特权都保存在LSA的策略数据库中，该数据库会加载到HKLM\SECURITY注册表分支，用户登录系统时，LSA会读取这些特权值。

对于Windows XP专业版，我们可以通过“本地安全策略”管理单元查看用户所具有的特权。可以看到，“更改系统时间”特权仅授予管理员组和Power Users组用户，如附图所示，这就是为什么在Windows XP下，标准用户无法修改系统时间和时区的原因。
单击看大图

盆盆评注笔者曾经写过一个连载，介绍帐户的登录权利所对应的HKLM\SECURITY注册表键值。可以用同样方法得出特权所对应的注册表键值。

实验准备

现在我们已经知道，要修改系统时间，当前帐户必须具备“更改系统时间”特权。但是在Windows Vista下，默认不是只有标准用户权限吗，这时候应该没有“更改系统时间”特权！那么系统是如何获得“更改系统时间”特权的呢？我们用实验来进行验证。

1. 实验工具

本实验在Windows Vista中文旗舰版上进行，测试帐户为Admin，是管理员组成员。为了查看进程的访问令牌，需要采用先前提到的Process Explorer工具，下载地址如下：

http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx

还有一个Process Monitor工具，下载地址如下：

http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx

2. 禁用安全桌面

由于“用户帐户控制”对话框默认运行在“安全桌面”上，这里的安全桌面就是我们按“Ctrl+Alt+Del”组合键所进入的桌面。但是为了改善用户体验，UAC的安全桌面并不是蓝绿色的背景，而是当前用户桌面桌面背景的截图快照（呈暗色显示）。

盆盆评注参考盆盆翻译自Mark Russinovich的文章，了解如何强制用户必须按“Ctrl+Alt+Del”组合键，才能打开UAC的凭据输入对话框，这样可以确保凭据的安全。

之所以启用“安全桌面”，主要是因为考虑到安全因素，以防其他进程可以对“用户帐户控制”对话框进行操作。但是由于本实验需要用工具对UAC的过程进行全程监控，所以需要临时禁用“安全桌面”功能，方法如下。

运行“secpol.msc”并回车，打开“本地安全策略”对话框，然后在左侧的控制台树里定位到本地策略→安全选项，在右侧详细窗格里双击“用户帐户控制：提示提升时切换到安全桌面”策略项，并选中“已禁用”选项，如附图所示。
单击看大图

实验记录

1．查看rundll32进程访问令牌

单击任务栏通知区域的时钟图标，然后单击底部的“更改日期和时间设置”链接，即可打开“日期和时间”窗口。正如您所预料的，这时候还不能对系统时间进行任何修改。同时可以在Process Explorer窗口中看到新增一个进程rundll32（呈绿色显示）。

双击该rundll32进程，即可打开其属性对话框。在“Image”标签页的“Command Line”文本框里可以看到“timedate.cpl”（“时间和日期”的控制面板扩展文件），如附图所示。这说明该rundll32.exe就是“时间和日期”控制面板组件的宿主进程。
单击看大图

切换到“Security”标签页里，就可以看到该rundll32进程的访问令牌，可以看到在下方的特权列表里，只有少得可怜的五个个特权，而其中并没有SeSystemTimePrivilege特权！这就是为什么在默认情况下，无法在管理员环境下修改系统时间的原因。
单击看大图

2．提升权限

要能够修改系统时间，只需单击“日期和时间”窗口右下侧的“更改日期和时间”按钮，即可打开 “用户帐户控制”对话框，单击“继续”按钮，如附图所示。现在应该可以修改系统时间了。
单击看大图

看来这个“用户帐户控制”对话框负责向系统传递消息，以便系统确认用户同意提升操作权限。其本质似乎应该是修改相关进程的访问令牌，就本例来说，应该是在rundll32进程的访问令牌里添加SeSystemTimePrivilege特权。那么果真是这样吗？

结果很让人沮丧，重新打开rundll32进程的属性对话框，并切换到“Security”标签页，发现其访问令牌没有任何改变（并没有新增SeSystemTimePrivilege特权）！

这是为什么呢？

3．查看dllhost进程的访问令牌

反复重新做实验后，终于发现在“用户帐户控制”对话框上单击“继续”按钮后，系统会新增一个dllhost进程，在其进程属性对话框的“Image”标签页的“Command Line”文本框里可以看到“/Processid: {9DF523B0-A6C0-4EA9-B5F1-F4565C3AC8B8}”参数，如附图所示。
单击看大图

搜索注册表得知，{9DF523B0-A6C0-4EA9-B5F1-F4565C3AC8B8}就是timedate.cpl的AppID，如附图所示。
单击看大图

在dllhost进程的属性对话框上，切换到“Security”标签页，不出所料，dllhost进程的访问令牌里果然有SeSystemTimePrivilege特权，而且是启用状态，如附图所示。
单击看大图

现在真相大白了，原来Windows Vista表面上让rundll32进程“明修栈道”，背地里却让dllhost进程“暗渡陈仓”，把完全的管理员令牌赋予该dllhost进程，真正让我们可以修改系统时间的是dllhost进程！

4．系统背后的动作

为了更好地对系统背后的动作进行监测，我们再启动Process Monitor，然后再重复上述的操作。

结果在Process Monitor里监测发现，单击“日期和时间”窗口右下侧的“更改日期和时间”按钮，发现由svchost进程（进程ID为1924）启动consent.exe进程，这个consent.exe进程就是“用户帐户控制”对话框，如附图所示。
单击看大图

盆盆评注在Windows Vista下，应该用Process Monitor代替Filemon和Regmon，Process Monitor除了可以监控注册表和文件活动外，还可以监控进程的活动，包括其堆栈信息。

双击这条记录，在打开的属性对话框上切换到“stack”标签页。在其堆栈信息中发现一个“appinfo.dll”模块，其描述为“应用程序信息服务”，如附图所示。原来这就是Windows Vista系统的“Application Information”服务，当系统确认进程需要管理员权限时，就会由“Application Information”服务负责启动consent进程，以便打开“用户帐户控制”对话框。
单击看大图

在Process Explorer中打开consent进程的属性对话框，在“Image”标签页也可以发现consent的父进程的进程ID为“1924”（svchost进程），如附图所示。

单击看大图

打开进程ID为1924的svchost进程的属性对话框，并切换到“Services”标签页，可以看到其下有“Application Information”服务，该服务以“appinfo.dll”的形式运行在svchost进程中，如附图所示。
单击看大图

在“用户帐户控制”对话框上单击“继续”按钮后，系统获得来自用户的确认信息，接下来我们可以通过Process Monitor监测到由另一个svchost进程（进程ID为1376）加载dllhost的进程映像文件，如附图所示。
单击看大图

双击这条记录，在打开的属性对话框上切换到“stack”标签页，在堆栈信息中发现一个“rpcss.dll”模块，其描述为“分布式COM服务”，如附图所示。原来这就是Windows Vista系统的“DCOM Server Process Launcher”服务，由该服务负责启动dllhost进程。
单击看大图

在Process Explorer中双击打开进程ID为1376的svchost进程的属性对话框，并切换到“Services”标签页，可以看到其下有“DCOM Server Process Launcher”服务，该服务以“rpcss.dll”的形式运行在svchost进程中，如附图所示。
单击看大图

盆盆评注 “Remote Procedure Call (RPC)”服务也是以“rpcss.dll”的形式运行在另外一个svchost进程中。但是两个并没有服务共享同一个svchost进程，这是因为这两个服务的启动帐户不同。“Remote Procedure Call (RPC)”服务的启动帐户是NETWORK SERVICE，而“DCOM Server Process Launcher”服务的启动帐户是SYSTEM。

接下来在Process Monitor中，我们可以看到dllhost进程检查HKCR\AppID\{9DF523B0-A6C0-4EA9-B5F1-F4565C3AC8B8}注册表键值，如附图所示。以便知道应该加载“Timedate.cpl”注册表组件，并最终允许修改系统时间。

单击看大图

5．比较前后访问令牌的SID列表

仔细观察前后两个进程（rundll32进程和dllhost进程）访问令牌中的SID列表，如附图所示，会发现有以下两个显著的不同。
单击看大图

（1） rundll32进程：Administrators组SID被标记为Deny，这表明该进程实际上不属于管理员组。同时访问令牌里只有五个特权，其中并没有“SeSystemTimePrivilege”特权。

访问令牌里包含一个名为“Mandatory Label\Medium Mandatory Level”的标签SID。

（2）dllhost进程：Administrators组SID被标记为Owner，这表明该进程属于管理员组。同时访问令牌里包含“SeSystemTimePrivilege”特权。

访问令牌里包含一个名为“Mandatory Label\High Mandatory Level” 的标签SID。

6．修改系统时区

大家知道，在Windows XP下，我们无法在标准用户下修改系统时区。但是在Windows Vista却可以，无需提升权限，不知道读者朋友有没有考虑过这个问题。

原来这是因为Windows Vista的标准用户多了一个“SeTimeZonePrivilege”（更改时区）特权，所以无需提升权限，就可以修改系统的时区，这给标准用户带来方便。

进一步研究发现，在打开“日期和时间”对话框时，其宿主进程rundll32的访问令牌中，虽然有“SeTimeZonePrivilege”，但是其状态为“Disabled”（如上图所示）。

而只有在单击“更改时区”按钮时，rundll32进程的“SeTimeZonePrivilege”特权才会被激活，如附图所示。
单击看大图

实验结论

1．UAC的实质

当管理员登录时，Explorer进程会获得一个“缩水”的访问令牌，也叫标准用户（Standard User）访问令牌。由于用户进程大多数都是由Explorer启动，所以这些进程会自动继承这份“缩水”的访问令牌（如本例的rundll32进程）。

凭借缩水的访问令牌，用户可以完成绝大多数工作，同时由于用户权限被大大缩小，这样用户进程就不会有意无意破坏系统的完整性，这样就可以大大减少受攻击面。

如果需要执行管理任务，系统会提醒用户进行确认，一旦认可，将会获得完全版本的管理员访问令牌（如本例的dllhost进程）。

用户帐户控制好比给Windows Vista穿上一件铁布衫，有了它的庇护，Windows系统不再奉行“不抵抗”政策，恶意网页胆敢再来“骚扰”，将被毫不犹豫地阻止。同时最终用户不再需要接受额外的培训，一切都由系统自动完成，只需要做出选择即可，您就没事偷着乐吧！

2．标签SID

至于前后两个进程的访问令牌中新出现的标签SID，其中一个是“Mandatory Label\Medium Mandatory Level”，另一个是“Mandatory Label\High Mandatory Level”。这两个帐户，既不能用来登录，似乎也不能用来设置安全权限，那么到底派什么用场呢？

原来这是用来标记访问令牌，这样系统看到访问令牌中包含“Mandatory Label\Medium Mandatory Level”的标签SID，马上就可以知道该令牌属于标准用户访问令牌；同样如果令牌中包含“Mandatory Label\High Mandatory Level”的标签SID，马上就知道其属于完全的管理员访问令牌。

那么，为什么不在访问令牌中新增一个标志位？例如等于0时就是标准用户令牌，等于1时就是完全权限令牌？这样的话，就不需要新增标签SID了。也许是为了兼容性，毕竟增加一个标志位，就等于要修改访问令牌的数据结构，这可不是一个好主意，而添加几个SID，则相对简单得多。

标签SID的作用很大，当进程需要管理员权限时，系统会根据其父进程的标签SID，来判定是否需要弹出“用户帐户控制”对话框。如果其父进程的标签SID是“Mandatory Label\Medium Mandatory Level”，系统就会弹出“用户帐户控制”对话框。如果父进程的标签SID是“Mandatory Label\High Mandatory Level”，就不会弹出“用户帐户控制”对话框，而是直接运行该目标进程。

由于绝大多数用户进程的父进程是Explorer，所以会弹出“用户帐户控制”对话框。

除此之外， Windows安全子系统还用标签SID来帮助判断一个进程是否可以访问特定的资源对象，是否可以访问某个特定的进程。

盆盆评注有关标签SID的详细作用，可以参考盆盆发表在ITECN博客上的文章《Windows Vista有趣的标签SID》：http://blogs.itecn.net/blogs/ahpeng/archive/2007/02/27/labelsid.aspx

[翻译]Hyper-V和多处理器虚机

ahpeng — Sun, 20 Apr 2008 00:58:00 GMT

作者：John Sheu

http://blogs.technet.com/winserverperformance/archive/2008/02/29/hyper-v-and-multiprocessor-vms.aspx

译者：盆盆

欢迎访问我们的博客！笔者是Windows Server Performance团队的开发主管，在过去的三年半里，笔者负责带领团队改进Windows Server 2008 Hyper-V的性能。

在Hyper-V的整个开发周期里，我们和产品组一起协作，以便能够推出有竞争力的产品，很高兴Hyper-V能够在今年正式发布，本周发布的Windows Server 2008正式版本里已经包含了Hyper-V Beta版本[盆盆注：Hyper-V RC0也已经在3月19日正式发布]。

架构概述

Hyper-V采用基于Hyperisor的架构，并且充分利用Windows驱动模型，以便提供广泛的硬件支持。Hypervisor可以把单个服务器划分为多个CPU和内存的容器。由于采用微内核架构，Hyper-V可以提供高效的分区间通信机制，并在此基础上搭建高性能的虚拟I/O架构。根分区包含物理I/O设备，还将提供虚拟栈用来为子分区所实现的I/O服务。

虚拟栈可以实现模拟I/O设备，例如IDE控制器和DEC 21140A网卡。然而模拟这种设备的代价很昂贵。发送单个I/O请求，就有可能导致虚拟栈和子分区之间的多次切换。相反，Hyper-V提供专门为虚机环境所设计的虚拟I/O设备。这些虚拟设备连接到VMBus，这是一个支持即插即用的总线，使用共享内存，以便可以有效地进行分区间通信。Windows虚机可以自动检测到VMBus上的虚拟设备，并且加载合适的驱动程序。

Hyper-V中的虚拟输入/输出采用客户端/服务器架构，在根分区中包含VSP（虚拟服务提供程序），在子分区中包含VSC（虚拟服务客户端）。该架构极大地减少发送I/O请求所需的开销。如果Virtual Server用户把虚机迁移到Hyper-V中，他们将体会到高I/O的工作负载的CPU开销大大降低。

多处理器的虚机

在这第一篇文章里，笔者想着重指出Hyper-V的主要性能特性：多处理器的虚机。Hyper-V支持4 CPU的Windows Server 2008虚机，和2 CPU的Windows Server 2003虚机。如果服务器工作负载需要很高的性能，我们可以考虑用2 CPU或者4 CPU的Hyper-V虚机对其进行虚拟化。当然，只有当工作负载确实需要的时候，才应该使用多处理器虚机，因为拥有更多的处理器会带来一些额外的开销。

然而，操作系统内核和驱动会采用自旋锁（Spin Lock）的机制，在获得自旋锁之前，（线程）并不会阻塞，并一直处于自旋状态，前提是自旋锁只会保持很短的时间。但是虚拟化会打破这种条件，因为虚拟处理器是按时间片进行调度的。如果在保持自旋锁的时候竞争虚拟处理器，则其他虚拟处理器就要自旋很长时间，导致CPU循环的浪费。[盆盆注：自旋锁是多处理器操作系统的一种互斥机制，有点类似于互斥锁，但是保持时间更短。更详细信息，可以参考《Windows Internals》第四版的P152]

我们在Hypervisor和Windows Server 2008内核里加入创新设计，尽可能防止出现自旋锁的长时间等待条件，如果确实存在长时间等待条件，也会有效地加以检测并对其进行处理。我们还对Hypervisor进行设计，包括调度程序和内存虚拟化逻辑，以使它们在大多数临界区中都不会锁定，从而确保多处理器系统能够获得很好的延展性。

所以，4 CPU的Windows Server 2008虚机，其延展性可以和物理4 CPU系统一较高下。这是一个很好的注解，来诠释Windows Server 2008虚机和Hyper-V如何一起提供性能上的改进。我们还将在后续的版本里继续提高多处理器系统和多处理器虚机的延展性。

Hyper-V高可用性群集实测报告

ahpeng — Sun, 20 Apr 2008 00:57:00 GMT

早就听说Hyper-V Beta可以支持快速迁移和高可用性，最近抽空测试了一下Hyper-V的主机群集（Host Clustering）功能，结果相当理想，甚至超出了盆盆的预期。所以赶紧写一个文档，分享给广大的微软技术爱好者，也算是盆盆赠送给ITECN粉丝的新年礼物*^_^*。

一、商业价值和技术原理

群集的意义何在？这就要从虚拟化的应用场景来说起。Hyper-V属于服务器虚拟化技术，这和我们熟悉的Virtual Server是同一类型的，而服务器整合则是其主要的应用场景之一。服务器整合可以极大地提升服务器的利用率（从原本的10~20%提升到60~70%）、可以很好地节省服务器采购的费用、可以大大节省电费和降温费用（每台服务器每年的电费和降温费用，超过服务器投资的1/3），更重要的是，服务器整合还可以大大提高服务响应的速度。

然而服务器整合也会带来一个潜在的问题。

在传统IT架构中，为了安全和稳定性，物理服务器通常是专机专用，也就是说，一台物理计算机只安装一个关键业务程序。一旦物理硬件损坏，只会影响到该服务器上的关键业务。而采用服务器整合的虚拟化技术后，物理主机上可能同时运行多台虚机（每台虚机里跑一个关键业务程序），多个虚机之间可以实现安全隔离，如附图所示。这好比把所有的鸡蛋放在一个篮子里，一旦物理主机硬件损坏，其上的多台虚机，及其中运行的关键业务都会同时中断。

而Hyper-V则支持高可用性群集功能，不管是有计划的主机维护、还是突发的硬件故障，虚机都可以在另外一台主机上快速重启，而且服务中断的时间很短，几乎可以忽略不计。盆盆自己做了总结，Hyper-V主机群集有以下一些显著特点：

1. 内置支持Hyper-V虚机

Windows Server 2008群集，现在已经内置支持Hyper-V虚机，可以把虚机作为Windows Server 2008群集中的可用服务。

2. 支持多节点

到目前为止（Hyper-V Beta），可以最多支持16个节点的遇故障转移群集（Failover Clustering）！我们既可以手动指定虚机迁移的目标主机，而当意外故障发生时，系统会自动寻找具备充足内存的目标主机，默认是下一个主机。

3. 操作步骤简单

Hyper-V基于Windows Server 2008群集功能，相对于Windows Server 2003，其设置的步骤非常简单，甚至是不熟悉原理的用户，也能轻松实现。

4. 极大减少停机时间

服务器停机有两种情况：计划维护和意外故障。根据VMware公司的统计，计划维护停机的时间约占日常停机事件的80~90%，例如我们要对服务器进行升级、打补丁或者进行其他维护。意外故障，例如硬件的突发故障，断电等等。

针对80~90%的计划维护停机，Hyper-V可以进行快速迁移（Quick Migration）。虚机的磁盘文件（.VHD）存放在共享存储设备（iSCSI或者光纤SCSI设备）上，同时挂载到多台主机上，所以快速迁移时，不需要迁移庞大的磁盘文件，如附图所示。

如果需要对主机Node1进行维护，只需把其上的虚机保存状态（save state），也就是把当前虚机内存里的内容保存到文件里，保存状态所产生的文件也保存在共享存储上，然后该虚机就可以在另外一台主机Node2上恢复。

由此可见，快速迁移所需的时间和以下两大因素有关：

（1）共享存储的带宽

（2）虚机内存的容量

例如对于一台1GB内存的虚机，如果共享存储是带宽为1Gb（125MB）的iSCSI，只需约16秒的停机时间（1Gb/8≈125MB，1GB/125MB=8秒，8×2=16秒）；如果是4Gb的光纤存储，则只需约4秒！不同虚机内存和存储带宽所对应的停机时间，如附图所示。

如果是突发性的硬件故障或者断电，则可以借助高可用性群集功能，该虚机可以在另外一个节点上重新启动。这时候相对快速迁移而言，虚机里的关键业务需要更长的停机时间。

5. 支持跨区域故障转移

Hyper-V还支持所谓的stretch clustering（延伸群集），也就是跨越地理位置的故障转移群集功能，一旦某个站点发生故障，其他地方的另外一个站点可以立刻恢复工作！

6. 和System Center的完美集成

Hyper-V不仅可以实现高可用性，还可以实现负载平衡。这可以和System Center进行完美整合。例如企业通过两台虚机提供订单服务（负载平衡），当三月份业务繁忙时，System Center Operation Manager监测到两台虚机的性能开始不堪重负，则可以很方便地借助System Center Virtual Machine Manager根据模板创建一个新的虚机加入到这个NLB群集，继续提供服务，整个过程几乎不需要人工干预，而且非常有效。

二、Hyper-V/VMware/Xen，孰优孰劣？

说老实话，作为虚拟化市场的先驱，VMware的技术无疑更加成熟。VMware采用一种所谓的VMotion技术。VMotion采用内存后台备份的机制，可以实现在线迁移，也就是说，几乎没有停机时间。

VMotion也需要共享存储的支持，虚机的磁盘文件保存在共享存储设备上，但是需要指出的是，VMotion并不是基于群集的。

1. VMotion的原理

假设虚机要从主机A迁移到主机B上。VMotion的过程简述如下：

（1）VMotion首先尝试把虚机的内存映像从主机A拷贝到主机B。在这个过程中，主机A上的虚机继续对外提供服务。

（2）在内存映像拷贝过程中。用户对该虚机的任何内存写入操作，都会记录到一张叫做内存位图（Memory Bitmap）的表中。

（3）内存映像拷贝完成后，会把内存位图表拷贝到主机B上。这段时间虚机会暂时停止工作（时间极短，如果尝试Ping的话，通常只有一个数据包显示超时），如附图所示。

（4）当虚机在主机B上启动时，系统会把内存位图表里记录的已修改页（Modified Memory Page）继续拷贝到主机B中，直到结束。

2. VMware VMotion和Hyper-V快速迁移之间的对比

（1）由于VMotion采用后台内存拷贝的模式，只有在拷贝内存位图表时，才会临时中止客户端访问，用户几乎感觉不到服务中断（一般最多1~2秒）

而Hyper-V快速迁移则需要有一个内存状态的保存和恢复时间，根据虚机内存和存储带宽的大小，有少量的服务中断时间（少则1~2秒，多则1~2分钟）。

从原理上讲，Hyper-V采用的是比较简单的内存状态保存的技术，以避免在内存映像传输时，后续的内存写入同步问题，以增加停机时间作为代价，但一般来说这点时间还是可以容忍的，通常不会有损SLA。

（2）VMotion需要相对比较昂贵的费用（必须采购更高版本才能获得）

而Hyper-V快速迁移则包含在Windows Server 2008的授权费用中，不需要额外付费。

（3）VMotion需要两台主机的CPU为同一系列（最好是同一型号），以避免CPU指令集的不同而导致的指令兼容问题。

Hyper-V快速迁移当然不需要这个限制。

（4）VMotion适用于计划维护停机事件，如果是突发故障，可以借助VMware的HA功能（需要付费），让虚机在另外一台主机上重启。

而Hyper-V则可以借助主机群集功能同时实现快速转移和高可用性。

（5）VMotion是VMware Infrastructure的核心功能之一，它也是DRS（动态资源调度）的基础。系统可以根据一定的优先级和性能监控，自动通过VMotion在不同主机之间在线迁移虚机，以便平衡数据中心的可用资源。

相信今后的Hyper-V的正式版本，也有类似的机制，例如可以借助System Center Operation Manager自动监控虚机和物理主机的性能，然后借助System Center Virtual Machine Manager进行快速迁移。

那么Xen呢，Citrix的XenServer Enterprise可以实现类似的XenMotion功能，盆盆没有测试过，估计类似于VMware的功能。今后盆盆会抽空进行测试，并给出相应的测试报告。

三、实验环境简述

至少需要两台物理计算机（必须满足Hyper-V的安装条件），用来安装Windows Server 2008（Hyper-V），并加入到域。两个独立的网段，一个作为心跳网络（Heartbeat Network），还一个连接生产环境。如果有iSCSI共享存储设备，还需要有一个网段专门连接到该存储网络。

盆盆当然不可能购置iSCSI/FC共享存储设备，所以需要准备一台专门的虚机，借助IET或者Openfiler（基于Linux）、WinTarget（基于Windows）等工具虚拟出iSCSI共享存储设备。只是性能和真实的iSCSI设备相比，自然不可同日而语，而且也远不如普通的IDE/SATA硬盘（毕竟是用虚拟磁盘来模拟的）。不过我们这里只是一个实验，看看效果就行了。

所以盆盆这里有三台物理计算机，其中一台计算机安装虚机（可以是Virtual Server、Hyper-V或者VMware等虚机），并把该虚机提升为域控制器；另外两台安装Hyper-V，并加入到该域中，实验环境的网络拓扑结构如附图所示。

这里不再描述如何借助WinTarget或者IET、Openfiler搭建虚拟iSCSI共享存储设备，大家可以参考帮助文档。

四、配置Hyper-V高可用性

在Windows Server 2008配置Hyper-V高可用性非常方便，只需分为三步走：配置验证、创建群集、设置高可用性。

1. 配置验证

在Hyper-V主机上添加“Failover Cluster”角色，然后打开“Failover Cluster Management”管理单元，如附图所示，并单击右侧操作窗格里的“Validate a Configuration”。

接下来指定需要添加到群集里的两个节点（Hyper-V主机），然后可以选择“Run only tests I Select”选项，并在接下来的页面里指定所需验证的选项，这里可以略过共享磁盘的相关验证（虚拟出来的设备，很难通过验证，但是不影响实验结果）。

然后可以开始验证过程，并检查验证结果，如果有问题，则需要退回重新检查。

2. 创建群集

在“Failover Cluster Management”管理单元窗口里单击“Create a Cluster”，然后添加所需加入的Hyper-V主机节点。

然后指定群集的访问IP地址和群集名字，如附图所示。

接下来确认群集设置，即可开始创建群集，最后在群集创建成功页面上单击“Finish”按钮即可，如附图所示。

3. 设置高可用性

接下来就可以把某个Hyper-V虚机作为Windows Server 2008群集所管理的服务。这里我们首先需要打开Hyper-V管理单元，新建或者复制一个虚机，请注意必须把该虚机的磁盘文件保存在共享磁盘上。

确保关闭该虚机，然后在“Failover Cluster Management”管理单元上单击“Configure a Service or Application”，然后在“Select a Service or Application”页面确保选择“Virtual Machine”选项，如附图所示。

然后选中刚才所新建的虚机（本例是Hyper-VCluster），如附图所示。

确认无误后，即可开始配置该虚机的高可用性，最后在结果页面上单击“Finish”按钮，如附图所示。

五、测试Hyper-V快速迁移

一切就绪后，就可以开始测试Hyper-V的快速迁移功能了。很简单，只需启动该Hyper-V虚机，然后在“Failover Cluster Management”管理单元左侧控制台树里定位到“Services and Applications”分支，可以看到该虚机当前处于“Online”的状态。

鼠标右键单击该虚机，并在快捷菜单里单击“Move this service or application to another node”，并选择另外一台Hyper-V主机，如附图所示。

然后在“Failover Cluster Management”管理单元左侧控制台树里定位到“Services and Applications”分支下方的测试虚机，即可在中间的详细窗格里看到该虚机的当前所在的主机是Node1（本例是TOPHOME主机），并且可以看到该虚机正在保存状态，如附图所示。

一旦保存状态完毕后，即可看到该虚机已经切换到另外一台主机（本例是MarkThink），并且可以看到该虚机正在从保存状态中恢复，如附图所示。

整个迁移过程速度非常快，盆盆给这台虚机配置512MB内存，虽然是在模拟的共享存储上进行配置，但是迁移的速度很快，差不多20秒左右即可迁移完毕，这个速度还是完全可以承受的。