sys.sql_logins.is_policy_checked是否表示已检查策略？

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

没有。

尽管文档当前对这个标志的含义有以下可能是模棱两可的陈述：

密码策略已检查。

它的真正含义并应该说的是，该标志有两个作用：

1. 可能已经检查了密码策略，但是只有在（a）上一次设置密码时启用了密码策略，并且（b）用纯文本（不带哈希）指定了密码，才可以。
2. 下次设置密码策略时，将检查密码策略，但前提是（a）当时启用了密码策略，并且（b）密码以纯文本指定（不带哈希）。

（并且请注意，“策略”还指强制到期，以及用户必须在下次登录时更改密码的事实，但是由于复杂性通常是审核操作的重点，因此，我将仅关注该方面。 ）

该is_policy_checked位被设置为1，如果CHECK_POLICY = ON在一个CREATE LOGIN或ALTER LOGIN事件，即使政策不当时检查。正如您可能从上面收集的那样，在以下情况下不会进行此检查：

• 密码是使用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（甚至不能成功创建登录名或更改密码）。
• 在这种情况下，我认为继续当前的行为是没有意义的，在这里我可以指定要检查的策略，但是即使不能，也允许密码并且创建/更改登录名（恕我直言，这很糟糕，无论事实之后的标志状态如何-但至少如果将其设置为0，则可以识别此类绕过）。

如今，没有可靠的方法-无需手动将其密码更改为您认为安全的密码-即可审计您的SQL登录并确信它们都符合您的复杂性策略。在当今不断增长的数据，越来越多的数据泄露以及当今越来越需要保护系统越来越紧密的当今时代，这是一个需要解决的问题。我已经对此发表了博客，并为此创建了一个Connect项目：

• 请帮我解决一个很大的安全漏洞
• 连接＃1250342：CHECK_POLICY是禁止操作，带有CREATE LOGIN ... PASSWORD ... HASHED

我鼓励您对“连接”项进行投票，更重要的是，请确保不要对DDL选项和元数据的工作原理有错误的认识，从而对系统进行审核。

请不要把它当作“非问题”放在一边，因为您对它的工作方式非常满意，并且已经知道该标志是不可信任的-您不是我担心的用户；是其他人。