这是我从来没有能够像我希望的那样回答的问题： 在 IIS 中使用 Kerberos 身份验证而不是 NTLM 的真正优势是什么？
我见过很多人（包括我自己）在安装过程中遇到很大困难，我也想不出一个使用它的好理由。但它一定有一些相当显著的优势，否则就不值得这么费劲去安装它，对吧？
答案1
仅从 Windows 角度来看：
NTLM
- 适用于两个都 外部的（非域）和内部的客户
- 适用于两者域帐户和本地用户帐户在 IIS 框上
- 使用域帐户，仅限服务器需要直接连接到域控制器 (DC)
- 使用本地帐户，您不需要任何地方的连接:)
- 您无需以相关用户身份登录即可使用凭证
- 在旁边：对于 DC 来说，由于 NTLM 请求数量过多而导致繁忙的 NTLM 服务器（IIS、Exchange、TMG/ISA 等）不堪重负的情况并不少见（为了缓解：
MaxConcurrentAPI，AuthPersistSingleRequest（错误的），更快的DC。）（自我参考奖金。
- 需要客户端连接仅有的到 IIS 服务器（在站点端口上，没有其他内容。即一切通过 HTTP（或 HTTPS）进行。）
- 可以遍历任何支持HTTP 保持活动s
- 您可以使用 TLS/SSL 来解决其他问题
- 需要多次往返进行身份验证，小包装
- （对数模式是 401.2, 401.1, 200使用用户名）
- 不能用于需要双跳认证的场景
- 即用户的凭证将被转发到另一台计算机上的服务
- 支持旧客户端 (< Win2000)
- 容易受到 LM Auth Level 差异的影响（不匹配
lmcompatibilitylevel） - 如果 Kerb 失败，则将用作 Negotiate 包的后备。
- （不是“如果访问被否认与路缘石”，路缘石必须休息NTLM 的使用 - 通常这看起来像是没有获得票证。如果客户端获得了票证并且票证不完美，则不会导致回退。）
凯尔伯罗斯
适用于现在仅限已加入域的客户端
- 需要客户端连接到直流电源（TCP/UDP 88）和服务器（客户端通过 Kerb 端口从 DC 检索票证，然后使用 HTTP 提供给服务器）
可能能够遍历代理，但请参见上面的 DC 点：你仍然需要与活动 DC 位于同一网络上，服务器也是如此。
- 所以理论上如果您有一个域，其中互联网连接的客户端直接与互联网连接的 DC 聊天，那么这是可行的。但是不要这样做除非你已经知道了。
- 在反向代理场景（ISA/TMG）中，协议转换服务器需要在该网络上，即而不是客户端...但客户端并不是真正执行 Kerberos 位的人（必然 - 想想 Forms auth 到 Kerb 的转换）。
票是长期有效的（10小时）含义更少的直流通信在票的有效期内 - 并强调：这可以节省数千到数百万个请求 每位客户在那一生中 - （
AuthPersistNonNTLM依然存在；Kerberos PAC 验证曾经是一个东西需要一个单程往返进行身份验证，但身份验证有效载荷尺寸相对较大（通常为 6-16K）（401，{（编码）标记大小}200）
可以与（“请始终使用约束”） 代表团实现双跳场景即连接用户到下一个服务的 Windows 身份验证
- 实际上，N 跳- 像乐高一样堆叠！根据需要添加尽可能多的跳跃...
- 例如，允许
UserA访问 IIS，并且允许 IIS 在访问不同的 SQL Server 计算机时模拟相同的 Windows 用户帐户。这就是“身份验证委派”。 - （受约束在此上下文中的意思是“但不是其他任何东西”，例如 Exchange 或其他 SQL 框）
目前是 Negotiate 身份验证的主要安全包
- 这意味着 Windows 域成员在可以获得它时会更喜欢它
需要SPN 注册，这可能很棘手。有帮助的规则。
需要使用姓名作为目标，而不是 IP 地址
Kerb 可能失败的原因：
- 使用 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的指导，生活就会更快乐）。
受限的授权是值得付出入场费的。
答案2
来自Microsoft 应用程序验证程序，它可以检测开发人员常见的错误。其中一个错误是NTLM 的使用：
NTLM 是一种过时的身份验证协议，其漏洞可能会危及应用程序和操作系统的安全。最重要的缺陷是缺乏服务器身份验证，这可能使攻击者能够诱骗用户连接到欺骗性服务器。由于缺少服务器身份验证，使用 NTLM 的应用程序还可能容易受到一种称为“反射”攻击的攻击。后者允许攻击者劫持用户与合法服务器的身份验证对话，并使用它向用户的计算机验证攻击者的身份。NTLM 的漏洞及其利用方式是安全社区日益关注的研究对象。
尽管 Kerberos 已经推出多年，但许多应用程序仍然只使用 NTLM。这不必要地降低了应用程序的安全性。然而，Kerberos 无法在所有情况下取代 NTLM - 主要是客户端需要向未加入域的系统进行身份验证的情况（家庭网络可能是其中最常见的情况）。Negotiate 安全包允许向后兼容的妥协，即尽可能使用 Kerberos，只有在没有其他选择时才恢复到 NTLM。将代码切换为使用 Negotiate 而不是 NTLM 将显著提高我们客户的安全性，同时引入很少或没有应用程序兼容性。Negotiate 本身并不是灵丹妙药 - 在某些情况下，攻击者可以强制降级到 NTLM，但这些情况更难以利用。但是，一个直接的改进是，正确使用 Negotiate 编写的应用程序会自动免受 NTLM 反射攻击。
最后要提醒大家不要使用 NTLM：在 Windows 的未来版本中，将有可能在操作系统中禁用 NTLM。如果应用程序对 NTLM 有很强的依赖性，则在禁用 NTLM 时，它们将无法进行身份验证。
答案3
- Kerberos 被认为是一种比 NTLM 更快、更安全的身份验证机制。
- 由于 NTLM 基于连接的特性，从历史上看，通过代理服务器连接比通过 NTLM 连接更容易。
- 话虽如此，正如您所说，Kerberos 的启动和运行更加困难，并且需要与 AD 建立连接，而这并不总是可行的。
另一种方法是将身份验证设置为negotiate并使用两者，而不是使用其中一种。
答案4
如果您需要模拟用户来访问不在 IIS 服务器上的资源，则需要 Kerberos。