为什么在IIS中使用Kerberos代替NTLM？

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

我已经看到很多人真的很难安装它（包括我自己），而且我还没有提出使用它的充分理由。但是，必须有一些相当显着的优势，否则设置它并不值得所有麻烦，对吗？

仅从Windows角度来看：

NTLM

• 与工程两个 外部（非域）和内部客户
• 在IIS框中 同时使用域帐户和本地用户帐户
  • 使用域帐户，只有服务器需要直接连接到域控制器（DC）
  • 使用本地帐户，您在任何地方都不需要连接:)
  • 您无需以相关用户身份登录即可使用凭据
  • 此外：繁忙的NTLM服务器（IIS，Exchange，TMG / ISA等）淹没DC并带有大量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处于同一网络上，就像服务器一样。

  • 因此，从理论上讲，如果您拥有一个域，在该域​​中，与Internet连接的客户端直接与与DC连接的DC进行聊天，则它是可行的。但是除非您已经知道，否则不要这样做。
  • 在反向代理方案（ISA / TMG）中，协议转换服务器需要在该网络上，即不在客户端上...但是然后，客户端实际上不是在执行Kerberos位的服务器（有必要-考虑对Curb进行Forms auth过渡）。

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

• 需要一次往返来进行身份验证，但是身份验证有效负载大小相对较大（通常为6-16K）（401，{（编码的）令牌大小} 200）
• 可以与（请始终受约束）委托一起使用，以启用将用户连接到下一个服务的Windows身份验证
  • 例如，为了允许UserA访问IIS并在IIS访问SQL Server时使用相同的用户帐户，这就是“身份验证委托”。
  • （在这种情况下，约束表示“但没有其他含义”，例如Exchange或另一个SQL框）
• 当前是协商身份验证的主要安全软件包
  • 表示Windows域成员在获得它时会更喜欢它
• 需要注册SPN，这可能很棘手。有帮助的规则。
• 需要使用名称作为目标，而不是IP地址
• 遏制可能失败的原因：
  • 使用IP地址代替名称
  • 没有注册SPN
  • 注册的重复SPN
  • SPN针对错误的帐户（KRB_ERR_AP_MODIFIED）注册
  • 没有客户端DNS / DC连接
  • 客户端代理设置/本地Intranet区域未用于目标站点

在我们的时候：

基本的

• 可以多跳。但这是通过直接将用户名和密码公开给目标Web应用程序来实现的
  • 然后可以对他们做任何想要的事情。什么都可以。
  • “哦，做了一个域管理员就用我的应用程序吗？并没有我刚才读他们的电子邮件？如果重置其密码？呀。可惜 ”
• 需要任何形式的安全性的传输层安全性（即TLS / SSL）。
  • 然后，查看上一期
• 适用于任何浏览器
  • （但请参阅第一期）
• 需要一个单一的往返来验证（401，200）
• 可以在多跳方案中使用，因为Windows可以使用基本凭据执行交互式登录
  • 可能需要LogonType配置来完成此操作（认为默认设置在2000年到2003年之间更改为网络明文，但是可能记错了）
  • 但再次，看第一个问题。
  • 觉得第一个问题真的非常重要吗？它是。

总结一下：

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

受约束的代表团值得入场费用。

• Kerberos具有比NTLM更快，更安全的身份验证机制的声誉。
• 由于NTLM基于连接的特性，从历史上看，通过代理服务器进行连接比使用NTLM更容易。
• 就是说，正如您所注意到的，Kerberos很难启动和运行，并且需要连接到AD的连接并不总是可行的。

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

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

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

尽管Kerberos已有许多年可用，但许多应用程序仍仅使用NTLM编写。这不必要地降低了应用程序的安全性。但是，Kerberos不能在所有情况下替换NTLM，主要是在客户端需要向未加入域的系统进行身份验证的情况下（家庭网络可能是其中最常见的）。Negotiate安全软件包允许向后兼容的折衷方案，该方案尽可能使用Kerberos，并且仅在没有其他选择时才还原为NTLM。将代码切换为使用协商而不是NTLM可以显着提高我们客户的安全性，同时几乎不引入应用程序兼容性。进行谈判本身并不是灵丹妙药，在某些情况下，攻击者可以强制降级为NTLM，但要利用它们显然要困难得多。但是，一项直接的改进是，为正确使用协商而编写的应用程序可以自动抵抗NTLM反射攻击。

最后请注意不要使用NTLM：在将来的Windows版本中，可以在操作系统上禁用NTLM。如果应用程序对NTLM有严格的依赖性，则在禁用NTLM时，它们将仅无法通过身份验证。

您应该添加一个非常重要的观点：

Kerberos在Unix中已成为标准和开放协议超过20年，而NTLM是Microsoft的纯专有解决方案，并且只有Microsoft知道。

如果需要模拟用户访问iis服务器上没有的资源，则需要Kerberos。