在中間層 .NET 應用程序中經過受權管理器使用基於角色的安全

基於角色的安全是從 Windows NT 的第一個版本開始在 Windows 平臺上發展而來的。使用角色，操做系統能夠經過檢查稱爲 BUILTIN\Administrators 的組的安全上下文作出一些決定，例如，進程是否有特權。操做系統基於該邏輯角色作出決定（例如，是否讓您安裝服務或設備驅動程序）。在安裝操做系統時，您能夠經過將相應的用戶添加到 Administrators 組來選擇誰將承擔該角色。

Microsoft 事務服務 (MTS) 和 COM+ 試圖使基於角色的安全成爲一種讓應用程序開發人員感受愉快的功能，而且爲 COM 服務器提供了一個簡單的、基於角色的受權基礎結構。目標是爲多層服務器應用程序啓用受信任的子系統模型，其中應用程序服務器受到後端資源的信任以批准請求。經過及早執行受權，能夠避免向後端服務器委託客戶端憑據的須要。委託充滿了從潛在的安全漏洞到可伸縮性問題等大量問題。

若是您一直在尋找中間層中的通用受權解決方案，那麼您的搜索能夠告一段落了。

受權管理器簡介

受權管理器（一般稱爲 AzMan）是 Windows 的一種通用的、基於角色的新安全體系結構。AzMan 與 COM+ 無關，所以它能夠用在任何須要基於角色的受權的應用程序中，包括 ASP.NET Web 應用程序或 Web 服務、基於 .NET Remoting 的客戶-服務器系統等等。在撰寫本文時，受權管理器僅在 Windows Server?200三、Windows 2000 的 Service Pack 4 中提供，而且預計做爲 Windows XP 將來的 Service Pack 發佈。

AzMan 有兩個部分：運行庫和管理 UI。運行庫由 AZROLES.DLL 提供，它公開了一組供那些利用基於角色的安全的應用程序使用的 COM 接口。管理 UI 是一個 MMC 管理單元，您能夠經過運行 AZMAN.MSC 或者經過向您選擇的 MMC 控制檯中添加受權管理器管理單元對其進行試驗。（請注意，管理 UI 與較舊的平臺不兼容，所以您將須要使用運行 Windows Server 2003 的計算機來管理 AzMan。）[編輯更新 — 1/9/2004：Windows Server 2003 管理工具包使您能夠在運行 Windows XP Professional 的計算機上安裝 Windows Server 2003 管理工具。]

當運行圖 1 中顯示的 AzMan 管理工具時，您將注意到的第一件事情是它比 COM+ 提供的功能複雜得多。您再也不只具備角色和角色分配操做。您如今具備能夠分配給任務的低級別操做，而任務隨後又能夠分配給角色。任務能夠包含其餘任務，而角色能夠包含其餘角色。這一分層方法有助於改進目前複雜的應用程序中所需的好像不受限制的角色集。

圖 1 管理管理器

如下是任務和角色的建立方式。應用程序設計器定義了被視爲安全敏感的整個低級別操做集。而後，該設計器定義了一組映射到這些操做的任務。任務被設計爲可由業務分析師理解，所以一個給定任務老是由一個或多個低級別操做組成。若是用戶被授予執行某個任務的權限，則他或她就被授予了執行該任務中全部操做的權限。做爲一個示例，一個名爲「提交採購定單」的任務可能由下列操做組成：得到下一個 PO 編號、將 PO 排隊和發送通知。固然，您能夠老是簡單地將每一個任務映射到單個操做，以使事情儘量保持簡單，可是若是您須要的話，則能夠利用分隔任務和操做所具備的靈活性。

在定義任務和操做以後，就能夠開始編碼了，而且不管什麼時候須要執行敏感操做，均可以包含對 AzMan 運行庫的調用。該調用是 IAzClientContext.AccessCheck，稍後我將說明一個有關它的用法的示例。

