我在SQL Server 2008R2上运行了一个非常奇怪的行为。
我有一个作为SQL Server客户端的第三方应用程序。 我有一个应该有权访问此应用程序的用户的子集。 我创build了一个Active Directory组，称其为“DOM \ appusers”，与几个testing用户。 我创build了一个相同名称的SQL Serverlogin名，创build了一个数据库，将其命名为“appdb”，在appdb数据库创build了一个用户，与login关联的“DOM \ appusers”，并为该用户分配了“db_owner”angular色。
大多数操作工作。 但是他们中的一些人会得到错误。 特别是，一个查询失败：
SELECT x,y,z INTO tmpTable FROM (table1 INNER JOIN table 2 on table1.col1 = table2.col1) INNER JOIN table3 ON table1.col2 = table3.col2 GROUP BY x,y,a,b,c HAVING (((table2.col4)=0) AND ((table3.col5)=0)) AND ((table3.col6)=0) 这是从SQL事件探查器，在那里它标记查询的错误，但没有关于错误的更多细节，和应用程序是无益的，所以我不能告诉你究竟是什么错误抛出。
我不是SQL专家，所以我不知道这个查询有什么特别的地方，或者为什么它需要db_owner之外的权限，但是这不是一个关于SQL查询的问题。
对我来说真奇怪的是，如果我绕过这个组，我会得到不同的结果。 如果我删除上面详细说明的SQL Serverlogin名和用户名，则直接创build一个新的login名和用户引用Active Directory用户，并为其分配相同的db_ownerangular色，然后上面的查询工作。 事实上，所有查询都按预期工作。
这很奇怪，我认为这是我的错误。 我做了三次相同的实验，结果相同。 我validation了testing用户没有上述设置之一就无法访问数据库。 我试着将服务器范围的“sysadmin”angular色分配给AD组，查询开始工作。 显然，我不能这样离开，但这是一个数据点。 我还创build了一个使用SQL Server身份validation而不是Windows身份validation的login，这也起作用。
所以，显而易见的问题是这样的：当用户通过一个组获得他们的权限与“直接”获取权限有什么不同？（就MSSQL的额外login层和数据库用户而言，任何东西都是“直接的”）？ db_owner对于一个用户来说是不是意味着同一件事情？ 这只是一个错误？ 有没有修复？ 我宁愿不必将每个应用程序用户都单独添加到SQL Server用户/login列表中，但这是迄今唯一想到的解决方法。 有没有不同的解决scheme？
在此先感谢您的帮助。 🙂
事实certificate，这不完全是一个“权限”的问题，尽pipe我得到的错误消息。
长话短说，与Windows组相关的SQL服务器用户没有默认架构，也没有办法configuration它。 这是SQL Server 2008R2（以及可能更早的版本）的一个限制，在SQL Server 2012中已得到纠正。
因此，应用程序的查询试图在没有权限的模式中创build它的tmpTable。 当我创build连接到单个Windows用户的SQL Server用户时，它的工作原因是，在这种情况下，它分配了一个默认模式“dbo”，这是正确的模式。 用户有权写在那里，一切正常。
最终，对我来说，唯一的解决scheme是创build连接到各个Windows帐户的单独的SQL Server用户和login名。 这是一个持续的维护麻烦，但这个版本的SQL Server似乎是不可避免的。
我敢肯定，问题在于服务帐户（你说它是作为“networking服务”运行）没有必要的凭据来查找域组成员。 如果一个域用户被操作系统validation为真正的DOMAIN \用户，SQL Server信任这一点，但是如果SQL Server需要查看DOMAIN \ groupmember是否真的是DOMAIN \组的成员，这将失败，因为服务帐户doesn'没有必要的权限来查找这些信息。 因此，组成员可以login，因为操作系统说没关系，但是当稍后检查对象的权限时，查找失败。
尝试作为域用户/域服务帐户运行SQL服务，看看是否有帮助。