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

仅从Windows的angular度来看：

NTLM

• 与外部 （非域名）和内部客户一起工作
• 在IIS框上同时使用域帐户和本地用户帐户
  • 使用域帐户， 只有服务器需要直接连接到域控制器（DC）
  • 使用本地帐户，你不需要连接任何地方:)
  • 您不必以有问题的用户身份login即可使用凭证
  • 除此之外 ，一个繁忙的NTLM服务器（IIS，Exchange，TMG / ISA等）用NTLM请求的数量（缓解： MaxConcurrentAPI ， AuthPersistSingleRequest （false） ，更快的数据中心）压倒了DC并不罕见。 自我参照奖金 。）
• 只需要客户端连接到IIS服务器 （在站点端口，没有别的，即一切都发生在HTTP（或HTTPS））。
• 可以遍历任何支持HTTP Keep-Alive的代理
  • 您可能能够使用TLS / SSL来解决其他问题
• 需要多次往返authentication， 小包
  • （日志模式是401.2,401.1,200用户名）
• 不能用于需要双跳authentication的情况
  • 即用户的凭证将被转发到另一台计算机上的服务
• 支持较老的客户端（<Win2000）
• 易受LMauthentication级别差异（不匹配lmcompatibilitylevel ）
• 如果“限制”失败，则由“协商”程序包用作回退。
  • （ 不是 “如果访问被拒绝了”，Curb必须打破 NTLM才能使用 – 通常这看起来没有获得票证，如果客户得到票证并且不完美，那么不会导致回退）。

Kerberos的

• 只适用于当前join域的客户端
  • 需要客户端连接到AD DC （tcp / udp 88） 和服务器 （客户端从DC通过Curb端口检索票证，然后使用HTTP提供给服务器）

• 可能能够遍历一个代理，但是看到上面的DC点： 你仍然需要和一个活跃的DC在同一个networking上，就像服务器一样 。

  • 所以在理论上，如果你有一个互联网连接的客户端直接与互联网连接的DC聊天的域，这是可行的。 但是不要那样做，除非你已经知道了。
  • 在反向代理服务器场景（ISA / TMG）中， 协议转换服务器需要在该networking上，即不是客户端…但是客户端并不是真正做Kerberos位的客户端（必要的 – 认为Forms auth to Curb过渡）。

• 票证是长期的 （10小时），意味着在票证生命周期内更less的DC通信 – 并强调：这可以节省数以百万计的 每个客户端在这个生命周期 – （ AuthPersistNonNTLM仍然是一件事; Kerberos PACvalidation曾经是一件事情）

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

当我们在这时：

基本

• 可以多跳。 但是，通过将您的用户名和密码直接暴露给目标Web应用程序来这样做
  • 然后可以做任何他们想要的东西。 任何东西 。
  • “哦，域名pipe理员只是使用我的应用程序？我刚刚阅读他们的电子邮件？然后重新设置他们的密码吗？ Awww。可惜 ”
• 需要传输层安全性 （即TLS / SSL）来保证任何forms的安全。
  • 然后， 看到以前的问题
• 适用于任何浏览器
  • （但看第一个问题 ）
• 需要一次往返才能authentication（ 401，200 ）
• 可以在多跳场景中使用，因为Windows可以使用基本凭据执行交互式login
  • 可能需要将LogonTypeconfiguration为完成此操作（认为在2000年到2003年间，默认情况下会更改为networking明文，但可能会误解）
  • 但是， 再次 看到第一个问题 。
  • 得到第一个问题真的非常重要的印象？ 它是。

总结一下：

遏制可能会很难build立起来，但是有很多指南（ 我的一个 ）试图简化这个过程，而且从2003年到2008年，这些工具已经有了很大的改进（ SetSPN可以search重复的，这是最常见的问题; 使用SETSPN -S只要你看到使用-A的指导，生活就会更开心）。

受限制的授权是值得的入场费用。

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

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

从Microsoft应用程序validation程序中检测常见的开发人员错误。 其中一个错误是使用NTLM ：

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

虽然Kerberos已经有很多年了，但是许多应用程序仍然只是使用NTLM编写的。 这不必要地降低了应用程序的安全性。 但Kerberos无法在所有场景中取代NTLM，主要是客户端需要对未join域的系统进行身份validation（家庭networking可能是最常见的）。 Negotiate安全软件包允许尽可能使用Kerberos的向后兼容的安全措施，只有在没有其他选项的情况下才会恢复为NTLM。 切换代码以使用Negotiate而不是NTLM将显着提高我们的客户的安全性，同时引入很less或没有应用程序兼容性。 谈判本身并不是一个银弹 – 有些情况下攻击者可以强制降级到NTLM，但是这些攻击要难得多。 但是，一个直接的改进是编写正确使用协商的应用程序自动免疫NTLMreflection攻击。

通过对使用NTLM谨慎的最后一句话：在未来的Windows版本中，可以禁止在操作系统上使用NTLM。 如果应用程序对NTLM有很大的依赖性，那么当NTLM被禁用时，它们只是无法进行身份validation。

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

在20多年的时间里，Kerberos已经成为Unix中的标准和开放协议，而NTLM则是微软公司的一个纯粹的专有解决scheme，只有微软才知道。

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