本部分提供有关 Microsoft Entra 密码保护的许多常见问题的解答。
一般问题
在如何选择安全密码方面，你们为用户提供了哪些指导？
在以下链接中可以找到 Microsoft 当前为此主题提供的指导：
非公有云是否支持本地 Microsoft Entra 密码保护？
Azure 全球云和 Azure 政府云都支持本地 Microsoft Entra 密码保护。
Microsoft Entra 管理中心允许在不受支持的云中修改特定于本地的“Windows Server Active Directory 的密码保护”配置。此类更改将持久保存，但从不生效。 不支持在不受支持的云中注册本地代理或林，任何此类注册尝试都会失败。
如何将 Microsoft Entra 密码保护权益应用到我的一部分本地用户？
不支持。 一旦部署并启用，Microsoft Entra 密码保护就会平等适用于所有用户。
密码更改和密码设置（或重置）之间的区别是什么？
密码更改是指用户在证明其知道旧密码后选择一个新密码。 例如，密码更改会在用户登录到 Windows 时执行，然后系统会提示选择一个新密码。
密码设置（有时称为密码重置）是管理员例如通过使用 Active Directory 用户和计算机管理工具将帐户的密码替换为新密码。 此操作需要高级别的权限（通常是域管理员），并且执行该操作的人通常不知道旧密码。 支持人员方案通常会在特定的时候（例如在协助忘记密码的用户时）执行密码设置。 首次使用密码创建全新用户帐户时，也会看到密码设置事件。
不管密码是否已更改或已设置，密码验证策略的行为都是相同的。 Microsoft Entra 密码保护 DC 代理服务会记录不同的事件，以通知你是否已完成密码更改或设置操作。 请参阅 Microsoft Entra 密码保护监视和日志记录。
Microsoft Entra 密码保护安装后是否会验证现有密码？
不会。Microsoft Entra 密码保护只能在密码更改或设置操作期间对明文密码强制执行密码策略。 Active Directory 接受密码后，只保留该密码的特定于身份验证协议的哈希。 永远不会保留明文密码，因此 Microsoft Entra 密码保护无法验证现有密码。
初始部署 Microsoft Entra 密码保护之后，所有用户和帐户最终将开始使用 Microsoft Entra 密码保护验证的密码，因为其现有密码会在一段时间后过期。 你可以根据需要通过对用户帐户密码执行一次性手动过期操作来加速此过程。
除非执行手动过期操作，否则配置为“密码永不过期”的帐户不会被强制更改其密码。
为什么在尝试使用（Active Directory 用户和计算机管理）管理单元尝试设置弱密码时记录重复的密码拒绝事件？
“Active Directory 用户和计算机管理”管理单元首先尝试使用 Kerberos 协议设置新密码。 失败时，管理单元会再次尝试使用旧版 (SAM RPC) 协议设置密码。 所使用的具体协议并不重要。 如果 Microsoft Entra 密码保护将新密码视为弱密码，则此管理单元行为会生成两组密码重置拒绝事件，这些事件会被记录下来。
为什么使用空用户名记录 Microsoft Entra 密码保护密码验证事件？
Active Directory 支持测试密码以查看其是否通过了域的当前密码复杂性要求（例如，使用 NetValidatePasswordPolicy api）的功能。 以这种方式验证密码时，测试还包括通过基于密码筛选器 dll 的产品（如 Microsoft Entra 密码保护）进行的验证，但传递到给定密码筛选器 dll 的用户名为空。 在此方案中，Microsoft Entra 密码保护仍使用当前生效的密码策略来验证密码，并发出事件日志消息来捕获结果。 但是，事件日志消息将包含空的用户名字段。
我的一些混合用户尝试更改 Microsoft Entra ID 中的密码时收到响应“我们之前已经多次看到该密码。 请选择更难以猜中的密码。”在这种情况下，为什么我在本地看不到验证尝试？
当混合用户在 Microsoft Entra ID 中更改密码时，无论是通过 Microsoft Entra SSPR、MyAccount 还是其他 Microsoft Entra 密码更改机制，系统都会根据云中的全局和自定义禁止密码列表来评估其密码。 密码通过密码写回到达 Active Directory 时，已在 Microsoft Entra ID 中经过验证。
在 Microsoft Entra ID 中发起的、混合用户验证失败的密码重置和更改可以在 Microsoft Entra 审核日志中找到。 请参阅排查 Microsoft Entra ID 中的自助式密码重置问题。
是否支持与其他基于密码筛选器的产品一同安装 Microsoft Entra 密码保护？
是的。 支持多个已注册的密码筛选器 dll 是一项 Windows 核心功能，并不特定于 Microsoft Entra 密码保护。 在接受密码之前，所有已注册的密码筛选器 dll 必须同意。
在不使用 Azure 的情况下，如何在 Active Directory 环境中部署和配置 Microsoft Entra 密码保护？
不支持。 Microsoft Entra 密码保护是旨在扩展到本地 Active Directory 环境中的一项 Azure 功能。
如何在 Active Directory 级别修改策略的内容？
不支持。 只能使用 Microsoft Entra 管理中心管理此策略。 另请参阅上一问题。
为何需要使用 DFSR 进行 sysvol 复制？
FRS（DFSR 以前的技术）存在很多已知问题，在较新版本的 Windows Server Active Directory 中完全不受支持。 Microsoft Entra 密码保护的零测试在配置了 FRS 的域上完成。
有关详细信息，请参阅以下文章：
如果域尚未使用 DFSR，你必须先迁移它以使用 DFSR，然后才能安装 Microsoft Entra 密码保护。 有关详细信息，请参阅以下链接：
警告
Microsoft Entra 密码保护 DC 代理软件当前安装在仍使用 FRS 进行 sysvol 复制的域中的域控制器上，但该软件在此环境中无法正常运行。 负面附带影响包括未能复制单个文件，以及 sysvol 还原过程显示成功，但未能复制所有文件且无任何提示。 应当尽快迁移域以使用 DFSR，从而利用 DFSR 的内在优势并解除阻止 Microsoft Entra 密码保护的部署。 在仍使用 FRS 的域中运行此软件的未来版本时，系统会将其自动禁用。
该功能需要占用域 sysvol 共享中的多少磁盘空间？
准确的空间用量根据多种因素而异，例如，Microsoft 全局受禁密码列表和租户自定义密码列表中的受禁令牌数目和长度，以及加密开销。 这些列表的内容将来可能会不断扩充。 考虑到这一点，合理的预期是该功能至少需要占用域 sysvol 共享中的 5 MB 空间。
安装或升级 DC 代理软件后为何需要重新启动？
此项要求是核心 Windows 行为造成的。
是否有任何方法可将 DC 代理配置为使用特定的代理服务器？
否。 由于代理服务器是无状态的，具体使用哪种代理服务器并不重要。
是否可与其他服务（例如 Microsoft Entra Connect）一起部署 Microsoft Entra 密码保护代理服务？
是的。 Microsoft Entra 密码保护代理服务和 Microsoft Entra Connect 永远不会直接相互冲突。
遗憾的是，Microsoft Entra 密码保护代理软件安装的 Microsoft Entra Connect 代理更新程序服务版本与 Microsoft Entra 应用程序代理软件安装的版本不兼容。 这种不兼容性可能会导致代理更新服务无法联系 Azure 以获取软件更新。 不建议在同一台计算机上安装 Microsoft Entra 密码保护代理和 Microsoft Entra 应用程序代理。
DC 代理的安装和注册顺序是什么？
支持对代理程序安装、DC 代理安装、林注册和代理注册的任何排序。
部署此功能是否会导致域控制器上出现性能瓶颈？
在现有的正常 Active Directory 部署中，Microsoft Entra 密码保护 DC 代理服务应该不会显著影响域控制器的性能。
对于大部分 Active Directory 部署而言，密码更改操作在任意给定的域控制器上只占总体工作负荷的一小部分。 例如，假设某个 Active Directory 域包含 10,000 个用户帐户，某个 MaxPasswordAge 策略设置为 30 天。 一般情况下，此域每天会发生 10000/30（约等于 333）次密码更改操作，即使是在单个域控制器中，此操作次数也是微不足道的。 考虑一种更糟糕的潜在情况：假设在单个 DC 上执行的大约 333 次密码更改是在一小时内完成的。 例如，当许多员工在星期一上午上班时，就可能会发生这种此情况。 即使出现这种情况，每 60 分钟的密码更改次数也只有大约 333 次，即每分钟 6 次，同样，这并不是一个很高的负载。
但是，如果当前域控制器已在性能限制级别运行（例如，达到了 CPU、磁盘空间、磁盘 I/O 等的上限），则我们建议添加更多的域控制器或扩展可用磁盘空间，然后再部署此功能。 请参阅上面有关 sysvol 磁盘空间使用情况的上一个问题。
问：我只想在域中的少量 DC 上测试 Microsoft Entra 密码保护。 是否可以强制用户密码更改使用这些特定的 DC？
否。 当用户更改其密码时，Windows 客户端 OS 会控制要使用的域控制器。 域控制器是根据 Active Directory 站点和子网分配、特定于环境的网络配置等因素选择的。 Microsoft Entra 密码保护不会控制这些因素，也不能对选择哪个域控制器来更改用户的密码施加影响。
在一定程度上实现此目标的方法之一是在给定 Active Directory 站点中的所有域控制器上部署 Microsoft Entra 密码保护。 这种方法能够合理覆盖分配到该站点的 Windows 客户端，以及登录到这些客户端并更改其密码的用户。
问：如果只在主域控制器 (PDC) 上安装 Microsoft Entra 密码保护 DC 代理服务，该域中的其他所有域控制器是否也会受到保护？
不是。 如果在给定的非 PDC 域控制器上更改用户密码时，则明文密码永远不会发送到 PDC（这种想法是常见的错误认知）。 一旦在给定的 DC 上接受新密码，该 DC 将使用该密码来为该密码创建各种特定于身份验证协议的哈希，然后在目录中保存这些哈希。 不会保存明文密码。 然后，更新的哈希将复制到 PDC。 在某些情况下，用户密码可以直接在 PDC 上更改，同样，这取决于网络拓扑和 Active Directory 站点设计等多种因素。 （请参阅前面的问题。）
总而言之，在 PDC 上部署 Microsoft Entra 密码保护 DC 代理服务需要对整个跨中的功能实现 100% 的安全覆盖。 仅在 PDC 上部署该功能不能为域中的任何其他 DC 提供 Microsoft Entra 密码保护安全优势。
为什么在本地 Active Directory 环境中安装代理后，自定义智能锁定仍不起作用？
仅在 Microsoft Entra ID 中支持自定义智能锁定。 即使安装了代理，对 Microsoft Entra 管理中心内的自定义智能锁定设置的更改也不会影响本地 Active Directory 环境。
问：System Center Operations Manager 管理包是否适用于 Microsoft Entra 密码保护？
不是。
为什么在将策略配置为处于审核模式时，Microsoft Entra ID 仍拒绝弱密码？
仅本地 Active Directory 环境支持审核模式。 当评估密码时，Microsoft Entra 始终隐式地处于“强制”模式。
当密码被 Microsoft Entra 密码保护拒绝时，我的用户看到传统的 Windows 错误消息。 是否能自定义该错误消息，使用户知道到底发生了什么？
否。 当域控制器拒绝密码时，用户所见到的错误消息由客户端计算机控制，而不是由域控制器控制。 不管密码是否被默认 Active Directory 密码策略或基于密码筛选器的解决方案（如 Microsoft Entra 密码保护）拒绝，都会发生此行为。
密码测试过程
您可能想要对各种密码执行一些基本测试，以便验证软件的正确操作并更好地了解密码评估算法。 本部分概述了用于生成可重复结果的测试的方法。
为什么需要执行此类步骤？ 有几个因素会使在本地 Active Directory 环境中对密码执行受控的、可重复的测试变得困难：
- 密码策略在 Azure 中进行配置和保留，并且策略的副本会由本地 DC 代理通过使用轮询机制定期进行同步。 此轮询周期固有的延迟可能会导致混淆。 例如，如果在 Azure 中配置策略，但忘记将其同步到 DC 代理，则测试可能不会产生预期的结果。 轮询间隔当前硬编码为每小时一次，但在策略更改之间等待一小时对于交互式测试方案来说是不理想的。
- 将新的密码策略同步到域控制器后，会在复制到其他域控制器时出现进一步的延迟。 如果针对尚未接收到最新版策略的域控制器测试密码更改，则这些延迟可能会导致意外结果。
- 通过用户界面测试密码更改会使你的结果难以有置信度。 例如，很容易错误地在用户界面中键入无效密码，尤其因为大多数密码用户界面都隐藏用户输入（例如，Windows Ctrl-Alt-Delete ->“更改密码”UI）。
- 在测试已加入域的客户端中的密码更改时，不可能严格控制使用哪个域控制器。 Windows 客户端 OS 根据 Active Directory 站点和子网分配、特定于环境的网络配置等因素选择域控制器。
以下步骤基于登录域控制器时的密码重置的命令行测试，这是为了避免这些问题。
警告
仅在测试环境中使用这些过程。 当 DC 代理服务停止时，所有传入密码更改和重置都会被接受，无需验证。 这也有助于避免登录域控制器的风险增加。
以下步骤假定你已在至少一个域控制器上安装了 DC 代理，至少安装了一个代理，并同时注册了代理和林。
使用域管理员凭据或其他具有创建测试性用户帐户和重置密码的足够权限的凭据登录到域控制器。 确保域控制器已安装 DC 代理软件并已重启。
打开事件查看器并导航到 DC 代理管理事件日志。
打开提升的命令提示符窗口。
为执行密码测试创建测试帐户
有多种方法可以创建用户帐户，但此处提供了一个命令行选项，可让你在重复的测试周期中轻松地执行此操作：
net.exe user <testuseraccountname> /add <password>出于下面讨论的目的，假设我们创建了一个名为 "ContosoUser" 的测试帐户，例如：
net.exe user ContosoUser /add <password>至少以身份验证管理员的身份登录到 Microsoft Entra 管理中心。
浏览到“保护”>“身份验证方法”>“密码保护”。
根据需要为要执行的测试修改 Microsoft Entra 密码保护策略。 例如，你可以决定配置强制或审核模式，或者可以决定在自定义禁止密码列表中修改禁止项的列表。
通过停止并重新启动 DC 代理服务来同步新策略。
此步骤可通过各种方法来执行。 一种方法是使用“服务管理”管理控制台，方法是右键单击 Microsoft Entra 密码保护 DC 代理服务，然后选择“重新启动”。 另一种方法可以从命令提示符窗口执行，如下所示：
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgent检查事件查看器以验证是否已下载新策略。
每次停止并启动 DC 代理服务时，应会看到连续的 2个 30006 事件。 第一个 30006 事件将反映缓存于 sysvol 共享的磁盘上的策略。 第二个 30006 事件（如果存在）应具有更新的租户策略日期，如果是，则将反映从 Azure 下载的策略。 租户策略日期值当前被编码为显示从 Azure 下载策略的大致时间戳。
如果第二个 30006 事件未出现，则应在继续操作之前排查该问题。
30006事件如下面的示例所示：
The service is now enforcing the following Azure password policy. Enabled: 1 AuditOnly: 0 Global policy date: 2018-05-15T00:00:00.000000000Z Tenant policy date: 2018-06-10T20:15:24.432457600Z Enforce tenant policy: 1例如，在“强制”模式和“审核”模式之间进行切换时，会导致修改 AuditOnly 标志（列出的 AuditOnly=0 的策略处于“强制”模式）。 对自定义受禁密码列表所做的更改不会直接反映在上面的 30006 事件中，而出于安全原因，这些更改不会记录到其他任何位置。 进行该更改后，成功地从 Azure 下载策略意味着还包括已修改的自定义受禁密码列表。
尝试在测试用户帐户上重置新密码来运行测试。
可在命令提示符窗口中执行此步骤，如下所示：
net.exe user ContosoUser <password>运行该命令后，可以通过在事件查看器中查看来获取有关该命令的结果的详细信息。 在 DC 代理管理事件日志主题中介绍了密码验证结果事件；你将使用此类事件来验证测试结果以及 net.exe 命令的交互式输出。
我们来举个例子：尝试设置 Microsoft 全局列表禁止的密码 (请注意，该列表 未记录，但我们可以根据已知的禁止项进行测试)。 此示例假设你已将策略配置为处于强制模式下，并已将零个项添加到自定义禁止密码列表。
net.exe user ContosoUser PassWord The password doesn't meet the password policy requirements. Check the minimum password length, password complexity, and password history requirements. More help is available by typing NET HELPMSG 2245.按照文档，由于我们的测试是密码重置操作，你应该看到 ContosoUser 用户的 10017 和 30005 事件。
该 10017 事件应如下例所示：
The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message. UserName: ContosoUser FullName:该 30005 事件应如下例所示：
The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. UserName: ContosoUser FullName:这很有趣，接下来请尝试其他示例！ 现在，当策略处于“审核”模式时，我们将尝试设置自定义受禁密码列表所禁止的密码。 此示例假设你已完成以下步骤：将策略配置为处于“审核”模式，将“lachrymose”项添加到自定义受禁密码列表，并循环使用 DC 代理服务将生成的新策略同步到域控制器，如前所述。
设置禁止密码的变体：
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.请记住，这次成功了是因为策略处于审核模式。 你应看到 ContosoUser 用户的 10025 和 30007 事件。
该 10025 事件应如下例所示：
The reset password for the specified user would normally have been rejected because it didn't comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details. UserName: ContosoUser FullName:该 30007 事件应如下例所示：
The reset password for the specified user would normally be rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. UserName: ContosoUser FullName:继续测试所选的各种密码，并使用前面步骤中所述的过程检查事件查看器中的结果。 如果需要在 Microsoft Entra 管理中心内更改此策略，请不要忘记将新策略同步到 DC 代理，如前文所述。
我们介绍了一些过程，使你能够对 Microsoft Entra 密码保护的密码验证行为进行受控测试。 直接在域控制器上从命令行重置用户密码看起来可能是执行此类测试的一种奇怪方法，但如前所述，它旨在产生可重复的结果。 在测试各种密码时，请记住密码评估算法，因为它可能有助于解释你不期望的结果。
警告
完成所有测试后，请不要忘记删除为测试目的创建的任何用户帐户！
更多内容
以下链接不是核心 Microsoft Entra 密码保护文档的一部分，但可能是有关该功能的其他信息的有用来源。
可用的 Microsoft Premier\Unified 支持培训
若要详细了解 Microsoft Entra 密码保护及其部署方式，可以使用 Microsoft 主动服务。 签署顶级支持或统一支持合同的客户可以使用此项服务。 该服务称为 Microsoft Entra ID：密码保护。 请联系客户成功客户经理获取详细信息。