sql服务器身份验证和Windows身份验证之间有什么区别？

Question

sql server身份验证和windows身份验证有什么区别...有没有使用每个身份验证的具体情况？

Answer 1

理想情况下，在Intranet类型的环境中工作时，必须使用Windows身份验证。

而SQL Server身份验证可以用于所有其他类型的情况。

这是一个可能有帮助的链接。

Windows Authentication vs. SQL Server Authentication

Answer 2

我不知道的SQLServer，以及其他DBMS”，但我想象中的一样，有利于与DB2和Oracle。如果您使用Windows身份验证，则只需维护一组用户和/或密码，即Windows已为您完成的一组用户和/或密码。

DBMS认证意味着拥有一组必须维护的用户和/或密码。

此外，Windows密码让他们集中为企业（活动目录）配置的，而SQLServer的具有维护每个DBMS例如一组。

Answer 3

如果你想验证针对Windows系统的用户的用户[由管理员创建]，然后在这种情况下，你会在你的应用程序去为Windows身份验证。

，但如果你希望用户对设置在应用程序数据库中可用的用户进行身份验证，那么在这种情况下，你会想要去的SQL身份验证。

准确地说，如果你的应用程序是一个ASP.NET web应用程序，那么你可以使用依赖于像SqlMembershipProvider的，供应商的SqlProfileProvider标准Login控件。您可以配置登录控件和应用程序，以确定它是否应该针对Windows用户或应用程序数据库用户进行身份验证。在第一种情况下，它将被称为Windows身份验证，后者将被称为Sql身份验证。

Answer 4

SQL Server拥有自己的内置系统，用于涵盖登录和角色的安全性。这与Windows用户和组是分开的并且平行的。您只能使用SQL安全性，然后所有管理都将发生在SQL Server中，并且这些登录和Windows用户之间没有任何关联。如果你使用混合模式，那么Windows用户就像SQL登录一样对待。

有许多的每一种方法的特点 -

1）如果你想使用连接池，你必须使用SQL登录，或全部共享相同的Windows用户 - 不是一个好主意。

2）如果你想跟踪哪些特定的用户在做什么，然后使用Windows身份验证是有道理的。

3）使用Windows工具来管理用户比SQL更强大，但是两者之间的联系是微不足道的，例如，如果您删除了Windows用户，那么SQL中的相关数据不会更新。

Answer 5

我认为主要的区别是安全性。

Windows认证意味着该标识被作为Windows handashaking的一部分进行处理，现在密码是有史以来“那里”的拦截。

SQL身份验证意味着您必须自己存储（或提供）用户名和密码，以便更容易违反。一大堆努力使得Windows身份验证非常健壮和安全。

我可以建议，如果您确实使用Windows身份验证，请使用组和角色来执行此操作。 Windows中的组和SQL中的角色。如果您只需设置组，然后将每个用户添加到组中，就必须在SQL中设置大量用户，这是一个很大的麻烦。 （我认为大多数安全性应该以这种方式完成）。

Answer 6

SQL验证

SQL认证是用于各种数据库系统的一个典型的验证，用户名和密码组成。很显然，SQL Server的一个实例可以拥有多个这样的用户帐户（使用SQL认证）和不同的用户名和密码。在不同用户可以访问不同数据库的共享服务器中，应使用SQL身份验证。另外，当客户端（远程计算机）连接到运行客户端的计算机之外的其他计算机上的SQL Server实例时，需要SQL Server身份验证。即使您没有定义任何SQL Server用户帐户，在安装时，root帐户sa也会添加您提供的密码。就像任何SQL Server帐户一样，这可以用于本地或远程登录，但是如果应用程序是登录的应用程序，并且应该只能访问一个数据库，那么强烈建议您不要使用sa帐户，但创建一个访问受限的新帐户。总体而言，SQL身份验证是使用的主要身份验证方法，而我们在下面评估的方法 - Windows身份验证 - 则更方便。

Windows身份验证

当你从它被安装在同一台计算机访问SQL Server，您应该不会提示输入一个用户名和密码。如果您使用Windows身份验证，则不是。通过Windows身份验证，SQL Server服务已经知道有人使用正确的凭据登录到操作系统，并且它使用这些凭据来允许用户进入其数据库。当然，只要客户端与SQL Server位于同一台计算机上，或者只要连接的客户端与服务器的Windows凭据匹配，就可以工作。 Windows身份验证通常用作登录到SQL Server实例而不键入用户名和密码的更方便的方式，但是，当包含更多用户或正在与SQL Server建立远程连接时，应使用SQL身份验证。

