sys.sql_logins.is_policy_checked是否意味着已对策略进行了检查？

Question

当我查看sys.sql_logins时，我看到了一个名为is_policy_checked的列。我是否可以相信，对于列值为1的所有登录，都已检查了我的密码策略？

Answer 1

##No。虽然文献资料目前对此标志的含义有以下含糊的说明：

检查密码策略。

它真正意味着，而且应该说，国旗有两个目的：

1. 密码策略可能已被选中，但前提是(a)在上次设置密码时启用了密码策略，以及(b)密码是以纯文本(而不是使用散列)指定的。2.密码策略将在下一次设置策略时进行检查，但前提是：(a)当时启用了密码策略，(b)密码是用纯文本(而不是哈希)指定的。

(请注意，“策略”还指强制过期和用户在下一次登录时必须更改密码的事实，但由于复杂性通常是审计操作的重点，我将只关注这个方面。)

is_policy_checked位在CREATE LOGIN或ALTER LOGIN事件期间被设置为1 if CHECK_POLICY = ON，即使当时没有检查策略。正如您可能从上面收集到的那样，这种检查不会在以下情况中发生：

• 密码是使用HASHED关键字指定的(在服务器之间迁移登录或将登录复制到日志发送/镜像/ AG次要文件时，这是一种非常常见的策略)。如果您没有预散列值，显然不可能检查密码的复杂性。
• 事件发生时未启用本地密码复杂性策略。
• 上面我建议的重措辞中没有提到，但是您可以在不设置新密码的情况下进行ALTER LOGIN，并且仍然可以更改标志(感谢@AMtwo给出了这个例子)。我怀疑这可能是聪明的人在愚弄审计师。

这些问题都很容易证明。

由于我所讨论过的大多数人总是认为is_policy_checked实际上意味着当前的密码符合当前的密码策略，所以我认为重要的是在这里进行一些更改，以便使用户有正确的期望，并理解这个标志并不一定意味着一切都好。至少应该更新这些文件，以反映实际情况，就像我前面指出的那样。但也有其他的事情可以做。

• 如果指定了CHECK_POLICY = ON，但实际上无法检查策略，则可能会引发警告(因为密码是用哈希指定的，或者因为密码策略已被禁用，或者因为该命令只是绕过或设置标志的简单尝试，例如ALTER LOGIN blat WITH CHECK_POLICY = ON;)。
• 可以反对CHECK_POLICY，而支持ACTIVELY_CHECK_POLICY和CHECK_POLICY_ON_NEXT_CHANGE。sys.sql_logins中的列应该是policy_has_been_checked和policy_will_be_checked。我没有嫁给这些名字，但它们比目前的措辞准确得多。
• 如果选择ACTIVELY_CHECK_POLICY = ON，并且在执行命令时无法检查策略，则应该收到错误消息，并且不应将标志设置为1 (甚至登录创建或密码更改也不会成功)。
• 在这种情况下，我认为继续当前的行为是没有意义的，在这种情况下，我可以指定要检查策略，但即使不能检查，也允许密码并创建/更改登录(这是错误的，IMHO，不管事实之后标志的状态如何，但至少如果设置为0，就可以识别这种旁路)。

今天，没有可靠的方法--如果不手动将他们的密码更改为您知道是安全的--来审核您的SQL登录并确信它们都符合您的复杂性策略。在这个数据不断增加的时代，越来越多的数据被破坏，而且显然需要更加严格地保护系统，这是一个需要解决的问题。我在博客上写了这篇文章，并创建了一个连接条目：

• 请帮我解决一个很大的安全漏洞
• 检查_策略是禁止使用CREATE登录。密码...散列

我鼓励您对Connect项目进行投票，更重要的是，确保您不会对DDL选项和元数据的工作方式有错误的认识。

请不要把这看作是一个“非问题”，因为你对它的工作方式非常满意，并且已经知道这个标志不能被信任--你不是我担心的用户，而是其他人。