Windows NT使用兩種導致訪問嘗試失敗返回錯誤5的機制：確認權限和確認特權。權限屬于對象上的行為，比如掛起線程權限或讀文件權限。權限總是與特定對象和已知用戶相關聯。例如，讀文件權限必須與文件（權限應用在此文件上）和有或沒有權限的用戶相關聯。同樣，掛起線程權限除非與特定的線程和用戶關聯否則沒有用。

　　特權是預先定義好的屬于系統上操作的權限。例如，特權有調試程序、備份和恢復存儲設備以及裝入驅動程序。特權以用戶為中心，而不是對象。

　　為了使兩者之間區分得更清楚，可以看一下實現權限和特權的數據結構：權限在叫作訪問控制表（ACL）的數據結構中指定。ACL通常與對象相關。用戶用訪問令牌表示。當用戶試圖訪問受保護的對象時，其訪問令牌與對象的ACL檢查。訪問令牌包含代表用戶的唯一標識符（安全性ID，或SID）。ACL中的每個權限與一個SID相關；這樣，安全性子系統就知道了與每個用戶相關的權限。

　　另一方面，特權在訪問令牌中編碼，所以沒有相關聯的對象。要確定用戶是否允許做某個與特權有關的操作，安全性子系統檢查訪問令牌。

　　此外，權限需要行為的說明（干什么的權限？例如，讀文件或者掛起線程），而特權不需要（用戶或者有特權，或者沒有）。與特權相隨的操作隱含在特權本身中。

　　特權在訪問令牌中編碼的原因是大多數特權不考慮安全性需求。例如，允許備份存儲設備的用戶必須能夠繞過文件安全性。為了允許用戶訪問而給硬盤上每個單獨的文件都加入一個新的ACE是不可行的。這樣，備份存儲設備的代碼首先檢查試圖備份的用戶是否擁有備份特權；如果有，單個文件的安全性就被忽略。

　　能夠與訪問令牌相關的特權集被牢固加密，不能被應用程序展開。服務器程序能夠使用特殊的權限和普通的映射實現自定的安全性規則。

　　有兩種類型的ACL：自由決定的(DACL)和系統的(SACL)。DACL管制對象訪問，SACL管制審核。

　　控制訪問

　　在大多數情況下，錯誤5是由Windows NT特有的叫作AccessCheck的Win32函數內部產生的。此函數的輸入有用戶的訪問令牌、需要的特權和ACL。ACL主要是小數據結構（叫作訪問控制元素，或ACE）的列表，每個數據結構定義一個用戶或一組用戶、一個權限集合以及允許或拒絕的信息。例如，ACL中可能有一個ACE寫著“從紙盒中拿走雞蛋的權限明確地拒絕給與用戶Elephant和Bozo”，后面一個ACE寫著“從紙盒中拿走雞蛋的權限明確地準予給與用戶Betty Crocker以及CHEFS組中所有用戶”。

　　ACL與對象相關，可以在服務器程序中動態創建。例如，如果一個文件對象與一個ACL相關，不管何時有應用程序試圖打開該文件對象，ACL就會被查詢以決定是否允許運行應用程序的用戶打開文件。

　　AccessCheck函數被許多系統函數內部調用，例如，CreateFile（用戶試圖在NTFS分區或命名管道上打開文件時）和OpenFileMapping。然而，Win32服務器程序能夠直接調用AccessCheck，保護想保護的任何對象。

　　注意安全性API函數只被服務器程序調用；客戶不需要或直接使用安全性。客戶曾經看到的Windows NT安全性就是錯誤5。這使得Windows NT安全性可以不必考慮客戶運行的軟件。需要的是服務器在域的安全性數據庫中確認客戶以及將從客戶收到的請求翻譯成服務器端函數調用的能力。此函數或者隱含調用AccessCheck，或者根據服務器端AccessCheck的輸出發送或不發送其結果。

　　Windows NT security中容易混淆的部分是對AccessCheck的調用可能是非常模糊的。例如，Windows NT監控設備驅動程序安裝的功能是一個非常模糊的概念。當試圖添加設備驅動程序時用戶要訪問哪個“對象”？系統在哪里調用AccessCheck以及必要時在哪里將錯誤信息顯示給用戶？

　　在設備驅動程序的例子中，答案還不是太困難：因為設備驅動程序和系統通過注冊表（Windows NT通過瀏覽注冊表子樹，解釋每個條目，嘗試執行在單獨注冊表項中指定的驅動程序二進制文件而裝入設備驅動程序）交互，Windows NT保護的對象是注冊表項，它在Windows NT中是可以得到的對象。在Win32 API層，任何操作注冊表的嘗試將會翻譯成注冊表工作的函數，例如RegOpenKey內部調用AccessCheck。

