Windows 用户权限和任何一组 SQL Server GRANT 之间的区别似乎是不相关的概念。通常情况下，它似乎实际上是使用数据库角色的伪登录来实现的；但这并不能有效地映射回 Windows 权限。假设单登录身份验证，为什么不使用最简单的数据库角色呢？
编辑：
到目前为止，我们已经获得了您不需要在应用程序中存储密码的单一好处；但这似乎更像是一个微不足道的有益结果，而不是设计目标；还有许多其他更直接的方法可以实现这一点，而无需紧密耦合两个宇宙的整个安全设备。
再次编辑：
除了单一登录和 SD 维护组的能力之外，没有其他人有任何好处可以建议，从而复制 SQL Server 中已经存在的组功能（基于相同的用户登录）？
小组问题有几个缺陷，包括假设 AD 经理同样有资格维护这两者；并且它排除了不属于 AD 的任何网络连接（从而将您锁定在 MS 技术中。）
用最佳实践的术语来说，你已经建立了系统的耦合，这通常被认为是一件坏事。
其中许多已经说过或与以前的答案相似......使用AD集成：
a) 我不必担心有权访问任何给定应用程序的用户，我可以将其传递给安全人员。
b）我可以根据已经存在的组来限制表级别的访问，以及强制标准用户只能调用存储过程的能力。
c) 当开发人员离开我的小组时，我们不必更改所有数据库密码（即，如果您关心数据安全......）
d) 根据进行更改的用户进行自定义日志记录很容易。还有其他方法可以做到这一点，但我只是懒惰。
e) 与 IIS 身份验证集成。如果您已经在 Intranet 中使用 IE 和 IIS，这只会让生活变得更轻松。
注意：不使用它的原因要多得多，而且我在担任现在的职位之前从未使用过它。在这里，一切都已经在 AD 中排列好了……这只是我在数据库安全方面遇到的最简单的时间。
使用集成安全性时，您的应用程序不需要了解或处理任何有关安全性的信息，此外，如果用户已经登录到您的域，他们也不需要登录到您的应用程序（假设您有模拟设置正确）。
最大的优势必须是使用 AD 组作为 SQL Server 中的登录名。通过这种方式，您可以让“帐户”组中的每个人都可以访问一组存储过程、表格等，而“经理”组中的每个人都可以访问不同的集合，所有这些都使用 AD。您的系统管理员无需进入 Management Studio 即可授予用户对您的应用程序的访问权限。
我想这基本上归结为“不重新发明轮子”并利用“多眼”效应。
使用 Windows 身份验证，您可以利用 Windows 集成安全性的强大功能，如果您愿意，您可以在其上添加自己的东西。这是一个已经成熟的系统，已经过数百万次的测试，让您省去自己犯错误并在以后发现/解决错误的努力（以及您的客户的成本）。
然后很多人不断扫描 Windows 身份验证过程，检查漏洞，探索绕过它的方法等。当漏洞被公开披露并创建修复程序时，您的应用程序就获得了“免费”的安全增强.
在我目前的工作中，我们将 AD 组作为 SQL 登录名，因此我们根据 AD 组的成员资格分配 SQL 权限。所以 sys 工程组的所有成员都有一些权限，DBA 有其他，普通用户其他，主管其他等等。添加新用户或更改他们的权限是一件简单的事情，只需在 AD 完成一次，他们立即获得他们应该在数据库中获得的权限。
帖子编辑：
稍微扩展一下“重新发明轮子”：对于一个 AD 帐户，我可以拒绝登录到特定机器的权利 - 或者将其锁定在每台机器之外，除了一两台机器。我可以阻止他们同时登录超过 2 个工作站。我可以强制他们在一段时间后更改密码，并在其中强制执行一些最小强度。还有一些其他技巧，所有这些都提高了我系统的安全性。
对于 SQL S. 用户，您一无所有。我见过有人试图通过复杂的 SQL 作业或某种自制的守护程序来强制执行它们，在我看来，这正在重新发明已经发明的轮子。
然后你不能阻止用户 SA（或特权用户）从任何机器登录。曾经有人告诉我有一种巧妙的方法可以阻止对 SQL S 的暴力攻击，该 SQL S 的端口用于通过 Internet 进行远程登录——该站点的管理员实施了一项工作，每半小时更改一次 SA 的密码。如果是 SQL + Windows，他们可以简单地说他们希望管理员只从某些 boxen 登录，或者直接使用 Windows 身份验证，从而迫使任何人先通过 VPN。
既然其他人都讨论过 Windows 身份验证的好处，我想我会玩 Devil's Advocate ......
允许帐户“Joe User”访问服务器意味着不仅可以连接您的应用程序，而且他还可以通过任何其他方式（SQL 工具、Excel、恶意软件等）连接。
使用 SQL 身份验证，您的应用程序可以作为特定用户运行，然后该应用程序可以处理数据库访问。因此，当“Joe User”运行您的应用程序时，该应用程序具有 SQL 访问权限……但“Joe User”本人没有，这意味着上述应用程序将无法隐式访问数据库。
是的，当然，如果您将应用程序级别的数据访问层作为服务运行，则可以使用集成安全性与使用应用程序“服务帐户”登录到服务器的数据库进行对话......然后你没有；没有将用户密码存储在应用程序配置文件中，并且您不会在每次与数据库建立新连接时通过网络传递密码
集成安全性仅对 Intranet 应用程序真正有用。我见过的伪登录主要用于 Internet Web 应用程序。
无论如何，这不仅仅是不在您的应用程序中存储密码，因为希望您无论如何都会对密码进行加盐和哈希处理。还有：
用户不必登录，这很重要，如果您一整天都偶尔跳入 web 应用程序，或者在有多个内部 web 应用程序的地方工作。
用户管理是免费的，因为 IT 管理员只需在 Active Directory 中编辑用户。
用户名和角色名在整个组织中是一致的。
访问内部 Web 服务时，用户模拟是一种更安全的方法。（例如：一个互联网网站访问一个内部网 web 服务）
Web 应用程序不需要对数据库做任何额外的用户授权，因为它都是无缝处理的。
[编辑] 您还知道数据库对象中的用户。因此，您可以让视图只返回与其关联的行。（除非你为每个app用户创建一个新的SQLServer用户，这是不可能的，为每个app用户创建一个新的SQLServer用户也是不合理的）
集成安全性并不适合所有事情，但对于企业来说，有很多附加值。
SQL 登录：通过线路混淆的明文密码
使用 NTLM 的 Windows 集成登录：通过网络传递的哈希
使用 Kerberos 的 Windows 集成登录：正确的安全身份验证。
如果您关心安全性，则只有一种选择。
根据我的经验，当通过 SQL 身份验证连接时，大多数应用程序对数据库运行的查询的响应时间要快得多。消除因不断要求 AD 进行安全验证而产生的延迟。
性能明智的 SQL 身份验证 >> Windows 集成安全性。
如果使用得当，我认为集成安全性很好。由于某些原因我无法理解，我工作过的很多公司都不太会使用 AD、SQL 权限和 IIS 安全模型。
如果您必须设计 SQL Server 权限系统，并且将其集成到 AD 中的关键要求，您可能会想出非常相似的东西。恕我直言。
我喜欢将用户分组到 AD 组中，然后在 SQL Server 中创建具有各种权限的组登录。人们不应该仅仅因为他们拥有连接到数据库的工具而拥有更多的数据访问权限。无论他们如何连接，他们都应该对数据拥有相同的权限。
根据 IIS 配置的建议，来宾用户（如匿名 Web 用户）应属于他们自己的 AD 组。让这个组只访问他们应该在数据库中访问的内容，有朝一日可以将数据从灾难中拯救出来。很难阅读源代码来确定数据是否受到保护，而调查数据库权限和安全配置要容易得多。
此外，非集成安全性很差，因为密码总是被分发，放入配置文件等。
忽略事物的授权表/等方面，事物的登录方面非常有用，因为您的应用程序可以使用 Windows 身份验证连接到 SQL Server，这意味着
您不必将数据库用户名和密码放在应用程序的某个文件中
每当您将密码放入纯文本文件中时，都会存在安全风险。避免这种情况很棒。
数据库可能具有细粒度的访问权限，每个用户都有许多不同的设置。这不仅是您只有一个用户可以访问应用程序的情况，而且是所有数据安全性。
如果我们谈论的是团队开发，那么可能会有用户组被授予对数据库的开发访问权限。该组中的每个用户都将是您的内部域的成员，并且拥有自己的密码，数据库管理员不应该管理甚至知道允许访问数据库。
集成的安全性为用户访问 IMO 提供了更大的灵活性。例如，如果我的组织想要限制开发人员组可以访问服务器的时间，那么集成安全性是我最好的选择。
但这并不适合所有事情。
[编辑] 它也非常适合记录访问。如果我必须为大型组织中的每个新开发人员创建一个 SQL 登录名......它可能会停止发生并且登录名会被共享，那么我永远不会有能力将手指指向掉下一个傻瓜的能力桌子。
如果您使用 sql server 身份验证，密码信息会以明文形式通过网络发送。集成安全没有这个问题。
对于将在 AD 环境中运行的企业应用程序，使用 Windows 集成安全性绝对是正确的方法。您不希望已经在环境中通过身份验证的用户必须为您的应用管理一组单独的凭据。请注意，我们正在谈论身份验证......对于授权，您仍将使用 SQL Server 基于角色的安全性。