我使用SQL Server已经很多年了，回到Sybase SQL Server时代，在登录和用户方面一直存在混乱。尽管它们通常使用相同的名称，但它们是独立的对象。SQL Server的新手似乎总是混淆这两者。让我们看一看…
我发现将SQL Server想象成一座堡垒是很有用的。毕竟，这是在保护你的宝贵数据，所以这个类比并不坏。如果您的数据被泄露，这可能是一个“简历生成事件”，因此，如果没有其他问题，请注意安全！要通过我们堡垒的前门，每个人都需要登录。登录是身份验证的对象，证明您是谁。SQL Server支持Windows身份验证（也称为“受信任”）和SQL Server身份验证（“不受信任”-听起来不太好，是吗？出于这个原因，我们也将其称为“标准”）。Windows身份验证的好处在于，SQL Server信任Windows令牌，并且在提供SSO（单点登录）解决方案时不必重新输入密码。但是，如果无法保证客户端的Windows，则需要使用标准登录。
Windows登录的另一个优点是对Kerberos身份验证协议的额外安全支持，提供相互身份验证。这意味着服务器和客户机都要经过身份验证。它可以保护非法服务器和非法客户端。Windows身份验证还将通过Active Directory或Local安全策略附带Windows密码策略。这将强制在预定义的时间之后更改密码，强制复杂度要求，并在锁定登录之前建立密码尝试的最大阈值。现在，从SQL Server 2005开始，标准登录将可选地遵循在服务器上生效的Windows密码策略。以前，我们必须在应用程序中开发自己的密码策略代码。
创建Windows登录时，我们可以将其映射到特定的Windows用户帐户（不要与SQL Server数据库用户帐户混淆；这里是混淆的起点…），但通常我们使用Windows组。这意味着这些组的成员资格必须由您的Windows网络管理员维护（希望不是您！），因此，无论何时有人离开或加入某个部门，作为SQL Server DBA，您都可以坐得很好。假设在一个名为Accounting的组中有1000名Windows用户。要为这1000名Windows用户启用对SQL Server的访问，需要基于记帐组的单个Windows登录。然而，假设会计组中有一个叫Eddie的Windows用户，你不信任他？简单：只需为Eddie创建Windows登录并指定拒绝访问。Eddie将从会计登录中授予访问权限，并从自己的登录中拒绝访问；因为拒绝总是胜过给予，他将被拒绝。
好的，仅仅因为你可以通过我们堡垒的前门并不意味着你可以在任何房间里做任何事情。我们的SQL Server堡垒的房间称为数据库，您需要为每个需要访问的数据库设置一个数据库用户帐户。数据库用户帐户映射到单个登录，通常称为相同的名称，因此很容易混淆为同一对象。从技术上讲，登录被映射到一个或多个数据库用户帐户。正是数据库用户帐户允许我们将权限应用于“安全性”，例如模式、表格和视图。我们可以将具有类似安全要求的多个数据库用户帐户组合到数据库角色中。我们轻率地将数据库用户帐户称为“用户”，但这会造成很大的混乱，因为Windows用户帐户也称为用户，但完全不同。
我们使用数据库角色的原因与使用Windows组的原因相同：简化安全管理。将权限应用于每个数据库用户帐户比应用于具有有意义名称的数据库角色要困难得多。我们还可以访问服务器角色，在这些角色中，我们可以将登录分组，以进行服务器范围的访问。
在所有这些术语混乱的情况下，如果SQL Server团队偶尔与Active Directory人员共进午餐不是很好吗？我知道微软校园现在有100多栋建筑，但仍然…
干杯
布瑞恩
最近的员额：