logo标签列表

SQL Server身份验证与Windows身份验证有何不同？

sql-server
44

什么是SQL Server身份验证和Windows身份验证之间的区别？

每种身份验证类型是否有特定的用例？

10个回答
26

SQL Server内置了自己的安全系统，包括登录和角色。这与Windows用户和组是分开且并行的。您可以仅使用SQL安全性，然后所有管理都将在SQL服务器内进行，并且这些登录和Windows用户之间没有连接。如果使用混合模式，则Windows用户被视为SQL登录。

每种方法都有一些特点 -

  1. 如果要使用连接池，则必须使用SQL登录，或者所有用户共享同一个Windows用户-这不是一个好主意。

  2. 如果要跟踪特定用户的操作，则使用Windows身份验证是有意义的。

  3. 使用Windows工具来管理用户比使用SQL更强大，但两者之间的链接不可靠，例如，如果删除Windows用户，则SQL中相关的数据不会更新。

2
如果它们是服务（或 Web 服务），并且您仍然为个人用户获得了好处，那么对于连接池使用相同的 Windows 用户不是一个坏主意（但您将在更多的池中拥有更多的连接）。 - Brody
19

SQL身份验证

SQL身份验证是各种数据库系统中通常使用的身份验证方式，由用户名和密码组成。显然，一个SQL Server实例可以有多个这样的用户帐户（使用SQL身份验证），具有不同的用户名和密码。在共享服务器中，不同的用户应该访问不同的数据库，应该使用SQL身份验证。此外，当客户端（远程计算机）连接到运行SQL Server的计算机以外的计算机的SQL Server实例时，需要使用SQL Server身份验证。即使您没有定义任何SQL Server用户帐户，在安装时会添加一个根帐户-sa，其密码为您提供的密码。就像任何SQL Server帐户一样，这可以用于本地或远程登录，但如果应用程序是进行登录的应用程序，并且它只能访问一个数据库，则强烈建议您不要使用sa帐户，而是创建一个具有有限访问权限的新帐户。总的来说，SQL身份验证是主要要使用的身份验证方法，而下面我们要介绍的Windows身份验证则更多的是一种方便。

Windows身份验证

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

您还可以使用Windows身份验证而无需提供用户名和密码（因此SQL Server Management Studio使用启动应用程序的用户）来连接远程SQL Server。 - Camille G.
@Camille G，如果您使用SQL身份验证进行身份验证，是否允许您访问系统中的任何数据库？ - MSIS
1
@MSIS 这取决于情况！SQL用户必须对每个数据库具有一定的访问权限，但如果该用户拥有某些特殊权限（如sysadmin），则可能可以访问每个数据库。 - Camille G.
4
当授权用户访问数据库时，需要考虑一些因素，其中包括可用性和安全性的优缺点。我们有两种选择来对用户进行认证和授权。第一种方法是通过给每个人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服务器的每个实例。这很耗时且不安全，留下了被解雇的用户仍然可以访问SQL Server的可能性。使用Windows方法则不存在这些问题。一切都集中处理并由AD处理。
仅使用SQL方法的优点在于其灵活性。您可以从任何操作系统和网络甚至远程访问它。一些旧的遗留系统以及一些基于Web的应用程序可能仅支持sa访问。
AD方法还提供了时间节省工具，例如组，以使添加和删除用户更容易，并提供用户跟踪功能。

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

4

理想情况下，在企业内部网络环境中应使用Windows身份验证。

而在其他类型的情况下，可以使用SQL Server身份验证。

这里有一个链接可能会有所帮助。

Windows身份验证 vs. SQL Server身份验证

3
如果您希望对用户进行身份验证并针对Windows系统用户[由管理员创建]，那么您将选择在应用程序中使用Windows身份验证。但是，如果您想对用户进行身份验证并针对应用程序数据库中的一组可用用户，则您需要选择SQL身份验证。
精确地说，如果您的应用程序是ASP.NET Web应用程序，则可以使用标准的登录控件，这些控件依赖于提供程序，例如SqlMembershipProvider、SqlProfileProvider。您可以配置登录控件和应用程序，以确定它是应该针对Windows用户还是应用程序数据库用户进行身份验证。在前一种情况下，它将被称为Windows身份验证，而在后一种情况下，它将被称为SQL身份验证。
嘿，你看起来有点年轻，使用“域基础架构”这样的术语，我应该担心即将到来的一代吗？ :-) - paxdiablo
嗨Pax，我同意那不是正确的词。我会用适当的注释进行编辑。感谢您的评论。 - this. __curious_geek
2
我对SQLServer不像其他数据库管理系统那样熟悉，但我想好处与DB2和Oracle相同。如果您使用Windows身份验证，则只需维护一个用户和/或密码集，即Windows的用户和/或密码集，这已经为您完成了。
DBMS身份验证意味着必须维护一个单独的用户和/或密码集。
此外，Windows密码允许它们在企业中（活动目录）进行集中配置，而SQLServer必须为每个DBMS实例维护一个集合。
1

SQL Server身份验证模式

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

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

混合身份验证允许使用Windows凭据，但同时补充了本地SQL Server用户帐户，管理员可以在SQL Server中创建和维护这些帐户。

1

认证是确认用户或计算机身份的过程。该过程通常包括四个步骤： 用户提供身份声明，通常通过提供用户名来实现。例如，我可以通过告诉数据库我的用户名是“mchapple”来进行此声明。 系统向用户发出挑战以证明其身份。最常见的挑战是请求输入密码。 用户通过提供所需的证据来回应挑战。在这个例子中，我会向数据库提供我的密码。 系统通过检查本地密码数据库或使用集中式认证服务器等方式验证用户是否已经提供了可接受的证据。

1

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

Windows身份验证是指身份作为Windows握手的一部分来处理，没有密码被拦截。

SQL身份验证意味着您必须自己存储（或提供）用户名和密码，这使得攻击变得容易得多。已经花费了大量精力使Windows身份验证非常强大和安全。

我建议如果您实施Windows身份验证，请使用组和角色进行管理。在Windows中使用组，在SQL中使用角色。在SQL中设置大量用户非常麻烦，而您可以只设置组并将每个用户添加到该组中。(我认为大多数安全性都应该以这种方式完成)。

0

如果可能的话，强烈建议使用Mssql身份验证。它允许您符合工作场所已经使用的现有Windows域，并且您不必知道用户的密码。

然而，如果服务器的机器没有通过本地工作场所的内部网络进行身份验证，则似乎无法使用。

如果您使用SQL身份验证，则安全性完全由您负责。

如果您使用Microsoft身份验证，则安全性基本上已经为您处理好了，但您将面临额外的限制。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接