环境:
ES 集群在主节点和数据节点上设置了 keytab。我可以运行
curl --negotiate -u : https://master-fqdn:9200/_security/_authenticate?pretty
aginst 所有节点并从 AD 中获取描述用户和组的漂亮 JSON。我可以在任何有 Kerberos session 的 Windows 或 Linux 主机上执行此操作。Kibana 设置为
xpack.security.authc.providers:
kerberos.kerberos1:
order: 0
description: "Log in with kerberos"
Kibana 服务器在 kerberos 域中注册(所有机器都在)。时间同步和反向查找正在工作。在 Linux 和 Windows 上使用 Firefox(在 about:config 中设置
network.negotiate-auth.trusted-uris
之后)时,它会发送 Authorization: Negotiate
带有 SPNEGO 数据的 header ,就像 curl 一样。但在这里我得到 GSSException: Defective token detected. GSSHeader did not find the right tag
在 ES 日志中和来自 Kibana 的 401 Unauthorized。在我得到的 Kibana 日志中SPNEGO is supported by the backend
Re-initiating SPNEGO handshake
Authentication attempt failed: Unauthorized
我已经使用 ES 的 JVM 命令行选项激活了 krb5 和 spnego 调试。当我运行 curl --negotiate
我在日志中看到很多 Kerberos 输出,但是当 Kibana reuqest 失败时它是静默的。我只在 ES 日志中看到 GSSException 堆栈跟踪。在我看来,它在尝试提取 SPNEGO token 时很早就失败了?这不是 NTLM(当您看到“有缺陷的 token ”时的常见错误),因为我在 Firefox@Linux 上遇到了同样的错误,并且该 token 看起来与我使用 curl 获得的类似。
是否可以记录进入 ES 的原始 http 请求? tcpdump 从 Kibana 到 ES 的流量是 TLS,所以不容易。我猜应该发生的是 Kibana 转发
Authorization
到 ES 的 header 。还有其他调试步骤吗?
最佳答案
解决了。
您需要使用 Kibana 主机的 FQDN (HTTP/kibana-fqdn@REALM) 将 SPN 添加到主节点 Kerberos id。
或者你可以在 Kibana 服务器上安装一个 ES 协调节点。
两种方式都实现了相同的目标:ES 节点需要接受为 HTTP/kibana-fqdn@REALM 创建的 SPNEGO token 。
Elastic 将修复文档:
https://github.com/elastic/kibana/issues/67089
关于elasticsearch - Kibana 中有缺陷的 token 配置为使用 SPNEGO,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/64681349/