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

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

如果您一直在尋找中間層中的通用授權解決方案，那么您的搜索可以告一段落了。

授權管理器簡介

授權管理器（通常稱為 AzMan）是 Windows 的一種通用的、基于角色的新安全體系結構。AzMan 與 COM+ 無關，因此它可以用在任何需要基于角色的授權的應用程序中，包括 asp.net Web 應用程序或 Web 服務、基于 .NET Remoting 的客戶-服務器系統等等。在撰寫本文時，授權管理器僅在 Windows Server?2003、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。運行庫審核還滿足了長期需要。

授權管理器具有大量功能，用戶在編寫安全代碼時的部分工作是弄清楚應用程序需要這些功能的哪個子集。最后，請記住，應該盡可能地將事情簡單化，以避免打開安全漏洞。