第 5 單元：內部網路安全性

確保您內部網路 .NET 應用程式的安全。

瞭解下列情況中使用 ASP.NET Web 應用程式與 SQL Server 2000 進行通訊的相關安全性問題及建議方案：

決定內部網路架構分散式 Web 應用程式中之驗證、授權及安全通訊的最佳實作方法。

Windows XP 或 Windows 2000 Server (含 Service Pack 3) 及更新的作業系統

Microsoft Internet Information Services (IIS) 5.0 及更新版本

Microsoft Active Directory

.NET Framework 1.0 版 (含 Service Pack 2) 及更新版本

SQL Server 2000 (含 Service Pack 2) 及更新版本

您必須具有使用 ASP.NET、SQL Server 及 IIS 進行開發及設定它們的經驗。

您必須具有設定 Windows 安全性及 Active Directory 的經驗。

您必須具有設定 Enterprise Services (COM+) 應用程式的經驗。

請閱讀第 1 單元＜簡介＞。當中定義了驗證、授權及安全通訊對於分散式 Web 應用程式的重要性。

請閱讀第 2 單元＜ASP.NET 應用程式的安全性模型＞。當中提供了建立分散式 ASP.NET Web 應用程式時所使用之架構及技術的概觀，並強調指出驗證、授權及安全通訊在何處適用於此架構。

搭配使用目前的單元與下列示範此單元中所討論之技術的單元：

ASP.NET 連接至 SQL Server

ASP.NET 連接至 Enterprise Services 再至 SQL Server

ASP.NET 連接至 Web 服務再至 SQL Server

ASP.NET 連接至遠端再至 SQL Server

用戶端有 Internet Explorer。

使用者帳戶在 Microsoft Active Directory® 目錄服務中。

應用程式提供各使用者的機密資料。

僅有經過驗證的用戶端，才能存取應用程式。

資料庫信任應用程式，讓它來適當地驗證使用者 (亦即應用程式會代替使用者呼叫資料庫)。

Microsoft SQL Server™ 在進行授權時，使用單一資料庫使用者角色。

