晚上，
我想要一些与我们遇到的问题相关的实际确认。
我们有一个 K2/SourceCode 解决方案，它开启了 EXECUTE AS 与 Sql Server 2008 R2 的成功使用。
我们无法直接控制此解决方案的实现方式，即我们无法修改提交给 Sql Server 引擎的查询。当然，我们可以使用 Profiler 捕获它们，它们往往遵循以下模式：
DECLARE @cookie VARBINARY(100);
EXECUTE AS LOGIN = 'DOMAIN\username' WITH COOKIE INTO @cookie;
SELECT @cookie;
exec [dbo].[SomeStoredProcedure] /* ... various params ...*/
exec sp_executesql N'REVERT WITH COOKIE = @cookie;',N'@cookie varbinary(100)',@cookie=/* some cookie value */
所以发生的事情是 [SomeStoredProcedure] 正在用户 [Domain\username] 的安全上下文中执行，服务（应用程序）帐户模拟该用户。我再次强调，我们无法控制这种模式。这就是应用程序的作用。
从表面上看，这种行为是完全可取的，因为我们希望以这样一种方式安排事情，即存储过程可以由当时处于应用程序前端的任何用户有效地执行。
然而，这些查询一直失败，我们的调查最终导致我们从 Sql Server 文档（我的重点）中得出这一点：
指定用户名 或登录名 EXECUTE AS 中指定的用户名或登录名必须分别作为 sys.database_principals 或 sys.server_principals 中的主体存在，否则 EXECUTE AS 语句将失败。此外，必须在主体上授予 IMPERSONATE 权限。除非调用者是数据库所有者，或者是 sysadmin 固定服务器角色的成员，否则即使用户通过 Windows 组成员身份访问数据库或 SQL Server 实例，主体也必须存在。例如，假设以下条件： CompanyDomain\SQLUsers 组有权访问 Sales 数据库。CompanyDomain\SqlUser1 是 SQLUsers 的成员，因此具有对 Sales 数据库的隐式访问权限。尽管 CompanyDomain\SqlUser1 可以通过 SQLUsers 组中的成员身份访问数据库，但语句 EXECUTE AS USER = 'CompanyDomain\SqlUser1' 失败，因为 CompanyDomain\SqlUser1 在数据库中不作为主体存在。如果用户是孤立的（关联的登录不再存在），
我们有大约 30 个最终用户需要能够使用此应用程序，并且要求应用程序安全帐户必须能够模拟这些用户中的任何一个来执行这些存储过程。此要求是固定的，不可协商。
上述文档似乎排除了通过将所有 30 个用户添加到 AD 组、将该组添加为 SQL Server 登录名并授予该组足够权限来满足此要求的可能性。我们的实际测试结果支持这一点 - EXECUTE AS 失败。
获取其中一个用户并在 Sql Server 上为他们提供自己的个人 AD 登录名，该解决方案将成功地为该用户工作。EXECUTE AS 成功，不需要为个人帐户分配必要的权限，因为它们已经通过 AD 组分配。
所以，在这一点上，我有理由相信我知道我将要做什么。要求是每个用户都必须将其 AD 帐户添加为单独的Sql Server Windows 登录名。
然而，在我继续执行这个繁琐的过程之前，我想公开问一个问题：我在这里遗漏了什么吗？
在企业级应用程序上想象一个类似的场景是很有启发性的——这个模型会有些分崩离析，因为需要添加数百个单独的、经过 Windows 身份验证的 Sql Server 登录。撇开这个过程自动化的可能性，以及最终会导致的管理负担，我只是觉得想象这是唯一的方法有点牵强。
我将不胜感激确认和/或评论。
谢谢
罗伯特