在部署時，應用程序安裝程序會設置一個 AzMan 存儲區（做爲 Active Directory? 的一部分，或者在簡單的 XML 文件中），並安裝基本的低級別操做和任務。管理員使用 AzMan 管理單元來查看該應用程序的任務的定義和說明。而後，管理員定義對於他/她的組織有意義的角色。就像任務被定義爲一組低級別操做同樣，角色一般被定義爲一組任務。而後，管理員能夠向這些角色分配用戶和組。實際上，從這時開始，管理員在維護應用程序方面的主要工做將是隨着人員加入或離開公司或者更改職銜，在角色中添加和移除用戶。

迄今爲止，我已經重點介紹了應用程序開發人員和管理員，可是實際上可能存在第三個幫助部署的人 — 業務邏輯腳本撰寫者。每一個任務均可以具備關聯的腳本。這裏的思路是：找到一般經過調用 IsCallerInRole 制定的動態安全決策，將它們移出應用程序代碼並移至某個位置，以便管理員無需修改和從新編譯代碼就能夠對應用程序的安全策略進行更改。

返回頁首

示例應用程序：公司庫

讓咱們觀察一個示例。假設您要構建一個系統以管理公司圖書館。您須要可以管理書籍庫存以及書籍的借閱和歸還等等。您將使用 AzMan 實現基於角色的安全。

首先，您須要建立設計中出現的敏感操做列表：

•

閱讀目錄

•

佔位（爲本身或他人）

•

借書

•

還書

•

將書籍添加到庫存

•

從庫存中移除書籍

•

閱讀顧客歷史記錄（爲本身或他人）

請注意，有幾個操做對只在運行時纔會具備的信息敏感。例如，當試圖閱讀顧客的歷史記錄時，應用程序必須提供上下文信息，指示用戶是在試圖訪問他/她本身的歷史記錄仍是他人的歷史記錄。當創建原型時，可使用 AzMan 管理單元將這些操做添加到簡單的 XML 存儲區。圖 1 顯示了這一添加過程。

若是您要嘗試本身繼續操做，請運行 AZMAN.MSC，而且經過「Action | Options」菜單確保您處於開發人員模式。在 XML 文件中建立一個新的存儲區，而後在該存儲區中建立一個新的應用程序。接下來，逐個地添加操做，而且賦予它們名稱和表明操做編號的惟一整數。應用程序開發人員使用該編號來標識 AccessCheck 調用中的操做。請注意，在命名操做時，我已經用前綴「op.」對名稱進行了編碼。這只是爲了在稍後建立任務和角色時避免命名衝突，由於這些名稱所有來自相同的池而且必須是惟一的。

AzMan 管理單元在兩種模式下操做：開發人員和管理員。在管理員模式下，您沒有選擇建立存儲區或應用程序的自由，而且您不能改動應用程序代碼所依賴的低級別操做定義。坦白地說，沒有什麼東西可以妨礙系統管理員進入開發人員模式並完成這些操做，但要點是在管理員模式下，UI 中選項的數量將減小，以簡化管理員的工做並幫助他們避免錯誤。

圖 2 AzMan 中的任務定義

下一個步驟是定義一組映射到這些低級別操做的任務，以便管理員可以輕鬆定義角色。由於您使操做列表保持簡單，因此能夠爲每一個操做定義單個任務。除非您絕對須要更高的複雜性，不然有一個保持事情簡單的很好的理由，而且它必須與業務邏輯腳本有關 — 我稍後纔會對其進行詳細討論。所以，如今讓咱們定義一系列基本上與個人操做相同的任務。圖 2 顯示了在 AzMan 中編輯任務定義時的工做模式。

返回頁首

受權存儲區

如今是改變您的身份並僞裝您是部署應用程序的管理員的時候了。在「Action | Options」菜單下切換到管理員模式，而且注意 GUI 是如何更改的：您再也不可以編輯應用程序的低級別操做了。繼續操做，而且按照圖 3 中的定義爲應用程序添加角色。

