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

这是我从来没有真正能够回答以及我喜欢的东西: 在IIS中使用Kerberos身份validation,而不是NTLM的真正优势是什么?

我看到很多人真的很难成立(包括我自己),而且我还没有拿出一个好的理由来使用它。 虽然有一些非常重要的优势,否则设置它不值得一提,对不对?

仅从Windows的angular度来看:

NTLM

  • 外部 (非域名)和内部客户一起工作
  • 在IIS框上同时使用域帐户本地用户帐户
    • 使用域帐户, 只有服务器需要直接连接到域控制器(DC)
    • 使用本地帐户,你不需要连接任何地方:)
    • 您不必以有问题的用户身份login即可使用凭证
    • 除此之外 ,一个繁忙的NTLM服务器(IIS,Exchange,TMG / ISA等)用NTLM请求的数量(缓解: MaxConcurrentAPIAuthPersistSingleRequest (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。