1

我使用一些客户端软件和 Web 应用程序，它们不清楚它们允许使用哪种类型的 IWA 进行身份验证。我已阅读手册/指南无济于事。它们包含标记为“启用 IWA”的复选框功能，并且在通过机器/域身份验证时，IWA 似乎确实像宣传的那样工作。

根据我所知道的和我所做的研究，有两种类型的 IWA：NTLM 和 Kerberos。我熟悉用于使 Negotiate 使用/或 NTLM/Kerberos 的 IIS 设置。我也熟悉使用 klist 来确定是否在域认证系统上请求/使用了 kerberos 票证。

我感到困惑的地方是，当应用程序不是基于 IIS（又名无法检查协商设置）并且 klist 输出显示没有 kerberos 票证并且 IWA 仍然有效的情况下出现的情况。这种情况是否总是假定为 IWA NTLM？还有其他我不知道的 IWA 形式吗？我知道 Web 应用程序可以从 javascript 中提取当前经过身份验证的用户，但这是一种非常不安全的做法，而且在我检查了 javascript 时似乎也不是这种情况。

问题总结：

  • 还有其他形式的 IWA 我在这里没有提到吗？
  • 如果正在使用非 IIS/klist 可验证 IWA，我如何检查 IWA 类型？
  • 检查是否正在使用不需要我执行数据包捕获的 NTLM 的最简单方法是什么？
4

1 回答 1

0

  1. 还有其他形式的 IWA 我在这里没有提到吗？
    A.没有其他形式 - 您的研究是正确的，并且您列出了 IWA 的两种形式： NTLM和Kerberos。

  2. 如果正在使用非 IIS/klist 可验证 IWA，我如何检查 IWA 类型？
    A. klist 验证 Kerberos 是否用作 IWA 类型。如果 klist 显示没有 Kerberos 票证，并且Web 应用程序的单点登录在 HTTP 客户端没有显示询问用户名和密码的对话框的情况下工作，那么身份验证类型必须是 NTLM。

  3. 检查是否正在使用不需要我执行数据包捕获的 NTLM 的最简单方法是什么？
    A. 最简单的了解方法是通过环境来了解：当 klist 输出显示没有 kerberos 票证并且 IWA 仍然有效（没有弹出对话框）时，这意味着 NTLM必须被用过。只要 SSO 工作并且 klist 没有显示到 Web 应用程序的 Kerberos 票证，就会调用 NTLM（如上面的答案 #2 中所示）。尽管浏览器缓存中存在会话密钥，这可能会造成混淆，唯一真正确定的方法是通过在跟踪/调试级别观察网络跟踪或服务器日志分析。不过我要补充一点，如果确实出现了询问用户名和密码的对话框，那么身份验证类型不是 IWA，很可能是基本身份验证或 LDAP 身份验证（基本身份验证和 LDAP 身份验证不是 SSO 协议）。
于 2017-03-18T04:42:37.233 回答