圖 3 角色和任務

在這裏，一種簡化事情的方式是將角色嵌套。例如，能夠根據 Patron 角色定義 Clerk，而且添加「借書」和「還書」任務，如圖 4 中所示。請嘗試用 COM+ 完成該工做。

圖 4 嵌套角色

管理員須要作的最後一件事情是經過向這些抽象角色中添加真實的用戶使它們變得具體。爲此，請選擇「Role Assignments」文件夾，並選擇「Assign Roles」操做。請注意，角色只有在被添加到該文件夾以後，纔會實際上變爲活動角色。例如，IAzApplication.Roles 屬性只返回已經添加到 Role Assignments 文件夾中的角色集合，而不是已經定義的全部角色。在分配角色以後，請當即右鍵單擊它以添加 Windows 用戶和組，或者添加您先前已經在 AzMan 存儲區中定義的應用程序組。我將在本文的稍後部分對應用程序組進行介紹。

返回頁首

AzMan 運行庫接口

在定義了一些操做和任務以後，就能夠開始在代碼中實現訪問檢查了。您須要考慮的第一件事情是身份驗證。若是您可使用一些內置的 Windows 管線（就像 Web 服務器對 Kerberos 身份驗證的支持同樣），則能夠得到客戶端的令牌。這是到目前爲止使用 AzMan 的最普通的方式，由於令牌包含用戶所在的全部組，從而能夠快速地將該用戶映射到一組 AzMan 角色。另外一方面，若是您要使用表單或 X.509 證書對用戶進行身份驗證，則您將不會具備令牌。相反，您將只具備該用戶的名稱。這並不意味着您沒法使用 AzMan，甚至也不意味着您將必須編寫更多的代碼。可是這確實意味着將須要付出更大的代價，由於 AzMan 運行庫將必須手動查找該用戶的組。這會引發與域控制器之間的往返行程。

應用程序須要作的第一件事情是初始化 AzMan 運行庫，使其指向它計劃使用的存儲區，而且向下探測到應用程序中存放受權設置的位置。如今，讓咱們使用簡單的基於 XML 的存儲區：

AzAuthorizationStore store = new AzAuthorizationStoreClass();
store.Initialize(0, @"msxml://c:\MyStore.xml", null);
IAzApplication app = store.OpenApplication(
    "Corporate Library Application", null);

要生成該應用程序，項目須要引用 AzMan interop 程序集，它位於 %WINDIR%\Microsoft.NET\Framework\AuthMan 目錄中。

既然要引導該應用程序，那麼在對新的客戶端進行身份驗證時，您須要構建客戶端的安全上下文的表示。該上下文在緩存用戶的角色映射方面很是相似於令牌：

IAzClientContext ctx =
  app.InitializeClientContextFromToken(htoken, null);

到哪裏去得到客戶端的令牌？唔，這取決於您要編寫哪一個類型的應用程序。例如，下面是某個 ASP.NET 頁中的用於得到客戶端令牌的 C# 代碼。在該示例中，web.config 指定身份驗證模式爲「Windows」，而且已經將 IIS 配置爲須要集成 Windows 身份驗證：

WindowsIdentity id = (WindowsIdentity)User.Identity;
IntPtr htoken = id.Token;

若是您只知道客戶端的名稱而且不能訪問它們的令牌，請嘗試弄清楚是否存在您能夠得到的令牌，由於令牌是發現客戶端的組的最權威方式。就像我先前提到的那樣，它仍是最快的方式。若是您確定本身沒法得到該客戶端的令牌，則請使用下面的備用方法來根據形如「域\用戶」的賬戶名稱來初始化上下文。該調用可能引發爲發現域組而產生的往返行程，因此請作好須要花費一些時間來執行該操做的思想準備：

IAzClientContext ctx =
  app.InitializeClientContextFromName(name, null);