建立自訂 ASP.NET 帳戶 (請參閱本手冊中的＜How To：建立自訂帳戶以執行 ASP.NET＞

建立具有最小權限的資料庫帳戶 (請參閱第 12 單元＜資料存取安全性＞)

在網頁伺服器上設定 SSL (請參閱本手冊中的＜How To：在網頁伺服器上設定 SSL＞

設定 IPSec (請參閱本手冊中的＜How To：使用 IPSec 在兩部伺服器間進行安全通訊＞

IIS 中的「整合式 Windows」驗證很適合這個案例，因為所有使用者都有 Windows 帳戶，而且使用 Microsoft Internet Explorer。「整合式 Windows」驗證的優點是不在網路上傳送使用者密碼。此外，因為 Windows 使用目前互動式使用者的登入工作階段，所以對於使用者來說，登入是透明的。

ASP.NET 是以最小權限的帳戶執行，因此可減輕攻擊的潛在破壞。

您不必在 ASP.NET 中模擬，以對原始呼叫者執行 .NET 角色檢查或確保 Windows ACL 中資源的安全。為了對原始呼叫者執行 .NET 角色檢查，它會從 HTTP 內容，擷取代表原始呼叫者的 WindowsPrincipal 物件，如下所示：

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
if ( wp.IsInRole("管理員") )
{
  // 授權使用者執行管理員特定的功能
}

ASP.NET FileAuthorizationModule 會對 ASP.NET 檔案類型 (它們在 IIS 中會對應到 aspnet_isapi.dll) 的原始呼叫者，執行 ACL 檢查。IIS 相當於 .jpg、.gif 及 .htm 檔案等靜態檔案類型的Gatekeeper，它根據與檔案有關聯的 NTFS 使用權限，使用原始呼叫者身分識別，執行存取檢查。

對 SQL Server 執行 Windows 驗證，表示您不用將憑證儲存在檔案中，也不用透過網路將憑證傳遞給資料庫伺服器。

在資料庫伺服器上使用重複的 Windows 帳戶 (與 ASPNET 本機帳戶相符的帳戶)，會增加管理負擔。如果一台電腦上的密碼變更，另一台電腦上的密碼必須同步更新。在某些案例中，您也許可以使用最小權限的網域帳戶，以簡化管理工作。

無法在防火牆中開啟 Windows 驗證需要的通訊埠時，也可以使用重複的本機帳戶作法。此時就不宜使用 Windows 驗證和網域帳戶。

您必須確定 Windows 群組符合安全性需要的細微性。由於 .NET 角色安全性是以 Windows 群組成員資格為基礎，所以這個方案有賴於在正確的細微層次上設定 Windows 群組，以符合存取應用程式的使用者 (共用相同安全性權限) 類別。這裡用來管理角色的 Windows 群組，可能是該電腦的本機群組或網域群組。

慣用 SQL Server 資料庫使用者角色，而不是 SQL Server 應用程式角色，這可避免與使用 SQL 應用程式角色相關的密碼管理和連接共用問題。
應用程式使用角色名稱及密碼，呼叫內建預存程序，以此啟動 SQL 應用程式角色。因此，密碼必須儲存在安全的地方。使用 SQL 應用程式角色時必須停用資料庫連接共用，因為它會嚴重影響應用程式的延展性。

若需 SQL Server 資料庫使用者角色及 SQL Server 應用程式角色的相關資訊，請參閱第 12 單元＜資料存取安全性＞。

資料庫使用者會新增到資料庫使用者角色中，並會指派給角色的使用權限；如果資料庫帳戶變更，您不必變更所有資料庫物件的使用權限。

為何我無法啟用 Web 應用程式的模擬功能，以便可以使用對原始呼叫者設定的 ACL，確保 Web 應用程式存取的資源安全？
如果您啟用模擬，模擬的安全性內容將沒有網路憑證 (假設不啟用委派，而且您正在使用「整合式 Windows」驗證)。因此，遠端呼叫 SQL Server 時，將使用 NULL 工作階段，這會造成呼叫失敗。如果停用模擬，遠端要求即可使用 ASP.NET 處理序身分識別。

前述案例使用 ASP.NET FileAuthorizationModule，它以 Windows ACL 對原始呼叫者身分識別進行授權，不需要模擬。

如果您以「基本」驗證取代「整合式 Windows」驗證 (NTLM)，並且啟用模擬，則每次呼叫資料庫時，都會使用原始呼叫者的安全性內容。每個使用者帳戶 (或使用者所屬的 Windows 群組) 都需要 SQL Server 登入。而且還必須對 Windows 群組 (或原始呼叫者) 確保資料庫物件的使用權限安全。

資料庫不知道誰是原始呼叫者。要如何才可以建立稽核追蹤？
稽核 Web 應用程式中的使用者活動，或將使用者身分識別明確地作為資料存取呼叫的參數來傳遞。

基本驗證及 SSL。大部份的瀏覽器都支援「基本」驗證。由於會在網路上傳遞使用者憑證，您必須使用 SSL，確保案例安全。

用戶端憑證。個別用戶端憑證可以對應到唯一的 Windows 帳戶，或是以單一 Windows 帳戶代表所有用戶端。使用用戶端憑證時也需要 SSL。

表單驗證。表單驗證可以驗證自訂資料存放區 (例如資料庫) 或 Active Directory 的憑證。
驗證 Active Directory 時，請確定只擷取與應用程式有關的必要群組。您不應該盲目擷取 Active Directory 的所有群組，正如不應該使用 SELECT * 子句查詢資料庫。
驗證資料庫時，請務必仔細剖析 SQL 命令中使用的輸入，以防 SQL 資料隱碼攻擊；此外，您應該在資料庫中儲存密碼雜湊 (結合 Salt)，而非純文字或加密的密碼。
若需使用 SQL Server 作為憑證存放區及將密碼存入資料庫的相關資訊，請參閱第 12 單元＜資料存取安全性＞。

使用「資料保護 API (DPAPI)」，確保資料庫連接字串 (含使用者名稱和密碼) 的安全。若需相關資訊，請參閱下列資源：

在網頁伺服器和資料庫伺服器之間使用 IPSec 或 SSL，保護網路上傳遞的純文字憑證。

選擇這個作法時，必須使用 Kerberos 驗證 (設定委派帳戶) 或「基本」驗證。
若需委派案例的相關資訊，請參閱本單元稍後的＜將原始呼叫者傳送到資料庫＞。

此外，必須在 ASP.NET 中啟用模擬。這表示要以原始呼叫者的安全性內容，存取本機系統資源；因此，本機資源 (例如登錄和事件記錄檔) 的 ACL 需要適當的設定。

資料庫連接共用受到限制，因為原始呼叫者無法共用連線。每個連線都與呼叫者的安全性內容相關聯。

傳送使用者安全性內容的另一個作法，是在應用程式層次上傳送原始呼叫者的身分識別 (例如，藉由使用方法和預存程序參數)。

使用者有 Internet Explorer。

元件部署在網頁伺服器上。

傳輸時，必須確保應用程式處理之機密資料的安全。

商業元件使用 Windows 驗證連接到 SQL Server。

這些元件中的商業功能，受限於呼叫者的身分識別。

服務元件設定為伺服器應用程式 (跨處理序)。

元件使用伺服器應用程式的處理序身分識別，連接到資料庫。

在 ASP.NET 中啟用模擬 (發揮 Enterprise Services 角色安全性的功能)。

建立具有最小權限的資料庫帳戶 (請參閱第 12 單元＜資料存取安全性＞)

在網頁伺服器上設定 SSL (請參閱本手冊中的＜How To：在網頁伺服器上設定 SSL＞

設定 IPSec (請參閱本手冊中的＜How To：使用 IPSec 在兩部伺服器間進行安全通訊＞

設定 Enterprise Services 安全性 (請參閱本手冊中的＜How To：同時使用角色安全性和 Enterprise Services＞

ASP.NET 和 Enterprise Services 是以最小權限的帳戶執行，因此可減輕攻擊的潛在破壞。如果任一處理序身分識別被洩露，由於帳戶的權限有限，可以縮小損害範圍。如果 ASP.NET 被插入惡意指令碼，也能抑制可能的損害。

ASP.NET 應用程式必須設定模擬，才能將原始呼叫者的安全性內容，傳送到 Enterprise Services 元件 (以支援 Enterprise Services (COM+) 角色式授權)。如果不模擬，則會對處理序身分識別 (亦即 ASP.NET 工作者處理序) 執行角色檢查。模擬會影響資源的授權對象。
如果不模擬，則會對 ASP.NET 處理序身分識別執行系統資源檢查。如果模擬，則會對原始呼叫者執行系統資源檢查。若需從 ASP.NET 存取系統資源的相關資訊，請參閱第 8 單元＜ASP.NET 安全性＞中的＜存取系統資源＞。

Enterprise Services (COM+) 角色可用來將存取檢查推進到商務邏輯所在的中介層。此時會在閘道檢查呼叫者、對應呼叫者的角色，並且根據角色呼叫商務邏輯。這可以避免呼叫不必要的後端處理。Enterprise Services (COM+) 角色的另一個優點是可以在部署時使用「元件服務管理員」，建立和管理角色。

對 SQL 執行 Windows 驗證，表示您不用儲存憑證，也不用在網路上傳送憑證。

無法在防火牆中開啟 Windows 驗證需要的通訊埠時，您可以使用本機帳戶與資料庫伺服器上的重複帳戶，執行 Enterprise Services 應用程式。此時就不宜使用 Windows 驗證和網域帳戶。

在資料庫伺服器上使用重複的 Windows 帳戶 (與 Enterprise Services 處理序帳戶相符的帳戶)，會增加管理負擔。密碼應該定期執行手動同步更新。

由於 .NET 角色安全性是以 Windows 群組成員資格為基礎，所以這個方案有賴於在正確的細微層次上設定 Windows 群組，以符合存取應用程式的使用者 (共用相同安全性權限) 類別。

HRDept (HR 部門的成員)
這個群組的成員可以擷取任何員工的詳細資料。

PayrollDept (薪資部門的成員)
這個群組的成員可以擷取任何員工的詳細資料。

員工 (所有員工)
這個群組的成員只能擷取自己的詳細資料。

使用者有 Internet Explorer 5.x 或更新版本。

所有電腦都執行 Windows 2000 或更新版本。

使用者帳戶在單一樹系的 Active Directory 中。

應用程式將原始呼叫者的安全性內容一直傳送到資料庫。

各層都使用 Windows 驗證。

設定網域使用者帳戶可以委派。

資料庫不支援委派。

在網頁伺服器上設定 SSL (請參閱本手冊中的＜How To：在網頁伺服器上設定 SSL＞

設定 IPSec (請參閱本手冊中的＜How To：使用 IPSec 在兩部伺服器間進行安全通訊＞

IIS 中的「整合式 Windows」驗證很適合這個案例，因為所有使用者都使用 Windows 2000 或更新版本、Internet Explorer 5.x 或更新版本，而且在 Active Directory 中有帳戶，能夠使用 Kerberos 驗證通訊協定 (支援委派)。這樣則可以跨越電腦界限傳送使用者的安全性內容。

Active Directory 中的使用者帳戶不得標示為「這是機密帳戶，無法委派」。Active Directory 中的網頁伺服器電腦帳戶必須標示為「受信任可以委派」。若需詳細資訊，請參閱本手冊中的＜How To：實作 Windows 2000 的 Kerberos 委派＞。

網頁伺服器和應用程式伺服器上的 ASP.NET 是以最小權限的本機帳戶 (本機 ASPNET 帳戶) 執行，因此可減輕攻擊的潛在破壞。

Web 服務和 Web 應用程式都設定為使用 Windows 驗證。二台電腦上的 IIS 都設定為使用「整合式 Windows」驗證。

從 Web 應用程式呼叫 Web 服務時，預設不會傳遞憑證。只有在回應下游網頁伺服器上的 IIS 發出網路驗證質詢時，才會需要這些憑證。此時，您必須如下所示，設定 Web 服務 Proxy 的 Credentials 屬性，明確指定所要的憑證：

wsproxy.Credentials = CredentialCache.DefaultCredentials;

若需以憑證呼叫 Web 服務的相關資訊，請參閱第 10 單元＜Web 服務安全性＞。

Web 應用程式設定為使用模擬功能。因此，從 Web 應用程式呼叫 Web 服務，不但可以傳送原始呼叫者的安全性內容，還允許 Web 服務驗證 (和授權) 原始呼叫者。

在 Web 服務中使用 .NET 角色，根據使用者所屬的 Windows 群組 (HRDept、PayrollDept 和 Employees)，授權使用者。HRDept 及 PayrollDept 成員可以擷取每個員工的詳細資料，而 Employees 群組成員只能擷取自己的詳細資料。
如下列程式碼範例所示，Web 方法可以使用 PrincipalPermissionAttribute 類別進行註解，要求特定的角色成員。請注意，PrincipalPermission 可以取代 PrincipalPermissionAttribute。這是所有 .NET 屬性類型的一般特性。

[WebMethod]
[PrincipalPermission(SecurityAction.Demand,
                  Role=@"DomainName\HRDept)]
public DataSet RetrieveEmployeeDetails()
{
}

上述程式碼中的屬性表示，只有 DomainName\HRDept Windows 群組成員才能呼叫 RetrieveEmployeeDetails 方法。非成員呼叫這個方法時，會發生安全性例外狀況。

Web 應用程式和 Web 服務中的「ASP.NET 檔案授權」，會對在 IIS Metabase (將檔案類型對應到 Aspnet_isapi.dll) 中有對應之任何檔案類型的呼叫者，執行 ACL 檢查。沒有 ISAPI 對應的靜態檔案類型 (例如 .jpg、.gif、.htm 等)，則由 IIS 來檢查 (同樣使用檔案附加的 ACL)。

因為 Web 應用程式已設定為使用模擬功能，所以應用程式本身存取的資源必須設定 ACL，至少要將讀取權授與原始呼叫者。

Web 服務不模擬或不委派，因此它使用 ASP.NET 處理序身分識別，存取本機系統資源和資料庫。最後，所有呼叫都是以單一處理序帳戶進行的。這樣則可以使用資料庫連接共用。如果資料庫不支援委派 (例如 SQL Server 7.0 或更早版本)，這個案例是很好的選擇。

對 SQL Server 執行 Windows 驗證，表示您不用將憑證儲存在網頁伺服器上，也不用透過網路將憑證傳遞給 SQL Server 電腦。

原始呼叫者和網頁伺服器之間的 SSL，可以保護與 Web 應用程式相互傳遞的資料。

下游網頁伺服器和資料庫之間的 IPSec，可以保護與資料庫相互傳遞的資料。

在資料庫伺服器上使用重複的 Windows 帳戶 (與 ASP.NET 處理序帳戶相符的帳戶)，會增加管理負擔。密碼應該定期執行手動同步更新。
或者，您可以使用具有最小權限的網域帳戶。若需選擇 ASP.NET 處理序身分識別的相關資訊，請參閱第 8 單元＜ASP.NET 安全性＞。

由於 .NET 角色安全性是以 Windows 群組成員資格為基礎，所以這個方案有賴於在正確的細微層次上設定 Windows 群組，以符合存取應用程式的使用者 (共用相同安全性權限) 類別。

Kerberos 委派是無限制的，因此您必須小心控制網頁伺服器上執行的應用程式身分識別。若要提高安全門檻，您應該從 Domain Users 群組中移除該網域帳戶，以限制該帳戶的接觸範圍，並且只讓適當的電腦存取。若需相關資訊，請參閱 Microsoft 網站上的白皮書《Default Access Control Settings (英文)》，網址為： http://www.microsoft.com/windows2000/techinfo/planning/security/secdefs.asp。

使用者有各種類型的網頁瀏覽器。

由 ASP.NET 裝載遠端元件。

Web 應用程式使用 HTTP 通道，與遠端元件通訊。

ASP.NET 應用程式呼叫 .NET 遠端元件，並傳遞驗證用的原始呼叫者憑證。這些憑證可從「基本」驗證取得。

這是機密資料，必須確保它在處理序和電腦之間傳送時的安全。

建立具有最小權限的資料庫帳戶 (請參閱第 12 單元＜資料存取安全性＞)

在網頁伺服器上設定 SSL (請參閱本手冊中的＜How To：在網頁伺服器上設定 SSL＞

設定 IPSec (請參閱本手冊中的＜How To：使用 IPSec 在兩部伺服器間進行安全通訊＞

網頁伺服器和應用程式伺服器上的 ASP.NET 是以最小權限的本機帳戶執行，因此可減輕攻擊的潛在破壞。雙方都使用預設 ASP.NET 帳戶。
使用 ASPNET 本機帳戶 (在 SQL Server 電腦上重複)，可以進一步降低可能的安全性風險。資料庫伺服器上重複的 Windows 帳戶，允許遠端元件使用最小權限的 ASP.NET 帳戶，在應用程式伺服器上執行。

網頁伺服器的「基本」驗證，允許 Web 應用程式以使用者憑證回應應用程式伺服器的 Windows 驗證質詢。
Web 應用程式為了以呼叫者憑證來呼叫遠端元件，於是將遠端元件 Proxy 設定為下列的程式碼片段。

string pwd = Request.ServerVariables["AUTH_PASSWORD"];
string uid = Request.ServerVariables["AUTH_USER"];
IDictionary channelProperties =
                         ChannelServices.GetChannelSinkProperties(proxy);
NetworkCredential credentials;
credentials = new NetworkCredential(uid, pwd);
ObjRef objectReference = RemotingServices.Marshal(proxy);
Uri objectUri = new Uri(objectReference.URI);
CredentialCache credCache = new CredentialCache();
credCache.Add(objectUri, "Negotiate", credentials);
channelProperties["credentials"] = credCache;
channelProperties["preauthenticate"] = true;

若需將安全性憑證傳送到遠端元件的相關資訊，請參閱第 11 單元＜.NET 遠端處理安全性＞。

ASP.NET Web 應用程式不啟用模擬，因為遠端 Proxy 是以「基本」驗證取得的使用者憑證而特別設定的。Web 應用程式存取的任何其他資源，使用 ASP.NET 處理序帳戶提供的安全性內容。

使用者和網頁伺服器之間的 SSL，可以保護與網頁伺服器相互傳遞的資料，以及驗證處理程序期間以純文字方式傳遞的「基本」憑證。

應用程式伺服器的「整合式 Windows」驗證，提供原始呼叫者的 .NET 角色檢查。這些角色對應到 Windows 群組。

即使不模擬，也能執行角色式檢查。

「ASP.NET 檔案授權」會對在 IIS Metabase (將檔案類型對應到 aspnet_isapi.dll) 中有對應之任何檔案類型的呼叫者，執行 ACL 檢查。IIS 會對靜態檔案 (未對應到 IIS 中的 ISAPI 擴充程式) 執行存取檢查。

由於應用程式伺服器未啟用模擬，於是遠端元件使用 ASP.NET 安全性內容來存取本機或遠端資源。此外，別忘了設定 ACL。

對 SQL Server 執行 Windows 驗證，表示您不用將憑證儲存在應用程式伺服器上，也不用透過網路將憑證傳遞給 SQL Server 電腦。

在資料庫伺服器上使用重複的 Windows 帳戶 (與 ASP.NET 處理序帳戶相符的帳戶)，會增加管理負擔。密碼應該定期執行手動同步更新。

由於 .NET 角色安全性是以 Windows 群組成員資格為基礎，所以這個方案有賴於在正確的細微層次上設定 Windows 群組，以符合存取應用程式的使用者 (共用相同安全性權限) 類別。

您必須在資料庫中精細存取，而且使用權限受限於物件。特定的使用者或群組可以讀取，其他使用者或群組可以寫入到個別物件。
相比之下，在較粗略的工作授權中，由角色成員決定特定物件的讀取及寫入功能。

您可能想使用平台稽核功能，取代傳送身分識別以及在應用程式層次上執行稽核。

ASP.NET 連接至 SQL Server

ASP.NET 連接至 Enterprise Services 再至 SQL Server

「基本」驗證以快顯對話方塊提示使用者鍵入憑證 (使用者名稱和密碼)。

資料庫必須辨識原始呼叫者。如果網頁伺服器和資料庫分屬不同網域，則必須啟用適當的信任關係，讓資料庫驗證原始呼叫者。

使用者有 Internet Explorer 5.x 或更新版本。

所有電腦都是 Windows 2000 或更新版本。

在單一樹系的 Active Directory 中維護使用者帳戶。

應用程式將原始呼叫者的安全性內容 (在作業系統層次上) 一直傳送到資料庫。

各層都使用 Windows 驗證。

設定網域使用者帳戶可以委派，Active Directory 中用來執行 Enterprise Services 應用程式的帳戶必須標示為「受信任可以委派」。

Active Directory 中的 Enterprise Services 處理序帳戶必須標示為「受信任可以委派」，而使用者帳戶不得標示為「這是機密帳戶，無法委派」。若需相關資訊，請參閱本手冊中的＜How To：實作 Windows 2000 的 Kerberos 委派＞。

所有電腦都需要 Windows 2000 或更新版本。這包含用戶端 (瀏覽器) 電腦和所有伺服器。

所有電腦必須在 Active Directory 中，而且必須屬於單一樹系。

裝載 Enterprise Services 的應用程式伺服器，必須在執行 Windows 2000 SP3。

如果您在 Windows 2000 上使用 Internet Explorer 6.0，則預設為 NTLM 驗證 (而非所需的 Kerberos 驗證)。若要啟用 Kerberos 委派，請參閱 Microsoft 知識庫文件 Q299838＜Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6 (英文)＞。

Kerberos 驗證會產生委派層次語彙基元，它是傳送原始呼叫者之安全性內容的關鍵。伺服器處理序 (IIS) 可以將收到的委派層次語彙基元，傳遞給同一台電腦上任何帳戶下執行的任何其他處理序，而不必變更其委派層次。即使工作者處理序是以本機或網域帳戶執行也不要緊。但是要注意 IIS 是以何種身分執行。如果不是以 LocalSystem 執行，執行的帳戶必須在 Active Directory 中標示為「受信任可以委派」。
如果 IIS 是以 LocalSystem 執行，電腦帳戶必須標示為「受信任可以委派」。若需相關資訊，請參閱本手冊中的＜How To：實作 Windows 2000 的 Kerberos 委派＞。

IIS 中的「整合式 Windows」驗證 (使用 Kerberos) 很適合這個案例，因為所有使用者都有 Windows 帳戶，而且使用 Internet Explorer 5.x 或更新版本。「整合式 Windows」驗證的優點是不在線路上傳送使用者密碼。此外，因為 Windows 使用目前互動式使用者的登入工作階段，所以登入是透明的。

ASP.NET 會建構 WindowsPrincipal 物件，並將它附加到目前的 Web 要求內容 (HttpContext.User)。如果您必須在 Web 應用程式中執行授權檢查，則可以使用下列程式碼。

WindowsPrincipal wp = (HttpContext.Current.User as WindowsPrincipal);
if ( wp.IsInRole("管理員") )
{
  // 授權使用者執行管理員特定的功能
}

ASP.NET FileAuthorizationModule 會對 ASP.NET 檔案類型 (它們在 IIS 中會對應到 Aspnet_isapi.dll) 的原始呼叫者，執行 ACL 檢查。IIS 相當於 .jpg、.gif 及 .htm 檔案等靜態檔案類型的Gatekeeper，它使用原始呼叫者身分識別，執行存取檢查。

對 SQL 執行 Windows 驗證，您則不用將憑證儲存在應用程式伺服器的檔案中，也不用在網路上傳遞憑證。例如，將 Trusted_Connection 屬性併入連接字串中：

ConStr="server=YourServer; database=yourdatabase; Trusted_Connection=Yes;"

原始呼叫者的內容在所有層上傳送，很容易稽核。您可以使用平台層次稽核 (例如，Windows 和 SQL Server 提供的稽核功能)。

如果您在 Windows 2000 上使用 Internet Explorer 6.0，則所交涉的預設驗證機制是 NTLM (而非 Kerberos)。若需相關資訊，請參閱 Microsoft 知識庫文件 Q299838＜Unable to Negotiate Kerberos Authentication After Upgrading to Internet Explorer 6 (英文)＞。

與使用可信任的子系統模型相比，在各層間委派使用者，需要耗費很大的效能和應用程式延展性。資料庫的連線與原始呼叫者的安全性內容相關，因而無法有效運用集區，也就無法發揮資料庫連接共用的優點。

這個作法也要求 Windows 群組的細微層次符合應用程式的安全性需要。亦即必須在正確的細微層次上設定 Windows 群組，以符合存取應用程式的使用者 (共用相同安全性權限) 類別。