我正在为 Java Web 应用程序（使用 SPNEGO/Kerberos）构建一个 Active Directory 单点登录身份验证系统，并且在 Firefox 或（据报道）Safari 上一切正常，但 Internet Explorer 会导致异常：
GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)
事实上，我认为 IE 在安装 Windows 补丁之前就可以工作。
【问题讨论】：
标签： java active-directory kerberos gssapi spnego
显然，Microsoft IE 补丁 KB974455 为集成 Windows 身份验证启用了“扩展保护”。通常，使用 SPNEGO/Kerberos 身份验证时，客户端机器会为服务器获取 Kerberos/Active Directory 票证，并在 HTTP 身份验证协商期间提供此票证。至少从 Java 1.6 开始，Java JGSS-API 库能够解释 SPNEGO/Kerberos 协商并验证票证。
使用Extended Protection（另见Extended Protection for Authentication），IE 将通道绑定添加到 SPNEGO 协商；我目前不知道通道绑定基于什么数据，除了 SSL 会话标识符似乎是其中的一部分。 Java JGSS-API 库尝试验证通道绑定，并且无法在没有绑定所基于的数据的情况下进行验证。然后它会抛出通道绑定不匹配异常。
问题导致someinternettraffic，包括Sun Bug ID 6851973。
根据与6851973相关的cmets，RFC 4121说，
如果 GSS_Accept_sec_context [RFC2743] 的调用者传入 GSS_C_NO_CHANNEL_BINDINGS [RFC2744] 作为通道绑定，然后 接受者可以忽略发起者提供的任何通道绑定， 即使发起者确实传入了通道绑定，也会返回成功。
和“所有主要的 krb5 实现者都实现了这个 'MAY'”。如果发起者提供通道绑定，JGSS 似乎要求接受者提供通道绑定。此外，该修复程序在 Java 7 版本 64 中可用，并将向后移植到 Java 5 和 6，尽管 Java 6u18 没有 似乎有它，如 6851973 中报告的那样。
Extended Protection for Authentication 中看到的解决方法是设置
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\SuppressExtendedProtection
注册表设置为 0x02。这会禁用扩展保护。
【讨论】：