在具備客戶端上下文之後，就能夠運行訪問檢查。該調用採用不少參數，但如今我將使事情保持簡單。讓咱們假設您要實現一個向庫存中添加書籍的函數。我將「向庫存中添加書籍」定義爲操做編號 5，所以代碼可能如圖 5 所示。

第一個參數 nameOfBook 是一個在啓用運行庫審覈後使用的字符串。它標識您要對其執行操做的對象，所以您應當老是在這裏提供一些有意義的信息。我已經使用了第二個參數 scopes 的默認值。稍後我將對該參數進行解釋。第三個參數用於列出您要測試的一個或多個操做。結果是一個老是與操做數組大小相同的數組，帶有與每一個操做相對應的整數狀態代碼，以指示是授予仍是拒絕訪問權限。零表示訪問檢查成功，而且容許該上下文標識的客戶端執行指定操做。其餘任何值都表示失敗（一般您將看到的是數字 5，即 ERROR_ACCESS_DENIED）。

AzMan 運行庫接口不是強類型的。它對於本身的大多數參數都使用 VARIANT。這容許傳統的使用腳本語言的 ASP 程序員使用 AzMan，可是意味着使用強類型語言（如 C# 和 Visual Basic .NET）的程序員可能在調用 AccessCheck 時犯下一些直到運行時纔會發覺的錯誤。例如，操做數組的類型必須是 object[]，而不是 int[]，可是若是您傳遞 int[]，則編譯器不會抱怨，由於參數的實際類型是對象。當我一開始學習該 API 時，這個問題讓我感到困惑，我花費了好長時間才弄清楚究竟應該如何編寫代碼才能避免出現因爲參數類型不匹配而形成的運行時錯誤。我已經聽到有傳聞說最終將出現 AzMan 的託管接口，可是在此以前，您可能但願爲 AccessCheck 編寫強類型的包裝以免犯錯誤。下面的代碼顯示了一個示例，它還簡化了調用該函數的最多見方式：

public class AzManWrapper {
  public static int AccessCheck(
             IClientContext ctx,
             string objectName,
             int operation) {
    object[] results = (object[])ctx.AccessCheck(
         objectName, scopes, ops,
         null, null, null, null, null);
    return (int)results[0];
  }
}

經過包裝，能夠提供本身的 AccessCheck 重載，以便處理在須要其餘可選參數時出現的更復雜狀況。特別地，爲該函數使用包裝應當可以減小不少困難，而且下降應用程序代碼的混亂程度。您甚至可使用該包裝將 AccessCheck 失敗轉換爲異常，而不是與 IPermission.Demand 行一塊兒返回狀態代碼。儘管如此，請不要過於執着以致於包裝整套接口，由於該函數其實是惟一一個難以調用的函數。

此刻，您可能想知道的一件事情是：在使用 AzMan 時是否能夠不使用 Windows 賬戶來表示用戶。運行庫在設計時考慮了該問題，儘管您須要爲每一個用戶定義自定義安全標識符 (SID) — 這不是很是困難，而且您必須調用一個備用方法來初始化客戶端安全上下文，即 InitializeClientContextFromStringSid。最大的障礙是您將沒法使用 AzMan 管理單元來管理存儲區（它們與 Windows 用戶和組很是緊密地耦合在一塊兒）。有關如何處理該問題的詳細信息，請參閱本文開頭引用的由 Dave McPherson 撰寫的白皮書。

返回頁首

存儲區、應用程序和範圍

我但願能回顧一些內容，稍微介紹一下受權存儲區的結構。首先，您具備兩個用於存儲受權設置的選擇：能夠將整個存儲區放到 XML 文件中，或者在 Active Directory 中承載它。我強烈建議對於生產應用程序使用 Active Directory，由於它比簡單的 XML 文件提供了更多的功能，而且一般還會提供更好的性能。

