您描述的問題是一個經典的雙跳場景,它可以(最終)通過稱爲Kerberos配置的艱苦過程來解決。一個更復雜的解決方法將涉及將來自asp.net應用程序的憑據作爲變量傳遞給數據庫上的SQL查詢。
如果SQL Server將LDAP服務器配置爲鏈接服務器,則可以重寫存儲過程以接受用戶作爲輸入變量,並在繼續之前檢查用戶是否是AD組的成員。考慮將OPENQUERY到您的存儲過程,如下圖所示:
CREATE PROCEDURE CheckAccess
@CurrentUser varchar(max)
AS
IF @CurrentUser IN
(
SELECT CN
FROM OPENQUERY(ADSI,'<LDAP://DC=Your,DC=DomainComponent,DC=com>;(&(CN=*)
(memberOf=CN=YourADGroupName,OU=Your,OU=OrganizationalUnit,OU=Name,DC=Your,DC=DomainComponent,DC=com));CN')
)
THEN
SELECT 'Authorized User'
ELSE
SELECT 'Unauthorized User'
END
如果可以的話,你的LDAP管理員協商,以確保你得到該集團的正確domainComponents和organizationalUnits來調整OPENQUERY。其中一個缺點是,查詢你的AD組可能需要一段時間,顯然取決於成員資格的大小。這可能很痛苦,但只要您的應用程序可以將用戶作爲變量傳遞,您就可以利用OPENQUERY甚至查詢sys.database_principals來檢查其訪問權限。
你可以嘗試的一件事是編寫一個CLR存儲過程。然後,您可以使用WindowsIdentity來執行S4U檢查組成員資格或任何用戶。 – 2012-04-26 01:29:58