Windows7中的不同之處
我在前面提過，Windows7中的某些操作現在可由標准用戶執行，但正如有關UAC的E7博客文章所述，我們還認識到，我們可以在不影響UAC的目標的情況下使Windows體驗更加流暢。許多用戶抱怨說，當他們執行常見的系統管理操作時，WindowsVista本身會頻繁地請求管理權限。使Windows能夠針對標准用戶環境正常工作對我們最有利，因為這樣將為我們的客戶帶來利益。但是，提升權限提示並沒有告誡或鼓勵我們這樣做，而是會強制用戶在絕大多數用戶都不理解的對話框中再次單擊。因此，Windows7開始從默認Windows體驗中最大程度地減少這些提示，並使以管理員身份運行的用戶能夠控制其提示體驗。
為此，我們進一步重構了系統，這樣，擁有標准用戶權限的用戶將能執行更多任務，並且，我們減少了若干多提示方案(例如，在IE中安裝ActiveX控件)中的提示數量。Windows7還引入了兩種新的UAC操作模式，可以在新的UAC配置對話框(請參閱圖3)中選擇這些模式。通過轉到控制面板，單擊“用戶帳戶”，單擊“用戶帳戶”，然後單擊“更改用戶帳戶控制設置”，您可以打開該對話框。(您也可以通過單擊提升權限提示上的“顯示這些通知時進行更改”鏈接或通過訪問“操作中心”來進入該對話框。)
圖3中顯示的默認設置就是其中一個新級別。與位於滑塊頂部並相當於WindowsVista中的默認模式的“始終通知”不同，只有當非Windows可執行文件請求提升時，Windows7才會默認提示用戶;針對非Windows提升的行為與WindowsVista相同。
下面接下來的滑塊位置是第二個新設置，它的標簽相同，只是後面附加了“(不降低桌面亮度)”。該模式和默認模式的唯一不同之處在於：提示將出現在用戶的桌面(而不是安全桌面)上。這樣的好處是：用戶可以在提示處於活動狀態的同時與桌面交互，但正如我之前提到的，將會出現第三方輔助功能軟件可能無法在該提示對話框上正常工作的風險。
最後，如果選擇最底部的滑塊位置，將會完全禁用UAC技術，這樣，所有采用PA帳戶運行的軟件都將使用完全管理權限運行、文件系統和注冊表虛擬化將被禁用，並且保護模式IE將被禁用。盡管采用此設置時將沒有提示，但保護模式IE的損失是此模式的一個很大的弊端。
自動提升
在采用中間兩種設置時，之所以(大多數)Windows可執行文件的提升不會產生提示，其原因在於系統“自動提升”了Windows可執行文件。首先，在此上下文中，Windows對Windows可執行文件的定義是什麼?答案取決於若干因素，但有兩個條件必須得到滿足：該可執行文件必須經過WindowsPublisher的數字簽名，WindowsPublisher是用於對Windows附帶的所有代碼進行簽名的證書(僅由Microsoft進行簽名是不夠的，因此Windows未附帶的Microsoft軟件不包括在內);並且該可執行文件必須位於其中一個為數不多的“安全”目錄中。安全目錄是指標准用戶無法修改的目錄，並且它們包括%SystemRoot%/System32(例如，/Windows/System32)及其大多數子目錄、%SystemRoot%/Ehome，以及%ProgramFiles%下的少許目錄(其中包括WindowsDefender和Windows日記本)。
同時，視可執行文件是普通.exe、Mmc.exe還是COM對象而定，自動提升還有一些附加規則。如果.exe種類的Windows可執行文件(如前面所定義)在其清單中指定了autoElevate屬性，這些可執行文件將會自動提升。應用程序也將在該清單中向UAC指明它們需要管理權限。此處的SysinternalsSigcheck實用工具通過命令“sigcheck–m%systemroot%/system32/taskmgr.exe”來轉儲任務管理器(Taskmgr.exe)的清單，該清單顯示任務管理器已加入自動提升，如圖4所示。
在目錄樹中查找自動提升可執行文件的一種簡便方法是，通過如下所示的命令使用SysinternalsStrings實用工具：
strings–s*.exe|findstr/iautoelevate
還有一個硬編碼列表，其中包含獲得自動提升處理的Windows可執行文件。這些Windows可執行文件也並非是Windows7附帶的內部文件，因此它們必須能夠在autoexecute屬性會導致錯誤的舊版系統上運行。列表中包括Migwiz.exe(遷移向導)、Pkgmgr.exe(程序包管理器)和Spinstall.exe(ServicePack安裝程序)。
將對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在Windows7的最終版本中也未自動提升，因為對於任何常見管理任務而言，並不需要對其進行提升，並且，如果Rundll32.exe進行了自動提升，則它通過命令行承載任意DLL的能力將會導致開發人員要求使用管理員權限，而自己卻未意識到。
自WindowsVista測試版發布以來，最終用戶一直在要求Windows提供一種向自動提升列表中添加任意應用程序的方法。經常被提及的原因是：他們常用的某個第三方應用程序強制他們不斷單擊提升權限提示，而這已經成為他們日常工作的一部分。就像WindowsVista一樣，Windows7並未提供這種功能。我們理解這種操作非常繁瑣，並且可能有這些應用程序無法在沒有管理權限的情況下運行的合理原因，但開發人員將會避免將其代碼修正為使用標准用戶權限，而這樣的風險太高。即使有關哪些應用程序進行自動提升的列表只能由管理員訪問，但開發人員只需更改其要求一次性提升的應用程序安裝程序，就可將其應用程序添加到列表中。作為替代，我們選擇進行投資來進行培訓並與應用程序開發人員密切合作，以確保其程序能夠以標准用戶身份正常工作。
很多人發現，采用PA帳戶通過標准用戶權限運行的第三方軟件可以利用自動提升來獲取管理權限。例如，軟件可以使用WriteProcessMemoryAPI將代碼注入資源管理器，並使用CreateRemoteThreadAPI來執行該代碼，這種技術稱為DLL注入。由於代碼在資源管理器(一種Windows可執行文件)中執行，因此它可以利用自動提升的COM對象(比如“復制”/“移動”/“重命名”/“刪除”/“鏈接”對象)來修改系統注冊表項或目錄，並為軟件授予管理權限。如果是這樣，這些步驟將需要蓄意謀劃，而且並非無關緊要，因此，與將其軟件修正為使用標准用戶權限來運行相比較，我們不相信正當的開發人員會選擇進行這些步驟。事實上，我們建議任何應用程序開發人員不要依賴於系統中的提升行為，並且建議應用程序開發人員測試其軟件在標准用戶模式下運行的情況。
接下來的發現是，惡意軟件可以使用同樣的技術獲取管理權限。同樣，情況確實如此，但正如我前面指出的，惡意軟件也可以通過提示的提升來危害系統。從惡意軟件的角度來看，Windows7的默認模式並不比“始終通知”模式(“Vista模式”)安全多少，並且，采用管理權限的惡意軟件在Windows7的默認模式下運行時，將仍然會崩潰。
結論
總而言之，UAC是一組具有一個整體目標的技術：使用戶能夠以標准用戶身份運行。因為對Windows進行了更改，使標准用戶能夠執行以前需要管理權限的更多操作，再結合文件和注冊表虛擬化以及提示，從而共同實現了此目標。最終標准是：默認的Windows7UAC模式通過減少提示使PA用戶的體驗更加流暢、允許用戶控制可以修改其系統的合法軟件，並仍然實現UAC的目標，即讓更多的軟件能夠在沒有管理權限的情況下運行，並繼續使軟件生態系統轉變為編寫能夠使用標准用戶權限工作的軟件。