若是您在實驗室中具備能夠利用的測試域，請嘗試啓動 AzMan 管理單元，在 Active Directory 中建立一個新的存儲區，並賦予其以下所示的獨特名稱：「CN=MyStore, CN=Program Data, DC=MyDomain, DC=com」（將 MyDomain 替換爲您本身的域）。要查看 AzMan 在 Active Directory 中建立了哪些對象，請使用諸如 ADSIEdit（這是一個能夠從 Windows Server 2003 CD 中經過運行 SUPPORT\TOOLS\SUPTOOLS.MSI 安裝的 MMC 管理單元）之類的工具。在該存儲區中建立一個應用程序，而且啓動新應用程序的屬性頁。您將注意到，該屬性頁上含有在使用簡單 XML 文件時不存在的安全和審覈選項卡。

在 Active Directory 存儲區中，能夠委託管理存儲區中的單個應用程序的職責，而且能夠在很是詳細的級別審覈對存儲區進行的更改。使用 XML 文件，您會受到用 NTFS 權限和審覈保護文件自己的限制。當前，只有在將存儲區放置在目錄中的時候，運行時審覈纔會受到支持，而審覈對於大多數應用程序而言都是很是重要的。若是 Active Directory 可用，則我強烈敦促您將 AzMan 存儲區放到它裏面，由於它是用於承載 Windows 中安全策略的最佳處所。

單個存儲區能夠容納多個應用程序。每一個應用程序都具備它本身的用於操做、任務和角色的命名空間。若是您在多個應用程序中共享存儲區，則請注意併發問題，由於存儲區尚不支持併發編輯。若是您認爲兩個管理員有可能同時編輯單個存儲區，則須要提供一些外部鎖定來序列化對該存儲區的訪問；不然，該存儲區可能會被破壞。AzMan 管理單元不提供該功能，等到它提供該功能時，您最好限制每一個存儲區的內容以免併發編輯。最簡單的解決方案是將每一個存儲區限制爲容納單個應用程序。

每一個應用程序還能夠定義多個範圍，這是受權管理器的一種高級功能，而且我只向已經進一步學習 AzMan 而且絕對須要這一額外級別複雜性的人們推薦該功能。範圍使您能夠對應用程序的不一樣部分具備不一樣的受權設置。例如，在大型 Web 應用程序中，能夠在特定子目錄下面以某種方式分配角色；在不一樣的子目錄下，可能以不一樣方式分配角色，或者可能定義一組徹底不一樣的角色。

在這種狀況下，範圍可能很方便，由於它們能夠共享低級別的操做定義，甚至可能共享某些任務、角色和應用程序組。遺憾的是，它們還可能令人感到困惑而且容易濫用。例如，在調用 AccessCheck 時，可使用第二個參數指定要用於檢查的範圍。若是用戶將提供範圍名稱（或許經過請求中的 URL），則您在將其傳遞給 AccessCheck 以前，最好可以確保該範圍名稱是規範化的；不然，聰明的用戶可能經過以意外的方式對名稱進行編碼，欺騙您使用更脆弱的範圍。若是您不熟悉這種類型的攻擊，則應當閱讀 Writing Secure Code, Second Edition (Microsoft Press, 2002) 中有關規範化的章節。要了解有關像範圍這樣的高級功能的詳細信息，請參閱本文開頭引用的由 Dave McPherson 撰寫的白皮書。

返回頁首

應用程序組

在 AzMan 中，有一種稱爲「應用程序組」的很是好的功能。在大型組織中，將新組添加到目錄中以便應用程序使用可能很是辛苦。實際上，若是隻有您的應用程序須要特定的組定義，則當疲憊不堪的域管理員拒絕向他/她的已經幾乎沒法管理的組列表中添加另一個條目時，那麼您可能會很是不走運。在這種狀況下，應用程序組能夠拯救您。在存儲區、應用程序或範圍級別，能夠定義用戶組而且向它們分配邏輯組名稱。而後，您能夠在角色分配中使用這些應用程序組。

