Ste*_*Bov 6 permissions sql-server-2008-r2 sql-server-2012 sql-server-agent
我们的组织中有三个独立的用户组（开发、支持、实施）。就目前情况而言，每个人都使用一次登录来完成所有事情。我们正开始摆脱这种情况。每个人都通过自己的登录名访问数据库，每个人都可以访问其组系统。因此，支持人员可以访问支持职能和工作等。
过程和表的允许权限非常简单。从 windows 组创建登录名。然后根据该登录创建一个用户，并允许它在我们为他们创建的新架构上读取和执行。
我们正在运行 SQL Server 2012 和 2008 R2。
SQL 代理作业位于用户级别之上，需要将登录名分配给所有者。但它不接受组登录作为接受的参数：
指定
@owner_login_name无效（有效值由sp_helplogins[不包括Windows NT 组]返回）。
希望允许这些组拥有自己的一组可以直接操作的作业（在报告服务器上而不是实时数据库上）。不影响其他部门的工作或其他工作（数据库维护任务、复制等）。但如果原始作者不在办公室或已经离开，则允许团队的其他成员操纵工作。
我尝试过四处搜索，但到目前为止，我在 2010 年在sqlservercentral.com上发现的唯一一件事说这是无法完成的。
将 SQL 代理作业分配给无人有权访问的支持/开发通用帐户。但每个人都可以以某种方式操纵自己的工作。
这将允许人们改变团队的工作，同时允许个人离开公司后继续使用工作。
我还没有找到一种方法让人们能够通过其他所有者访问/运行作业（即使他们使用相同的 Windows 组登录到 sql）。不授予他们SQLAgentOperateorRole （这会破坏将他们锁定在外的意义）彼此（和管理员）的工作。
每个组创建一个用户，该用户具有 msdb 权限的附加访问权限以及他们可以登录以操作作业的标准支持功能。
这样做的缺点是现在用户有两个登录名，其中之一不会改变。因此，离开公司的用户仍然可能拥有该帐户的登录凭据，这也会导致用户变得懒惰，只在该帐户下登录。（他们不应该这样做，但说实话，他们会的）。
每个组都有一个每 5 分钟运行一次的 SQL 作业，其中包含一个表，其中包含用于以频率 x 运行此命令的命令（本质上一个 SQL 代理作业运行自定义编写的 SQL 代理作业列表）。
我认为我不需要经历这是一个多么可怕的想法。但这是已经半考虑过的事情。
显然，我们可以看到的最佳解决方案是允许一个组拥有 SQL 代理作业，但似乎这是不可能的。
有人有主意吗？目前，我们将不胜感激有关如何实施此类事情的指导。
由于 SQL Server 代理不支持使用 Windows 组作为 SQL Server 代理作业的所有者。你可以这样做，但这意味着最终要绕过内置的限制。
您可以使用下面链接中发布的一些代码。
允许非系统管理员、非 SQL Server 代理作业所有者执行它
此方法围绕 SQL 代理作业的“所有者”执行“结束运行”，以实现执行的所有实际目的。这是因为dbo.StartAgentJob存储过程使用表中的登录名和组dbo.msdbJobMap来决定谁可以运行 SQL 代理作业。正如所写的，它将包括分配给该作业的组中的任何成员，并且有权启动该作业。
这意味着任何有权创建 SQL Server 代理作业（SQLAgentReaderRole或更高级别的成员）的人都可以创建和修改自己的 josb。
如果他们还有权在表中插入正确的 GroupName 和 JobName dbo.msdbJobMap，则分配给该作业的这些组中的任何人也都可以执行该作业。
尽管组不直接拥有该作业，但dbo.StartAgentJob存储过程将使用其提升的权限来确定是否允许组的登录名和/或成员执行该作业。
仍然存在什么问题？
SQL 代理作业的所有者是唯一可以编辑作业内容的人。（当然，系统管理员几乎可以做任何事情。）
如果需要重写 SQL 代理作业并且 所有者不再存在于系统中，系统管理员可以将作业所有者从已失效的帐户更改为新的指定所有者。（或者编写作业脚本并将脚本提供给开发人员，开发人员将进行重写并为新作业指定一个新名称。）
因此，让开发人员完全独立于管理员并不是一个100%的解决方案，但它应该大大减少所需的交互。
脚注：如果作业要在分布式服务器上运行，这还不够。