　　除了注冊表保護外，驅動程序二進制文件也有安全性問題。一個因訪問注冊表被拒絕而落空的黑客仍然能夠用添加了額外功能的驅動程序副本取代原有的驅動程序執行文件。這一過程不需要訪問注冊表，所以Windows NT如何防止這類問題呢？相當簡單，通過要求驅動程序二進制文件存放在NTFS分區并限制對其訪問。這樣，取代驅動程序二進制文件的企圖（在Win32 API層上調用DeleteFile或CreateFile時不可避免地被終止）會被AccessCheck抓住，惡意的黑客就不走運了。

　　系統提供的其它安全性對象可能難于說明。例如，怎樣阻止用戶訪問被保護的網絡共享？怎樣阻止打開遠程計算機上的服務控制管理器？系統層如何使Windows NT無懈可擊？如何使一些安全性函數自己失敗返回錯誤5，訪問被拒絕？設想如果應用程序能夠自由操作自己的訪問令牌或調用安全性函數改變對象的特權將會出現什么情況？這種情況下，僅僅修改ACL和令牌中的項目就能夠簡單的繞過安全性。。這樣，必須有某種“元安全性”，一種保護安全特性自己不被錯誤利用的機制。如何實現？

　　基于AccessCheck的安全性實現的一個結果是安全性嚴重依賴于只允許以眾所周知的入口點訪問安全性對象的體系結構。例如，Windows 3.1家族操作系統中的文件系統包括許多不同入口點：中斷21h（與文件系統交互），中斷13h（與磁盤設備驅動交互），以及幾種類型的提供對文件系統訪問的C運行庫和Windows API函數（如OpenFile和_fopen）。從安全性觀點來看，在OpenFile內部實現中調用AccessCheck這樣的函數毫無用處，應用程序可以簡單的調用_fopen繞過文件安全性。只有打開文件操作的所有不同調用都翻譯成一個“安全性”調用才行；如果有一個執行安全性檢查而另一個不執行，就會有安全性問題。

　　16位Windows系統中這種“開放文件系統”結構對提供如加密軟硬件的公司來說是主要的麻煩。

　　在編寫安全性服務器程序時，將程序設計的無懈可擊是絕對必要的；也就是說，必須防止客戶可以訪問關鍵數據的所有方法。安全性系統的挑戰之一是使關鍵數據無懈可擊。這可能是一件相當復雜的工作，就象前面的例子中，單獨保護注冊表入口對于保護整個計算機的設備驅動程序是不夠的。

　　訪問權限類型

　　使用安全性API，系統能夠幫助管制對幾乎任何種類對象的訪問。但“訪問”的含義是什么？是不是談論數據庫字段時所使用的訪問類型，還是與訪問其它窗口的消息循環完全不同的某種類型？

　　這就是為什么“訪問”在安全性API中是一個相當普遍的術語。不是像“打開、關閉、讀取和寫入對象的權限”這種牢固加密的訪問類型，Windows NT中的訪問被定義為掩碼中位的集合。安全性子系統將用戶訪問掩碼中的位與對象訪問掩碼中的位進行匹配。例如，這使得我們能夠設計一個員工數據庫，管理員可以讀寫工資和獎金的信息，經理可以讀但不能寫，其他人不能讀寫訪問。

　　以相同的方式，應用程序能夠定義自己的訪問類型。例如，如果程序想保護一個可以共享（從幾個用戶都能夠調用函數操作屏幕上對象的意義上）的OpenGL對象，可以為OpenGL對象能夠完成的所有操作（如旋轉、拉伸、反彈和移動）定義唯一的訪問權限，并且為每個需要對圖象進行操作的用戶指定這些權限的唯一子集。

　　安全性API能夠以三組權限工作：

• 標準權限（為每種對象類型提供相同操作的權限）。

• 特殊權限（對每個對象類型有特殊意義的權限。兩種不同類型的對象可能有相同的權限掩碼位，但有對權限意義的不同翻譯）。

• 普通權限，概略的占位符（象GENERIC_READ和GENERIC_WRITE此類的權限，幾乎適用于所有對象類型，但對不同對象類型有不同的意義）。普通權限被映射為標準權限和特殊權限。這一機制允許服務器不用實際定義操作就可以建立“讀”和“寫”的概念。服務器程序能夠用普通權限工作，不管讀寫是對文件還是對數據庫對象，對象自己能夠確定普通權限如何翻譯成特殊權限。