AzMan 提供了兩種類型的應用程序組：基本組和輕量級目錄訪問協議 (LDAP) 查詢組。基本組很是相似於 Active Directory 中的組，可是有一點兒不一樣：能夠定義包含成員和排除成員。例如，您能夠定義一個名爲 EveryoneButBob 的組，就像我在圖 6 中所作的那樣。優勢是功能和方便性都獲得了增長。缺點是肯定該應用程序組中的成員身份所需的 CPU 週期數以及存儲應用程序組中的成員身份列表所需的內存都增長了，所以請謹慎使用該功能。若是喜歡圖 6 中顯示的排除功能，您仍然能夠經過使用域組做爲應用程序組中的成員來得到該功能，從而減小 AzMan 須要在內存中保持的成員身份列表的大小。

圖 6 容許除一人 (Bob) 以外的全部人

LDAP 查詢組是 AzMan 的一項代價高昂可是很不錯的功能。在這裏，您可使用 LDAP 查詢語法定義在某種程度上相似的用戶組。例如，如下是能夠用來定義至少 21 歲的工程師集合的方式：

(&(age>=21)(memberOf= CN=eng,DC=foo,DC=com))

無論組的類型是基本組仍是 LDAP 查詢組，管理員均可以使用這些應用程序組做爲向角色分配用戶的備用方式。

返回頁首

腳本

對於靜態受權不能知足須要的狀況，應用程序能夠用變量和對象引用的形式向 AccessCheck 提供額外的上下文。這使腳本編寫者可使用 JScript? 或 VBScript 添加業務邏輯，而無需更改和從新編譯應用程序。例如，能夠向先前定義的閱讀顧客歷史記錄任務提供額外的上下文（或許是用戶所屬的角色集），以及一個指示客戶是訪問他/她本身的歷史記錄仍是他人的歷史記錄的布爾值。這將使您可以編寫腳本，以容許經理查看任何顧客的歷史記錄，可是普通顧客只能限於查看他們本身的歷史記錄。能夠爲該任務編寫如圖 7 中所示的腳本。

要將該腳本與閱讀顧客歷史記錄任務相關聯，請調出該任務的定義頁，瀏覽到包含該腳本的文件，將語言指定爲 VBScript，而後按「Reload Rule into Store」按鈕。

返回頁首

支持受權腳本

要支持圖 7中顯示的腳本，您將須要向任何涉及閱讀顧客歷史記錄任務的訪問檢查多傳遞幾個參數。因爲您已經將事情簡單化，而且每一個操做只定義了一個任務，所以這意味着每當您詢問有關相應操做的狀況時，均可以提供該上下文。如下是一個代碼片斷，它顯示瞭如何爲腳本編寫者提供這些額外的上下文：

bool self = _userIsCheckingOwnHistory();
object[] operations = { opReviewPatronHistory };
object[] scopes     = { "" };
object[] varNames   = { "roles", "self" };
object[] varValues  = { ctx.GetRoles(""), self };

object[] results = (object[])
ctx.AccessCheck(nameOfPatronHistory,
                scopes, operations,
                varNames, varValues,
                null, null, null);

AzMan 對於 varNames 和 varValues 數組的順序有一點兒挑剔。您必須像我同樣按字母順序對 varNames 進行排序。而後，varValues 數組必須爲 varNames 中的每一個命名參數提供相應值，這一點很是明顯。若是您要顯得更加獨出心裁，則可使用 AccessCheck 的最後三個參數傳入命名的對象引用。這會將腳本編寫者看到的對象模型擴展至默認的 AzBizRuleContext 對象之上。我將讓您本身對該功能進行試驗，以及解決您在決定支持腳本後可能遇到的一些難題。

