是否可以执行可选的Kerberos身份验证？可选的SPNEGO Kerberos身份验证
我想要的是：如果客户端（浏览器）不在域上，它将被重定向到用户名/密码Web登录。否则它会执行SPNEGO做Kerberos身份验证。
如果我只是发送WWW-Authenticate：Negotiate头到一个非域浏览器，它只是没有做进一步的事情。
如果浏览器不知道如何进行身份验证，是否有一些选项可以告诉浏览器尝试不同的东西？还是必须在发送“WWW-Authenticate”标头之前确定用户是否属于域的一部分？
我还没有找到anynone谁已经公开解决这个问题，并在一个标准的方式。是的，如上所述，可以回退到Basic，但这对于认证方案不起作用，其涉及从CGI表单请求用户名和密码，其中，就浏览器看到的情况而言，您将回落到否如果Negotiate失败，则进行身份验证。也许这是暗示认证方案被破坏？我不知道。
我会先告诉你我所知道的。我们的网站实际上受到Cosign保护，所以我们遇到类似的问题：只有专门配置的机器才会响应WWW-Authenticate标题，因此默认情况下我们必须将所有用户发送到我们的Cosign登录页面。诀窍是Cosign服务器还允许通过身份验证的GSSAPI/Kerberos主机在不输入登录详细信息的情况下完成身份验证过程，但只能通过某种解决方法在某些浏览器上执行。
该解决方法仅由登录页面内的JavaScript块组成，该块尝试使用受SPNEGO保护的资源的HEAD;如果成功，该脚本会将浏览器重定向到同一页面的SPNEGO保护版本，该版本将授予适当的Cosign Cookie并完成该过程而不输入密码。如果浏览器缺少任何JavaScript，Kerberos支持或足够的凭据，则用户将照常看到共享登录页面。
所以，单独上述可能会作为你的问题的答案;个人虽然我认为这不够，接下来是更多的讨论...
上述似乎并不令人满意，因为它坚持任何连接的用户代理支持JavaScript（不太可能是文本 - 基于Web的浏览器和HTTP客户端库），或者知道我们重定向支持Kerberos的用户的任意路径（对于我们的站点没有硬编码的任何内容都没有用处）。我得出的结论是，可能有更好的解决方法，或者如果不是，标准应该存在差距。我的最佳实践建议是这样的：
SPNEGO进程的正常部分是客户端尝试检索其初始响应为HTTP 401但标头为WWW-Authenticate: Negotiate的页面。这是GSSAPI/Kerberised客户端正确响应的提示; “常规”客户端将只显示错误页面。也许解决方案是简单地修改Cosign服务器以提供人性化的登录页面作为此错误响应的一部分？
它可能在现成的Apache和模块在技术上很难，并且可能违背各种标准（或至少是原则）。我不是所涉及系统的专家，所以只能推测除非（或直到）我有机会尝试它......
另外发送WWW-Authenticate: Basic用户名/密码挑战。
我与OP有完全相同的问题，我想知道，如果在此期间有一个既定的解决方案。当从域外部访问登录页面时，Kerberos进程在收到401后停止在客户端。是否有一种方法（除gra格式描述的JavaScript hack外）并行地运行这两种认证方法？ –