sql server身份验证和Windows身份验证之间有什么区别...是否有使用每种身份验证的具体情况？
答案 0 :(得分：24)
SQL Server有自己的内置安全系统，涵盖登录和角色。这与Windows用户和组分开且并行。您可以只使用SQL安全性，然后所有管理都将在SQL Server中进行，并且这些登录和Windows用户之间没有任何关联。如果您使用混合模式，则Windows用户将被视为SQL登录。
每种方法都有许多功能 -
1）如果你想使用连接池，你必须使用SQL登录，或者所有人共享相同的windows用户 - 不是一个好主意。
2）如果您想跟踪特定用户的行为，那么使用Windows身份验证是有意义的。
3）使用Windows工具管理用户比SQL强大得多，但两者之间的链接很脆弱，例如，如果删除Windows用户，则SQL中的相关数据不会更新。
答案 1 :(得分：16)
SQL身份验证
SQL身份验证是用于各种数据库系统的典型身份验证，由用户名和密码组成。显然，SQL Server的一个实例可以有多个这样的用户帐户（使用SQL身份验证），具有不同的用户名和密码。在不同用户应该可以访问不同数据库的共享服务器中，应该使用SQL身份验证。此外，当客户端（远程计算机）连接到运行客户端的计算机之外的其他计算机上的SQL Server实例时，需要SQL Server身份验证。即使您没有定义任何SQL Server用户帐户，在安装时也会使用您提供的密码添加root帐户sa。就像任何SQL Server帐户一样，这可以用于登录localy或远程，但是如果应用程序是进行登录的应用程序，并且它应该只能访问一个数据库，强烈建议您不要使用sa帐户，但创建一个访问受限的新帐户。总的来说，SQL身份验证是要使用的主要身份验证方法，而我们在下面查看的身份验证方法 - Windows身份验证 - 更方便。
Windows身份验证
当您从安装的同一台计算机访问SQL Server时，不应提示您输入用户名和密码。如果您使用的是Windows身份验证，那么您就不是。使用Windows身份验证，SQL Server服务已经知道有人使用正确的凭据登录到操作系统，并且它使用这些凭据允许用户进入其数据库。当然，只要客户端与SQL Server位于同一台计算机上，或者只要连接客户端与服务器的Windows凭据匹配，就可以正常工作。 Windows身份验证通常用作登录SQL Server实例而不键入用户名和密码的更方便的方法，但是当涉及更多用户或使用SQL Server建立远程连接时，应使用SQL身份验证。
答案 2 :(得分：4)
理想情况下，在Intranet类型的环境中工作时，必须使用Windows身份验证。
然而，SQL Server身份验证可用于所有其他类型的情况。
这是一个可能有用的链接。
答案 3 :(得分：3)
如果您希望针对[由管理员创建]的Windows系统用户对用户进行身份验证，那么在这种情况下，您将在应用程序中进行Windows身份验证。
但是如果您想根据应用程序数据库中可用的用户集对用户进行身份验证，那么在这种情况下，您将需要进行SQL身份验证。
确切地说，如果您的应用程序是ASP.NET Web应用程序，那么您可以使用依赖于SqlMembershipProvider，SqlProfileProvider等提供程序的标准Login控件。您可以配置登录控件和应用程序是否应对Windows用户或应用程序数据库用户进行身份验证。在第一种情况下，它将被称为Windows身份验证，后者将被称为Sql身份验证。
答案 4 :(得分：2)
我不了解SQLServer以及其他DBMS，但我认为其好处与DB2和Oracle相同。如果您使用Windows身份验证，则只需维护一组Windows用户和/或密码，这些用户和/或密码已经为您完成。
DBMS身份验证意味着必须维护一组单独的用户和/或密码。
此外，Windows密码允许为企业集中配置它们（Active Directory），而SQLServer必须为每个DBMS实例维护一个集合。
答案 5 :(得分：2)
在授予用户访问数据库权限时，在可用性和安全性方面需要考虑一些优点和缺点。在这里，我们有两个选项来验证和授予用户权限。第一种方法是为每个人提供sa（系统管理员）帐户访问权限，然后通过保留可根据需要授予或拒绝权限的用户列表来手动限制权限。这也称为SQL身份验证方法。这种方法存在重大安全漏洞，如下所示。第二个也是更好的选择是让Active Directory（AD）处理所有必要的身份验证和授权，也称为Windows身份验证。用户登录到他们的计算机后，应用程序将使用操作系统上的Windows登录凭据连接到数据库。
使用SQL选项的主要安全问题是它违反了最小特权（POLP）原则，即只向用户提供他们需要的绝对必要权限，而不是更多。通过使用sa帐户，您会出现严重的安全漏洞。违反了POLP，因为当应用程序使用sa帐户时，他们可以访问整个数据库服务器。另一方面，Windows身份验证遵循POLP，只允许访问服务器上的一个数据库。
第二个问题是应用程序的每个实例都不需要拥有管理员密码。这意味着任何应用程序都是整个服务器的潜在攻击点。 Windows仅使用Windows凭据登录SQL Server。 Windows密码存储在存储库中，而不是SQL数据库实例本身，并且身份验证在Windows内部进行，而无需在应用程序上存储sa密码。
使用SQL方法涉及密码会产生第三个安全问题。如Microsoft网站和各种安全论坛所示，SQL方法不会强制更改密码或加密，而是通过网络以明文形式发送。并且SQL方法在尝试失败后不会锁定，因此允许长时间尝试中断。然而，Active Directory使用Kerberos协议加密密码，同时使用密码更改系统并在尝试失败后锁定。
也有效率缺点。由于您每次要访问数据库时都要求用户输入凭据，因此用户可能会忘记其凭据。
如果要删除用户，则必须从应用程序的每个实例中删除其凭据。如果必须更新sa管理员密码，则必须更新SQL Server的每个实例。这是耗时且不安全的，它留下了被解雇的用户保留对SQL Server的访问权的可能性。使用Windows方法，不会出现这些问题。一切都由AD集中处理。
使用SQL方法的唯一好处在于其灵活性。您可以从任何操作系统和网络访问它，甚至可以远程访问它。一些较旧的遗留系统以及一些基于Web的应用程序可能仅支持sa访问。
AD方法还提供节省时间的工具，例如群组，以便更轻松地添加和删除用户，以及用户跟踪功能。
即使你设法纠正SQL方法中的这些安全漏洞，你也会重新发明轮子。在考虑Windows身份验证提供的安全优势（包括密码策略和遵循POLP）时，它是一种比SQL身份验证更好的选择。因此，强烈建议使用Windows身份验证选项。
答案 6 :(得分：1)
我认为主要区别在于安全性。
Windows身份验证意味着身份将作为Windows handashaking的一部分进行处理，现在密码永远都会“拦截”。
SQL身份验证意味着您必须自己存储（或提供）用户名和密码，以便更容易破解。为了使Windows身份验证非常强大和安全，已经付出了大量的努力。
我可能会建议您实施Windows身份验证时使用组和角色来执行此操作。 Windows中的组和SQL中的角色。当您只需设置组然后将每个用户添加到组中时，必须在SQL中设置大量用户是一件非常痛苦的事。 （我认为大多数安全应该以这种方式完成）。
答案 7 :(得分：1)
SQL Server身份验证模式
SQL Server 2008提供两种身份验证模式选项：
Windows身份验证模式要求用户提供有效的Windows用户名和密码才能访问数据库服务器。在企业环境中，这些凭据通常是Active Directory域凭据。
混合身份验证模式允许使用Windows凭据，但使用管理员可在SQL Server中创建和维护的本地SQL Server用户帐户对其进行补充。
答案 8 :(得分：1)
身份验证是确认用户或计算机身份的过程。该过程通常包括四个步骤： 用户通常通过提供用户名来声明身份。例如，我可以通过告诉数据库我的用户名是“mchapple”来提出此声明。 该系统向用户提出挑战以证明他或她的身份。最常见的挑战是请求密码。 用户通过提供所请求的证据来响应挑战。在这个例子中，我将为数据库提供我的密码 系统验证用户是否提供了可接受的证据，例如，根据本地密码数据库或使用集中验证服务器检查密码
答案 9 :(得分：0)
Mssql身份验证在可能的情况下是非常优选的。它允许您符合您工作场所已经使用的现有Windows域，并且您不必知道用户的密码。
但是，似乎无法在服务器的计算机 对您本地工作区的Intranet进行身份验证时使用。
如果您使用sql身份验证，安全性将完全取决于您。
如果您使用Microsoft身份验证，安全性基本上是为您处理的，但您将处理其他限制。