您將可能注意到的有關腳本的第一件奇怪的事情是，它們是在任務和角色級別定義的，而不是在操做級別定義的。可是，應用程序程序員爲單個操做執行訪問檢查以及提供上下文變量，所以腳本編寫者如何知道將向給定任務提供哪些變量？很明顯，應該由開發人員基於各個操做來仔細編寫相關文檔。一種策略是使事情真正簡單化，而且不管要執行哪一個操做，都老是傳遞相同的上下文變量。這固然能夠爲腳本編寫者簡化事情。在個人圖書館示例中，我當心地針對每一個操做定義了一個任務，所以我能夠爲每一個任務自定義上下文變量，但請記住，管理員在管理模式下運行時能夠定義新任務。若是系統管理員要定義一個新任務以便將兩個分別提供不一樣上下文變量的操做集成在一塊兒，那麼會發生什麼狀況呢？只需努力使事情簡單化，而且仔細說明應該如何編寫腳本以便避免出現這些使人討厭的狀況。

在編寫腳本時須要警戒的另一件事情是，腳本的結果被緩存在客戶端上下文對象中以便提升效率。扔掉客戶端上下文時，就同時扔掉了緩存。瞭解這一點是有好處的，由於某些腳本或許依賴於可能隨時間而更改的外部數據。

請注意，設計腳本的目的是使它們所附加到的任務或角色具備某種資格。例如，假設 Alice 是角色 R1 和 R2 的成員。角色 R1 被直接授予執行操做 X 的權限。角色 R2 被授予相同的權限，可是該受權是經過腳本進行的。當 Alice 試圖執行操做 X 時，AzMan 甚至沒必要運行角色 R2 中的腳本，由於操做 X 已經經過角色 R1 進行了靜態受權。於是，腳本不能用來完全拒絕權限。它們只能用來決定是否應當在某個訪問檢查中考慮特定的任務或角色。僅僅是由於腳本化的任務或角色因爲其相應腳本計算爲假而被忽略，並不意味着不存在仍會向要測試的操做受權的徹底不一樣的任務或角色。Dave McPherson 撰寫的白皮書提供了有關運行庫如何實現訪問檢查的很是詳細的說明。您能夠在「Performance」一節中找到相關內容。對於全部對使用 AzMan 持認真態度的讀者，我建議您仔細研究該節的內容。

返回頁首

審覈

訪問檢查的運行庫審覈是一項重要功能，而且僅當您使用 Active Directory 中的受權管理器存儲區時纔可用。若是要啓用該功能，請右鍵單擊應用程序，選擇「Properties」，而後經過「Auditing」選項卡啓用該功能。在運行時，用來運行服務器進程的賬戶很重要：必須授予它「生成審覈」特權。內置的賬戶 Local Service、Network Service 和 SYSTEM 默認狀況下都具備該特權。最後，請注意，服務器計算機必須啓用對象訪問權限審覈功能，才能在安全事件日誌中捕獲這些審覈。

您在啓用審覈以後將看到的現象是，對 AccessCheck 的每一個調用都會產生一個審覈條目，該條目中的對象名稱是您做爲 AccessCheck 的第一個參數傳遞的任何字符串。操做的易記名稱將與客戶端的名稱一塊兒顯示在審覈中。若是檢查成功，則將記錄成功訪問；不然，您將在該日誌中看到失敗的訪問。您是否可以同時看到成功和失敗審覈，取決於您經過 Windows 安全策略啓用的對象訪問審覈的級別。

返回頁首

小結

受權管理器是一種用於在 Windows 中構建安全系統的重要工具 。它對 MTS 和 COM+ 所普及的基於角色的安全的思想進行了擴展，它幾乎能夠由任何服務器應用程序而不只僅是基於 COM 的服務器使用。受權管理器致力於幫助用戶將安全邏輯集中到能夠存儲在 Active Directory 中的簡潔安全策略中，而且提供了用於執行訪問檢查的簡單 API。運行庫審覈還知足了長期須要。

受權管理器具備大量功能，用戶在編寫安全代碼時的部分工做是弄清楚應用程序須要這些功能的哪一個子集。最後，請記住，應該儘量地將事情簡單化，以免打開安全漏洞。