Answer 7

SQL Server身份验证模式

的SQL Server 2008提供两种身份验证模式选项：

Windows身份验证模式要求用户提供有效的Windows用户名和密码来访问数据库服务器。在企业环境中，这些凭据通常是Active Directory域凭据。

混合身份验证模式允许使用Windows凭据，但可以使用管理员可以在SQL Server中创建和维护的本地SQL Server用户帐户进行补充。

Answer 8

认证是确认用户或计算机身份的过程。该过程通常由四个步骤组成： 用户通常通过提供用户名来声明身份。例如，我可以通过告诉数据库我的用户名是“mchapple”来做出这个声明。 该系统挑战用户证明他或她的身份。最常见的挑战是请求密码。 用户通过提供请求的证据来回应挑战。在这个例子中，我将向数据库提供我的密码 系统验证用户是否已通过例如根据本地密码数据库或使用集中认证服务器检查密码来提供可接受的证据

Answer 9

授予用户访问数据库有几个需要考虑的可用性和安全性方面的优点和缺点。这里我们有两个选项来验证和授予用户权限。第一种方法是给每个人sa（系统管理员）帐户访问权限，然后通过保留可根据需要授予或拒绝权限的用户列表来手动限制权限。这也被称为SQL认证方法。这种方法存在主要的安全缺陷，如下所列。第二个更好的选择是让Active Directory（AD）处理所有必要的身份验证和授权，也称为Windows身份验证。用户登录到其计算机后，应用程序将使用操作系统上的Windows登录凭据连接到数据库。

使用SQL选项的主要安全问题是它违反了最小权限（POLP）的原则，即只向用户提供他们需要的绝对必要的权限，而不再需要。通过使用sa帐户，您会出现严重的安全漏洞。 POLP被违反，因为当应用程序使用sa帐户时，他们可以访问整个数据库服务器。另一方面，Windows身份验证通过仅授予对服务器上的一个数据库的访问权限来遵循POLP。

第二个问题是，没有必要让每个应用程序实例都有管理员密码。这意味着任何应用程序都是整个服务器的潜在攻击点。 Windows仅使用Windows凭据登录到SQL Server。 Windows密码存储在存储库中，与SQL数据库实例本身不同，身份验证发生在Windows内部，无需在应用程序中存储密码。

使用SQL方法引发的第三个安全问题涉及密码。正如Microsoft网站和各种安全论坛所介绍的，SQL方法不会“强制执行密码更改或加密，而是通过网络以明文形式发送。并且SQL方法在失败尝试后不会锁定，因此允许长时间尝试打入。然而，Active Directory使用Kerberos协议来加密密码，同时也使用密码更改系统并在尝试失败后锁定。

也有效率缺点。由于您将要求用户在每次访问数据库时都输入凭据，因此用户可能会忘记其凭据。

如果用户被删除，您将不得不从应用程序的每个实例中删除他的凭据。如果您必须更新sa管理员密码，则必须更新每个SQL Server实例。这是非常耗时且不安全的，它使得被解雇的用户可以保留对SQL Server的访问权限。使用Windows方法不会出现这些问题。一切都由AD集中处理。

使用SQL方法的唯一好处在于它的灵活性。您可以从任何操作系统和网络访问它，甚至可以远程访问它。一些较旧的遗留系统以及一些基于网络的应用程序可能只支持sa访问。

AD方法还提供了诸如组的省时工具，使其更容易添加和删除用户以及用户跟踪能力。

即使您设法纠正SQL方法中的这些安全漏洞，您也会重新发明轮子。在考虑Windows身份验证提供的安全优势（包括密码策略和POLP后）时，它是比SQL身份验证更好的选择。因此强烈建议使用Windows身份验证选项。

Answer 10

尽可能使用Mssql身份验证。它允许您符合您工作场所已经使用的现有Windows域，而且您不必知道用户的密码。

但是，在服务器的机器没有验证到您的本地工作区的Intranet时，似乎不可能使用该服务器的机器。

如果您使用sql认证，安全将完全取决于您。

如果您使用微软身份验证，安全性基本上为您负责，但您将处理其他限制。