您描述的问题是一个经典的双跳场景,它可以(最终)通过称为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