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