由于Windows Vista默认启用UAC功能，CMD Shell以Standard User的身份启动，我们无法采用sc命令对beep服务进行配置(会收到Access is Denied的错误消息)。
这时候必须右键单击开始菜单上的“Command Prompt”，选择“Run as administrator”，以Highest Privilege运行CMD Shell，这样SC命令才能拿到足够特权完成相应的管理工作。如下图所示，淡青底色的CMD Shell以Standard User身份运行(结果SC命令运行失败)，而红底色的CMD Shell则以Highest Privilege运行(结果SC命令运行成功)。
否则在Windows XP一样可以让用户进程运行在Standard User环境(可以参考笔者的《IE浏览器，我想你安全、再安全些》)，但是这充其量只能算是LUA(最小帐户特权)，而不够格称为UAC(用户帐户控制)！
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
显然上述的注册表修改法并不是解决问题的良药，实际上这只是强行把“皮球”踢给Explorer Shell(GUI)罢了，执行的结果也并不理想，更何况数百个命令行工具，逐个修改的话，简直是一场噩梦！
同样是系统内置的组件，例如regedit、mmc等GUI组件，其兼容性设置也被锁死，但是为什么系统会主动询问是否提升权限？难道命令行工具是后妈养的，Windows Vista有意给它穿小鞋？
唯一遗憾的是，只能由Microsoft自己对SC.exe的manifest信息进行修改，如果企图借助Winhex等工具直接修改SC.exe中的Manifest信息(例如试图将其RunLevel修改为"highestAvailable")，结果就会闹和笔者一样的笑话，收到“side by side”的出错消息──都是不懂开发给整的～
从Build 5308开始，Windows Vista会自动检查程序代码中的数字签名，并且在consent对话框里提供相应的警告信息。如果试图运行一个没有合法签名的程序，Windows Vista会警告说该程序没有合法的“身份证”，若要运行，后果自负。
(2) 以“Run as administrator”方式打开一个CMD Shell，这时候CMD进程的Mandatory Label SID为“High Mandatory Level”，在其下可以打开regedit，而无需确认。
(3) 按下ctrl+alt+del组合键，在Winlogon Desktop上单击“Start Task Manager”按钮，即可弹出如下图所示的窗口，实际上就是一个taskmgr.exe进程，其Mandatory Label SID为“Medium Mandatory Level”，这里在Process Explorer里记下其PID(假设为2272)：
在该窗口上单击“All programs on this computer”按钮，即可弹出一个consent对话框要求确认权限的提升。确认后即可弹出任务管理器，这时候原来的taskmgr进程(PID为2272)就会被自动杀死，现在我们在Process Explorer里打开新启动的taskmgr进程的属性对话框，可以看到其父进程就是那个已经被杀死的PID为2272的进程！如下图所示。难怪需要确认是否提升权限。
当我们尝试启动某个标记为需要高特权的进程时，Windows Vista会检查其“父进程”的访问令牌，并根据访问令牌里的Mandatory Label SID进行相应的判断：
这里需要注意的是，在Build 5231的Windows Vista版本里，如果按下“ctrl+alt+del”组合键，会直接弹出一个拥有完全权限的任务管理器，因为这时候任务管理器的
之所以没有给命令行添加所谓的UAC功能，猜想Microsoft考虑到使用命令行的用户大多是IT Pro，在命令行中屏蔽UAC功能，可以有效防止最终用户无意之中运行高危险的命令，例如format、BCDEDIT等，从而避免对系统的毁灭性打击。
原文摘自
ITECN Blog，作者：盆盆<Microsoft MVP>
原文地址:
点击查看ITECN Blog是由近40位微软MVP和MCT、还有微软员工组成，旨在宣传微软IT Pro技术
难度 Level300
简介 本文详细介绍了UAC的应用程序标识、安全桌面和虚拟重定向等底层原理，并给出不能禁用UAC的若干理由。更重要的是，本文还将就用户广为关心的文件操作问题提出比较巧妙的解决方案(既能解决文件操作的麻烦，又能保留UAC的安全性)；同时本文还为讨厌UAC功能的朋友提供了两个妥协折衷的方法，可以临时摆脱UAC功能的“唠叨”，而不需要因噎废食、禁用UAC功能。
我们现在已经知道，在Windows Vista中，使用管理员帐户登录系统，当Winlogon进程收集帐户凭据并交由LSA验证后。LSA会查看该帐户的访问令牌，如果发现里面包含某些高级特权(例如“修改系统时间”)或者高级SID(例如管理员组SID)，就会自动创建两个访问令牌，一个是
管理员访问令牌(Full Token)，另一个是
标准用户访问令牌(UAC Token)。
由Winlogon启动的初始化进程userinit链接到
标准用户访问令牌，所以由userninit进程启动的Explorer进程也链接到
标准用户访问令牌。同样由Explorer启动的用户进程也会自动链接到
标准用户访问令牌，由此大大减少受攻击面，极大地提升系统安全性。
如果某个进程需要以更高权限运行，则系统会弹出一个权限提升对话框，确认后即可以更高权限运行该进程，该进程链接到
管理员访问令牌。
提示 要了解有关UAC进程创建的流程，可以参考MVP Smallfrog的
《Windows Vista UAC 模式下的进程创建实战的故事》。
五种标识权限提升的方法Windows Vista并没有一种与生俱来的魔力，可以未卜先知某个应用程序是否应该运行在更高安全级别上。应用程序必须自己想办法通知Windows Vista它需要更高权限。有以下五种方法，让Windows Vista明白该应用程序需要提升权限：
(1) Windows Vista可以智能识别安装程序，例如根据安装程序的文件名(包含install或者setup)，还可以智能识别msi发布的安装包等等。可以做一个实验，如果修改其他某个应用程序的名字，例如将QQ.exe重命名为QQInstall.exe，运行它就会自动触发权限提升，原来UAC以为这是一个安装程序。
(2) 在可执行文件的属性对话框、兼容性标签页里勾选“以管理员身份启动该程序”复选框。这等效于在HKCU \Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers注册表分支下添加键值，也相当于修改C:\Windows\AppPatch下的sysmain.sdb兼容性数据库。
(3) 在程序的manifest文件或者内嵌的manifest信息里加入“level=highestAvaible”或者“level requireAdministrator”安全级别。
(4) 鼠标右键单击应用程序，选择“用管理员帐户运行”菜单项。
(5) 利用ACT(应用程序兼容性工具)为特定应用程序创建兼容性数据库，以便IT部门可以方便地在企业里部署兼容性设置。
提示 其中(2)和(3)可以参考笔者的
《Windows Vista UAC安全功能深入剖析系列之二》。
毁誉参半的安全桌面大概是从5365 Build起，当系统弹出“用户帐户控制”提升权限对话框时(实际上是consent进程)，桌面背景会呈暗色显示，这可能导致某些显示器弹出“无信号”的错误消息，正好可能挡住consent对话框，让这些用户感到非常不便。
1．原理简析其实这个功能的本意是非常好的，可以增加UAC功能的安全度。原来这个暗色的背景实际上是安全桌面，也就是我们按“Ctrl+Alt+Del”组合键时所看到的蓝色的特殊桌面(上面有类似启动任务管理器等命令)。为什么看到的是暗色的当前桌面呢？原来这是微软为了保持用户体验的一致性，特地对当前桌面做了一个“快照”，将其作为安全桌面的“墙纸”。
由于consent对话框实际运行在安全桌面上(安全桌面运行在session 0上，而用户进程都运行在session 1或者更高的session上)，所以安全性非常好。除了少数系统进程外，任何用户进程都无法和consent对话框进行通信，所以恶意程序无法仿冒提升权限对话框以便诱使用户点击。
由于安全桌面的安全性非常好，所以连我们自己都无法直接监控UAC背后发生了什么，同时甚至无法按PrintScreen键进行截图(剪贴板程序无法获得键盘输入)。
2．如何监控UAC底层变化用常规方法无法对UAC背后的变化进行监控，因为这时候提升权限对话框运行在安全桌面上，用户进程无法与之进行通信，所以我们必须另辟蹊径。
联想到Longhorn Server也具有UAC功能(默认禁用)，所以我们可以利用Longhorn Server搭建一个实验环境，用管理员帐户登录进入Session 1，然后借助远程桌面，以另外一个管理员身份登录到这台实验机，进入Session 2。
我们在Session 1里试图运行一个管理任务，这时候系统会提示权限提升。由于安全桌面的原因，这时候无法在Session 1下用Process Explorer访问consent进程的详细信息。
这时候我们可以在远程桌面窗口(Session 2)下打开Process Explorer，可以很方便地查看consent进程的详细信息，如附图所示，我们可以发现consent进程的父进程是svchost(本例的PID是1008)，查看这个PID 1008的svchost进程，发现是“Application Information Service”服务的宿主进程。所以可以推测是“Application Information Service”服务启动了consent进程。同时还可以看到consent进程本身运行在Session 1，而不是Session 0。
3．禁用安全桌面可以用以下方法禁用安全桌面：
(1) 运行secpol.msc，打开“本地安全策略”管理单元窗口。
(2) 在左侧的控制台树中依次展开本地策略、安全选项，在右侧的详细窗格里双击“用户帐户控制：提示提升时切换到安全桌面”策略项。
(3) 在打开的对话框里选中“已禁用”选项，如附图所示。
让UAC停薪留职不少读者朋友非常讨厌UAC，有时候UAC就像是一位喋喋不休的MM，时不时地打断我们的正常工作。为什么那么多朋友都无法容忍UAC？用户对UAC功能的抱怨大概集中在以下两个方面：
(1) 我已经是管理员了，为什么不直接允许我执行管理任务？如果是第三方应用软件倒也罢了，为什么Windows自带的工具软件都要阻止我？为什么不能让防火墙一样设置规则，让UAC下次不要再提醒？
(2) 为什么转移、删除一个文件都要那么麻烦？
有不少朋友安装好Windows Vista后，第一件事情就是禁用UAC！其实这是一种非常不值得的做法，至少有如下五大理由：
(1) UAC功能是Windows Vista中最大的卖点之一，花费不菲购买了Windows Vista，却把其中最值钱的功能特性给禁用了，这很有点“买椟还珠”的意思。
(2) 如果禁用UAC，则会同时禁用IE保护模式等安全特性，这将大大降低系统的安全性。
(3) 在企业环境里，如果启用UAC，可以减少约40%的桌面相关成本。
(4) 如果禁用了UAC，则当以普通用户登录系统时，无法享受UAC带来的便利(无法方便地安装程序和执行管理任务，也无法享受UAC为遗留应用程序准备的兼容性帮助)。
(5) 强烈推荐正在追MM的GGDD们启用UAC，这可以帮助您提前训练对MM唠叨的抵抗力。
其实从Build 5308、Beta 2，一直到当前最新的5472，UAC功能的进步是有目共睹的，现在UAC的恼人提示已经减少了很多，也增加了很多人性化的改进，UAC功能已经变得越来越平易近人，更多时候，UAC就像一位站在不远处用慈祥目光注视着我们的母亲，而不再是一个在您耳边不停斥责咆哮的上司。
如果您确实讨厌UAC，推荐不要彻底禁用它，而是用以下两种方法将其临时禁用，需要时可以即时恢复。
1．临时摆脱UAC的唠叨—疯狂的石头(1) 打开任务管理器，切换到“进程”标签页，然后结束“Explorer”进程。
(2) 这时候再单击“显示所有用户的进程”按钮，即可让任务管理器运行在管理员的级别上。
(3) 切换到“应用程序”标签页，单击“新任务”按钮，启动“Explorer”进程，现在新启动的“Explorer”进程运行在管理员级别下。
现在虽然在安全中心里显示UAC启用，如附图所示。但是实际上由于Windows系统的Shell进程Explorer此刻连接的访问令牌是管理员级别的，所以在Windows里启动的任何应用程序都自动继承管理员级别的访问令牌，不受UAC的限制，包括执行管理任务和文件操作。
这时候的UAC功能，光凭“肉眼”很难辨别真伪，说它是假的，安全中心里明明显示启用；说它是真的，但是却不会受到任何限制……
——这不就是疯狂的石头吗？
那么如何才能重新回到UAC状态呢？聪明的您一定想到了，那就是用标准用户权限重新启动Explorer进程：
(1) 首先在任务管理器里中止Explorer进程[记住：这时候任务管理器具有管理员权限]，然后关闭任务管理器。
(2) 按“Ctrl+Alt+Del”组合键呼出安全桌面，点击其上的“启动任务管理器”，即可以标准用户权限启动任务管理器，并新建Explorer进程，好了，现在UAC又回来了！
提示 只有在万不得已的情况才使用这种方法，而且推荐仅在该环境里运行管理任务或者进行文件操作时，才用这种方法，至于IE等进程，最好在之前就启动。不过该方法总比彻底禁用UAC功能要好。
2．让UAC闭嘴如果既希望启用UAC功能，又希望让UAC闭嘴，那么可以通过以下方法修改本地安全策略：
(1) 运行secpol.msc，打开“本地安全策略”管理单元窗口。
(2) 在左侧的控制台树中依次展开本地策略、安全选项，在右侧的详细窗格里双击“用户帐户控制：管理审批模式中管理员的提示提升行为”策略项。
(3) 在打开的对话框里选中“无提示”选项，如附图所示。
这时候UAC的功能还是保持启用状态(可以在安全中心里进行验证)，但是当执行管理任务时，系统不再提示确认，而是直接运行。当进行文件操作时，如果遇到权限问题，还是会发出提示，如附图所示，但是单击其上的“继续”按钮，并不会弹出“用户帐户控制”的确认对话框，而是直接完成文件操作。
这种方法的安全性要强于禁用UAC，因为至少这时候IE保护模式等功能还是可以使用的。但是如果一个恶意软件被标记为需要提升权限，那么它同样可以被直接执行。所以为了保证安全性，可以再启用一条比较严厉的策略“用户帐户控制：只提升签名并认证的可执行文件。”这样没有合法数字签名的应用程序将拒绝执行。
提示 仅推荐忍耐力比较差的朋友们使用。
文件操作的噩梦与福音UAC最为人诟病的就是文件操作的不方便，网上曾流传着这样一个笑话：要彻底删除一个文件，需要花费七个步骤。
其实平心而论，这本不是UAC所造成的问题，恰恰相反，如果理解UAC的本质原理，还会发现UAC其实对文件操作是有帮助的。
何以见得？
原来在Windows安全体系中，用户对文件能够进行什么操作，主要是看Explorer进程的访问令牌和文件的访问控制列表。如果该文件的访问控制列表里规定只有管理员才能执行删除操作，那么处于UAC环境下的用户当然不能直接删除该文件，这是因为这时候Explorer进程的访问令牌中，管理员组的SID被过滤掉了。
这就好比，一个普通用户无法在分区根目录下新建文件，道理是一样的。更何况UAC还给我们提供一个机会提升权限，以便可以进行适当的文件操作。
1．到底谁帮助我们提升了权限？这里面就带来一个问题(笔者最初也曾疑惑不解)，既然文件操作主要是看Explorer进程，但是提升权限后，并没有发现Explorer进程的访问令牌有什么变化，这是为什么？难道这个权限是从天上飞下来的？
经过检查发现，当权限提升以后，系统会启动一个Dllhost进程，该进程的访问令牌是管理员级别的，如附图所示，由这个Dllhost进程代替我们完成文件操作。
2．巧妙解决文件操作问题在5456、5472这些Build里，文件操作的UAC权限提升已经得到很大程度上的改善，例如现在按Shift+Del组合键，提升权限后，就可以直接彻底删除文件，而不会像以前版本那样，还需要花N多步骤清空回收站。
如果您还是对现在的UAC文件操作不满意，那么以下的解决方法可能堪称完美：
(1) 首先打开“文件夹选项”对话框，切换到“查看”标签页，确保选中“在单独的进程中打开文件夹窗口”，如附图所示。
Windows默认只能启动一个Explorer进程。而这个设置确保可以打开两个独立的Explorer进程，以便我们给新的Explorer进程链接管理员的访问令牌。
(2) 要想进行文件操作，只需右键单击“Windows资源管理器”菜单项，选择“用管理员帐户运行”，现在就可以打开一个以管理员权限运行的资源管理器窗口，在这里我们可以任意进行文件操作，当然前提条件是文件允许管理员组这样做，不会再出现UAC权限提升的提示。
为了方便起见，还可以为这个资源管理器添加一个开始菜单项：
(1) 把Explorer.exe从%windir%中复制到“文档”里，然后在属性对话框、“兼容性”标签页里勾选“以管理员身份启动该程序”复选框。
(4) 鼠标右键单击其Explorer.exe，选择“附到[开始]菜单”命令，即可在开始菜单里添加菜单项，可以将菜单项重命名为“管理员：Windows资源管理器”。
如果打开Process Explorer，就可以发现，现在系统里有了两个Explorer进程，其中一个进程被标识为“中强制级别”(Mandatory Integrity Level为中级)，这个就是系统的Shell进程。另一个进程被标识为“高强制级别”，这就是以管理员身份运行的“Windows资源管理器”，如附图所示。
这种方法既可以完美地解决文件操作的麻烦，又可以保留UAC功能。当我们在开始菜单或者快速启动栏里启动IE时，IE照样受UAC和IE保护模式的控制，而不会运行在管理员级别下。这是因为，这时候IE的父进程是“中强制级别”的那个Explorer进程。
虚拟重定向和IE保护模式一样，UAC也利用兼容重定向实现对遗留应用程序的兼容性，不过两者采用的是彼此独立、互不干涉的两套机制。其原理大致如下：
某个遗留应用程序由于设计上的原因，需要在管理员权限，这些程序往往可能需要在一些“全局”的位置写文件或者注册表位置，这些“全局”的位置包括C:\Windows、C:\Program Files，还有HKEY_LOCAL_MACHINE注册表分支。
由于UAC的作用，这些遗留应用程序运行在标准用户权限下，所以没有权限往这些“全局”的位置写入内容。这时候虚拟重定向功能就起作用了，它可以把这些“全局”位置重定向到per-user的路径，这样就可以欺骗遗留应用程序，让它可以顺利运行在标准用户状态。
1．实例介绍本文简单介绍文件夹虚拟重定向的实现方法，以记事本为例，此处假设当前登录帐户为Admin，Windows Vista安装在D盘。
(1) 首先必须选择Windows 2000/XP下的记事本，而不是Windows Vista内置的记事本工具。
(2) 打开Windows XP版本的记事本程序， 先确认一下记事本进程的访问令牌，确实是工作在标准用户权限下，如附图所示，也就是说按照道理，记事本不可能对D:\Windows目录有写入权限。
(3) 输入一段内容，然后单击文件、保存，把保存路径设置为D:\Windows，文件名为TestUAC.txt。非常奇怪，保存操作居然没有报错“拒绝访问”。
(4) 打开“我的电脑”，进入D:\Windows文件夹，里面并没有发现TestUAC.txt文件，不过我们在工具栏的最右侧看到了一个“兼容性”按钮。
(5) 单击“兼容性”按钮，即可进入“D:\Users\Admin\AppData\Local\VirtualStore\Windows”目录，可以发现这个目录下有一个TestUAC.txt文件，如附图所示。
在这个过程中，如果用File Monitor进行监控，就会发现，当记事本尝试往D:\Windows目录写入文件时，UAC应该会捕获拒绝访问的权限错误，然后自动启用重定向机制，把这个文本文件重定向(保存)到D:\Users\Admin\AppData\Local\VirtualStore\Windows目录中，如附图所示。
也就是说，UAC会自动把“全局”文件夹位置重定向到“%LocalAppData%\VirtualStore\”目录，这是一个per-user的目录，很显然不同的用户，重定向的目录也有所不同。用户A无法看到用户B的重定向文件。这种隔离对大多数应用程序来说没有什么问题，但是对某些应用程序来说可能存在一些问题，例如某些游戏软件可能要求把游戏得分记录保存在一个公共的位置，以便比较各个玩家的成绩，但是UAC可能会让每个玩家认为只有自己才是最棒的。
据微软的调查结果，UAC的这种兼容性大概能够使得约92%的遗留应用程序可以正常工作在Windows Vista环境下。
2．原理简析从File Monitor截图中我们还能看到一个熟悉的单词“REPARSE”(重解析)，难道它和NTFS文件系统的重解析属性有什么相关吗？其实UAC的兼容重定向是借助一个文件系统的筛选驱动程序(Filter Driver)来实现的，这个驱动的名字是luafv.sys，作为SYSTEM进程的线程在内核模式中加载，如附图所示。
3．配置虚拟重定向有读者朋友肯定早就想问，为什么这个实验必须借助Windows XP下的记事本？为什么不能用Windows Vista自带的记事本工具？原来Windows Vista自带的记事本工具实际上专门为UAC设计的，不能算是遗留应用程序，所以Windows Vista不会为它开启虚拟重定向功能，如果尝试向“全局”位置写入文件，会直接受到拒绝访问的错误消息。
那么标准到底是什么？Windows Vista凭什么不给自带的记事本开启虚拟重定向兼容特性？
原来秘密就在于程序的manifest信息，Windows Vista自带的记事本程序里嵌入了manifest信息，指定了其安全级别为“asInvoker”，Windows Vista将这类定义了安全级别manifest信息的应用程序，一律视作合格的应用程序，不再对此应用虚拟重定向。
用Process Explorer可以查出，Windows Vista自带的记事本的虚拟重定向标记为“No”，而Windows XP记事本的虚拟重定向标记为“Yes”。再例如QQ原本是可以启用虚拟重定向的，但是在manifest文件(QQ.exe.manifest)里添加以下安全级别信息，如附图所：
再启动QQ后，发现其虚拟重定向标记为“No”，如附图所示。
可以在本地安全策略里指定Windows Vista是否启用虚拟重定向功能，方法是禁用“用户帐户控制：将文件和注册表写入错误指定到每个用户位置”策略项。
提示 可以访问以下链接，以查阅《Windows Vista的UAC功能浅析(一)》：
http://www.vistafans.com/thread-36186-1-1.html
