为什么在 IIS 中使用 Kerberos 而不是 NTLM？

Question

这是我从来没有真正能够像我喜欢的那样回答的问题： 在 IIS 中使用 Kerberos 身份验证而不是 NTLM 的真正优势是什么？

我看到很多人真的很难设置它（包括我自己），我一直无法找到使用它的充分理由。不过肯定有一些非常显着的优点，否则设置它就不值得所有的麻烦，对吧？

Answer 1

仅从 Windows 的角度来看：

NTLM

• 与工程两个 外部（非域）和内部客户
• 适用于 IIS 框上的 域帐户和本地用户帐户
  • 使用域帐户，只有服务器需要直接连接到域控制器 (DC)
  • 使用本地帐户，您在任何地方都不需要连接:)
  • 您无需以相关用户身份登录即可使用凭据
  • 旁白：DC 被繁忙的 NTLM 服务器（IIS、Exchange、TMG/ISA 等）和大量 NTLM 请求（减轻：MaxConcurrentAPI、AuthPersistSingleRequest（假）、更快的 DC）淹没的情况并不少见。参考奖金。）
• 只需要客户端连接到 IIS 服务器（在站点端口上，没有别的。即一切都通过 HTTP（或 HTTPS）发生。）
• 可以遍历任何支持HTTP Keep-Alive的 代理
  • 您也许可以使用 TLS/SSL 来解决其他问题
• 需要多次往返进行身份验证，使用小数据包
  • （日志模式是 401.2、401.1、200和用户名）
• 不能用于需要双跳认证的场景
  • 即用户的凭据将被转发到另一台计算机上的服务
• 支持旧客户端 (< Win2000)
• 容易受到 LM 身份验证级别差异的影响（不匹配lmcompatibilitylevel）
• 如果 Curb 失败，则被 Negotiate 包用作后备。
• （不是“如果使用Kerb拒绝访问”，必须中断Curb 才能使用 NTLM - 通常这看起来像是没有获得票证。如果客户端获得了票证并且它不完美，则不会导致回退。）

Kerberos

• 仅适用于当前已加入域的客户端

  • 需要客户端连接到AD DC (tcp/udp 88)和服务器（客户端通过 Curb 端口从 DC 检索票，然后使用 HTTP 提供给服务器）

• 也许能够遍历代理，但请参阅上面的 DC 点：您仍然需要与活动 DC 位于同一网络上，服务器也是如此。

  • 所以理论上，如果您有一个域，其中连接互联网的客户端直接与连接互联网的 DC 聊天，这是可行的。但除非你已经知道，否则不要这样做。
  • 在反向代理场景 (ISA/TMG) 中，协议转换服务器需要在该网络上，即不是客户端......过渡）。

• 票证是长寿命的（10 小时），意味着在票证生命周期内DC 通信较少- 并强调：这可以 在整个生命周期内为每个客户端节省数千到数百万个请求- （AuthPersistNonNTLM仍然是一件事；Kerberos PAC 验证曾经是一件事）

• 需要单次往返验证，但验证负载大小相对较大（通常为 6-16K）（401 , {(encoded) token size} 200）

• 可以与（“请始终使用受约束的”） 委派一起使用以启用双跳方案，即连接用户到下一个服务的 Windows 身份验证

  • 实际上，N-hop - 它像乐高一样堆叠！根据需要添加尽可能多的啤酒花...
  • 例如，允许UserA访问 IIS，并让 IIS 在访问不同的 SQL Server 计算机时模拟同一个 Windows 用户帐户。这就是“授权委托”。
  • （在此上下文中约束意味着“但不是其他任何东西”，例如 Exchange 或另一个 SQL 框）

• 目前是协商身份验证的主要安全包

  • 这意味着 Windows 域成员在可以获得它时更喜欢它

• 需要注册 SPN，这可能很棘手。有帮助的规则。

• 需要使用名称作为目标，而不是 IP 地址

• Curb 可能失败的原因：

  • 使用 IP 地址而不是名称
  • 没有注册 SPN
  • 注册了重复的 SPN
  • SPN 注册错误帐户 ( KRB_ERR_AP_MODIFIED)
  • 没有客户端 DNS / DC 连接
  • 客户端代理设置/本地 Intranet 区域未用于目标站点

当我们在做的时候：

基本的

• 可以多跳。但是通过将您的用户名和密码直接暴露给目标网络应用程序来实现
  • 然后可以对他们做任何想做的事情。任何东西。
  • “哦，域管理员刚刚使用我的应用程序吗？我刚刚阅读了他们的电子邮件？然后重置他们的密码？Awww。可惜”
• 任何形式的安全都需要传输层安全（即 TLS/SSL）。
  • 然后，请参阅上一期
• 适用于任何浏览器
  • （但请参阅第一期）
• 需要单次往返验证（401 , 200）
• 可用于多跳方案，因为 Windows 可以使用基本凭据执行交互式登录
  • 可能需要LogonType配置来实现这一点（认为默认值在 2000 年到 2003 年之间更改为网络明文，但可能是记错了）
  • 但同样，请参阅第一个问题。
  • 得到第一个问题真的非常重要的印象？这是。

总结：

Curb 设置起来很棘手，但是有很多指南（我的）试图简化这个过程，并且从 2003 年到 2008 年，这些工具有了很大的改进（SetSPN可以搜索重复项，这是最常见的破坏问题;使用SETSPN -S任何时候你看到的指导使用-A，生活会更快乐）。

受限制的代表团值得入场。

Answer 2

来自Microsoft Application Verifier，它检测常见的开发人员错误。这些错误之一是使用 NTLM：

NTLM 是一种过时的身份验证协议，存在可能危及应用程序和操作系统安全的缺陷。最重要的缺点是缺乏服务器身份验证，这可能允许攻击者诱骗用户连接到欺骗服务器。作为缺少服务器身份验证的必然结果，使用 NTLM 的应用程序也容易受到一种称为“反射”攻击的攻击。后者允许攻击者劫持用户与合法服务器的身份验证对话，并使用它来对用户计算机的攻击者进行身份验证。NTLM 的漏洞和利用它们的方法是安全社区中增加研究活动的目标。

尽管 Kerberos 已经可用多年，但许多应用程序仍然只使用 NTLM 编写。这不必要地降低了应用程序的安全性。然而，Kerberos 不能在所有情况下取代 NTLM——主要是那些客户端需要对未加入域的系统进行身份验证的情况（家庭网络可能是其中最常见的）。Negotiate 安全包允许向后兼容的妥协，只要有可能就使用 Kerberos，并且只有在没有其他选择时才恢复到 NTLM。将代码切换为使用 Negotiate 而不是 NTLM 将显着提高我们客户的安全性，同时引入很少或没有应用程序兼容性。协商本身并不是灵丹妙药——在某些情况下，攻击者可以强制降级到 NTLM，但这些情况更难以利用。然而，一项直接的改进是，为正确使用 Negotiate 而编写的应用程序会自动免疫 NTLM 反射攻击。

最后提醒一下不要使用 NTLM：在 Windows 的未来版本中，可以在操作系统中禁用 NTLM。如果应用程序对 NTLM 有严格的依赖性，当 NTLM 被禁用时，它们将无法进行身份验证。

Answer 3

• Kerberos 享有比 NTLM 更快、更安全的身份验证机制的美誉。
• 由于 NTLM 基于连接的特性，它在历史上也比 NTLM 更容易通过代理服务器连接。
• 也就是说，正如您所注意到的，Kerberos 更难以启动和运行，并且需要与 AD 的连接并不总是实用。

另一种方法是将身份验证设置为negotiate并使用两者，而不是一个而不是另一个。