图 3 中显示的默认设置就是其中一个新级别。与位于滑块顶部并相当于 Windows Vista 中的默认模式的“始终通知”不同，只有当非 Windows 可执行文件请求提升时，Windows 7 才会默认提示用户;针对非 Windows 提升的行为与 Windows Vista 相同。
下面接下来的滑块位置是第二个新设置，它的标签相同，只是后面附加了“(不降低桌面亮度)”。该模式和默认模式的唯一不同之处在于：提示将出现在用户的桌面(而不是安全桌面)上。这样的好处是：用户可以在提示处于活动状态的同时与桌面交互，但正如我之前提到的，将会出现第三方辅助功能软件可能无法在该提示对话框上正常工作的风险。
最后，如果选择最底部的滑块位置，将会完全禁用 UAC 技术，这样，所有采用 PA 帐户运行的软件都将使用完全管理权限运行、文件系统和注册表虚拟化将被禁用，并且保护模式 IE 将被禁用。尽管采用此设置时将没有提示，但保护模式 IE 的损失是此模式的一个很大的弊端。
自动提升
在采用中间两种设置时，之所以(大多数)Windows 可执行文件的提升不会产生提示，其原因在于系统“自动提升”了 Windows 可执行文件。首先，在此上下文中，Windows 对 Windows 可执行文件的定义是什么?答案取决于若干因素，但有两个条件必须得到满足：该可执行文件必须经过 Windows Publisher 的数字签名，Windows Publisher 是用于对 Windows 附带的所有代码进行签名的证书(仅由 Microsoft 进行签名是不够的，因此 Windows 未附带的 Microsoft 软件不包括在内);并且该可执行文件必须位于其中一个为数不多的“安全”目录中。安全目录是指标准用户无法修改的目录，并且它们包括 %SystemRoot%/System32(例如，/Windows/System32)及其大多数子目录、%SystemRoot%/Ehome，以及 %ProgramFiles% 下的少许目录(其中包括 Windows Defender 和 Windows 日记本)。
同时，视可执行文件是普通 .exe、Mmc.exe 还是 COM 对象而定，自动提升还有一些附加规则。如果 .exe 种类的 Windows 可执行文件(如前面所定义)在其清单中指定了 autoElevate 属性，这些可执行文件将会自动提升。应用程序也将在该清单中向 UAC 指明它们需要管理权限。此处的 Sysinternals Sigcheck 实用工具通过命令“sigcheck –m %systemroot%/system32/taskmgr.exe”来转储任务管理器 (Taskmgr.exe) 的清单，该清单显示任务管理器已加入自动提升，如图 4 所示。
在目录树中查找自动提升可执行文件的一种简便方法是，通过如下所示的命令使用 Sysinternals Strings 实用工具：
strings –s *.exe | findstr /i autoelevate
还有一个硬编码列表，其中包含获得自动提升处理的 Windows 可执行文件。这些 Windows 可执行文件也并非是 Windows 7 附带的内部文件，因此它们必须能够在 autoexecute 属性会导致错误的旧版系统上运行。列表中包括 Migwiz.exe(迁移向导)、Pkgmgr.exe(程序包管理器)和 Spinstall.exe(Service Pack 安装程序)。
将对 Microsoft 管理控制台 Mmc.exe 进行特殊处理，因为它承载了多个以 DLL 形式实现的系统管理管理单元。Mmc.exe 通过命令行启动，该命令行指定一个 .MSC 文件，其中列出要加载的管理单元 MMC。Mmc.exe 将在通过 PA 帐户启动时请求管理权限，当 Windows 发现这一点时，它将验证 Mmc.exe 是否为 Windows 可执行文件，然后检查 .MSC。为了获得自动提升资格，.MSC 文件必须满足 Windows 可执行文件条件(由 Windows 在安全的位置中签名)，并且必须列在自动提升 .MSC 的内部列表中。该列表实际上包括 Windows 附带的所有 .MSC 文件。
最后，COM 对象可以通过创建一个名为 Elevation 的子项(其名为 Enabled 的值设置为 1)，利用其注册表项中的注册表值来指定需要管理权限。图 5 显示了外壳的“复制”/“移动”/“重命名”/“删除”/“链接”对象的注册表项，当用户对其帐户没有权限访问的位置执行文件系统操作时，资源管理器将使用该对象。
要使 COM 对象能够自动提升，它还必须是 Windows 可执行文件，并且必须已由 Windows 可执行文件进行实例化。(不过，无需将实例化可执行文件标记为自动提升。)例如，当您使用资源管理器通过 PA 帐户在 %ProgramFiles% 目录中创建目录时，操作将会自动提升，因为 COM 对象请求了提升、对象的 DLL 是 Windows 可执行文件，并且资源管理器是 Windows 可执行文件。
自动提升与 UAC 的目标
那么，所有特殊自动提升规则背后的原理是什么?选择要自动提升哪些程序以及不自动提升哪些程序是由以下问题确定的：“应用程序开发人员是否能够利用自动提升无意间或不费力地依赖于管理权限?”由于可以使用 Cmd.exe 通过命令行参数来执行批处理脚本，并且普通用户不需要以提升方式运行命令提示符(大多数用户甚至不知道命令提示符是什么)，因此未将 Cmd.exe 列入自动提升的清单。同样，承载控制面板插件的可执行文件 Rundll32.exe 在 Windows 7 的最终版本中也未自动提升，因为对于任何常见管理任务而言，并不需要对其进行提升，并且，如果 Rundll32.exe 进行了自动提升，则它通过命令行承载任意 DLL 的能力将会导致开发人员要求使用管理员权限，而自己却未意识到。
自 Windows Vista 测试版发布以来，最终用户一直在要求 Windows 提供一种向自动提升列表中添加任意应用程序的方法。经常被提及的原因是：他们常用的某个第三方应用程序强制他们不断单击提升权限提示，而这已经成为他们日常工作的一部分。就像 Windows Vista 一样，Windows 7 并未提供这种功能。我们理解这种操作非常繁琐，并且可能有这些应用程序无法在没有管理权限的情况下运行的合理原因，但开发人员将会避免将其代码修正为使用标准用户权限，而这样的风险太高。即使有关哪些应用程序进行自动提升的列表只能由管理员访问，但开发人员只需更改其要求一次性提升的应用程序安装程序，就可将其应用程序添加到列表中。作为替代，我们选择进行投资来进行培训并与应用程序开发人员密切合作，以确保其程序能够以标准用户身份正常工作。
很多人发现，采用 PA 帐户通过标准用户权限运行的第三方软件可以利用自动提升来获取管理权限。例如，软件可以使用 WriteProcessMemory API 将代码注入资源管理器，并使用 CreateRemoteThread API 来执行该代码，这种技术称为 DLL 注入。由于代码在资源管理器(一种 Windows 可执行文件)中执行，因此它可以利用自动提升的 COM 对象(比如“复制”/“移动”/“重命名”/“删除”/“链接”对象)来修改系统注册表项或目录，并为软件授予管理权限。如果是这样，这些步骤将需要蓄意谋划，而且并非无关紧要，因此，与将其软件修正为使用标准用户权限来运行相比较，我们不相信正当的开发人员会选择进行这些步骤。事实上，我们建议任何应用程序开发人员不要依赖于系统中的提升行为，并且建议应用程序开发人员测试其软件在标准用户模式下运行的情况。
接下来的发现是，恶意软件可以使用同样的技术获取管理权限。同样，情况确实如此，但正如我前面指出的，恶意软件也可以通过提示的提升来危害系统。从恶意软件的角度来看，Windows 7 的默认模式并不比“始终通知”模式(“Vista 模式”)安全多少，并且，采用管理权限的恶意软件在 Windows 7 的默认模式下运行时，将仍然会崩溃。
结论
总而言之，UAC 是一组具有一个整体目标的技术：使用户能够以标准用户身份运行。因为对 Windows 进行了更改，使标准用户能够执行以前需要管理权限的更多操作，再结合文件和注册表虚拟化以及提示，从而共同实现了此目标。最终标准是：默认的 Windows 7 UAC 模式通过减少提示使 PA 用户的体验更加流畅、允许用户控制可以修改其系统的合法软件，并仍然实现 UAC 的目标，即让更多的软件能够在没有管理权限的情况下运行，并继续使软件生态系统转变为编写能够使用标准用户权限工作的软件。
