Windows 身份验证的演变

随着 Windows 不断发展以满足不断变化的世界的需求，我们保护用户的方式也必须不断发展以应对现代安全挑战。Windows 安全性的基本支柱是用户身份验证。我们正在努力通过扩展 Kerberos 的可靠性和灵活性并减少对 NT LAN Manager (NTLM) 的依赖来加强用户身份验证。

自 2000 年以来，Kerberos 一直是默认的 Windows 身份验证协议，但仍然存在无法使用它并且 Windows 回退到 NTLM 的情况。我们的团队正在为 Windows 11 构建新功能，即使用 Kerberos 进行初始和直通身份验证 (IAKerb) 以及 Kerberos 的本地密钥分发中心 (KDC)，以解决这些情况。我们还引入了改进的 NTLM 审核和管理功能，使您的组织能够更深入地了解 NTLM 的使用情况，并更好地控制删除它。

我们的最终目标是完全消除使用 NTLM 的需要，以帮助提高所有 Windows 用户的身份验证安全性。

NTLM 的遗产

Windows 中的用户身份验证用于向远程系统证明用户的身份。NTLM 通过在质询和响应交换期间证明密码的知识而不向任何人透露密码来实现此目的。NTLM 的工作方式有其优点，使其在过去很流行：

• NTLM 不需要到域控制器的本地网络连接。

• NTLM 是使用本地帐户时唯一支持的协议。

• 当您不知道目标服务器是谁时，NTLM 就会起作用。

这些好处导致一些应用程序和服务硬编码 NTLM 的使用，而不是尝试使用其他更现代的身份验证协议（如 Kerberos）。Kerberos 提供了更好的安全保证，并且比 NTLM 更具可扩展性，这就是它现在成为 Windows 中首选默认协议的原因。

组织可以关闭 NTLM，但这可能会导致硬编码 NTLM 使用的应用程序出现问题。在无法使用 Kerberos 的情况下，禁用 NTLM 也可能会导致出现问题。Kerberos 必须有权访问域控制器并需要指定目标服务器。这些要求并不总是能够满足，如果 NTLM 不能作为后备，这将导致身份验证问题。改进 Windows 身份验证并减少 NTLM 的使用需要我们消除 Kerberos 中的这些限制。

Kerberos，比以往更好

对于 Windows 11，我们向 Kerberos 引入了两项主要功能，以在可以使用时进行扩展 — 解决 Kerberos 如今退回到 NTLM 的两个最大原因。第一个是 IAKerb，允许客户端在更多样化的网络拓扑中使用 Kerberos 进行身份验证。第二个是 Kerberos 的本地 KDC，为本地帐户添加了 Kerberos 支持。

IAKerb 是行业标准 Kerberos 协议的公共扩展，允许不具有域控制器视线的客户端通过具有视线的服务器进行身份验证。这通过协商身份验证扩展起作用，并允许 Windows 身份验证堆栈代表客户端通过服务器代理 Kerberos 消息。IAKerb 依靠 Kerberos 的加密安全保证来保护通过服务器传输的消息，以防止重放或中继攻击。这种类型的代理在防火墙分段环境或远程访问场景中非常有用。

Kerberos 的本地 KDC 构建在本地计算机的安全帐户管理器之上，因此可以使用 Kerberos 完成本地用户帐户的远程身份验证。这利用 IAKerb 允许 Windows 在远程本地计算机之间传递 Kerberos 消息，而无需添加对 DNS、netlogon 或 DCLocator 等其他企业服务的支持。IAKerb 也不要求我们在远程计算机上打开新端口来接受 Kerberos 消息。

通过本地 KDC 进行的身份验证使用开箱即用的 AES，提高了本地身份验证的安全性。

除了扩大 Kerberos 场景覆盖范围之外，我们还修复了现有 Windows 组件中内置的 NTLM 硬编码实例。我们正在将这些组件转移为使用 Negotiate 协议，以便可以使用 Kerberos 代替 NTLM。通过迁移到 Negotiate，这些服务将能够为本地和域帐户利用 IAKerb 和 LocalKDC。

所有这些更改将默认启用，并且在大多数情况下不需要配置。NTLM 将继续作为后备方案提供，以维持现有的兼容性。

改善NTLM的管理

除了新的 Kerberos 功能之外，我们还扩展了 NTLM 管理控制，以便为管理员提供更大的灵活性，帮助他们跟踪和阻止其环境中的 NTLM 使用。现有的事件查看器日志提供有关使用 NTLM 的传入和传出身份验证请求的信息。我们正在将服务信息添加到这些日志中，以便更清楚地了解哪些应用程序正在使用 NTLM。同样，我们正在扩展对 NTLM 的控制，以允许在服务级别指定粒度策略。通过这些策略，您将能够阻止特定服务的 NTLM 使用或为系统范围的 NTLM 阻止创建服务例外。

未来 NTLM 的禁用

减少 NTLM 的使用最终将导致它在 Windows 11 中被禁用。我们正在采用数据驱动的方法并监控 NTLM 使用的减少情况，以确定何时可以安全地禁用它。与此同时，您可以使用我们提供的增强控件来抢占先机。一旦默认禁用，客户还可以出于兼容性原因使用这些控件重新启用 NTLM。

你现在应该做什么？

减少 NTLM 使用通常是客户的首要任务，我们有一些现有资源可以帮助为这些更改做好准备。

• 开始对您的 NTLM 使用进行编目。我们建议使用现有策略和日志记录来了解 NTLM 的使用位置以及哪些应用程序可能会阻止您禁用 NTLM。有关详细信息，请参阅NTLM 阻止和您：Windows 7 中的应用程序分析和审核方法。

• 对于应用程序开发人员，审核 NTLM 硬编码使用的代码。查找对AcquireCredentialsHandle函数的调用，该函数传入硬编码字符串“ntlm”并替换为“negotiate”。还要查找对RpcBindingSetAuthInfo函数的调用，并将“RPC_C_AUTHN_DEFAULT”替换为“RPC_C_AUTHN_GSS_NEGOTIATE”。

• 注册参加我们即将于 2023 年 10 月 24 日太平洋时间上午 8:00 举行的网络研讨会“Windows 身份验证的演变”。加入产品工程团队，观看现场演示、问答、故障排除指导，并抢先了解我们最终禁用和删除 NTLM 的长期策略。

• 请留意有关我们即将推出的功能改进的更多更新，以解决 Kerberos 目前不支持的场景。

原文始发于微信公众号（河南等级保护测评）：Windows 身份验证的演变