elasticsearch Kibana中配置为使用SPNEGO的缺陷令牌

环境：

• CentOS 7
• 活动目录
• Elasticsearch和Kibana 7.9.3
• 在ES中配置的领域：Kerberos和AD
• Kerberos授权\u域：AD

ES群集在主节点和数据节点上使用键选项卡进行设置。我可以运行

curl--congregate-u:https://master-fqdn:9200/_security/_authenticate?pretty

aginst所有节点，并从AD获取一个漂亮的JSON描述用户和组。我可以在任何有Kerberos会话的Windows或Linux主机上执行此操作

Kibana是用

xpack.security.authc.providers:
  kerberos.kerberos1:
    order: 0
    description: "Log in with kerberos"

Kibana服务器已在kerberos域中注册（所有计算机都已注册）。时间同步和反向查找正在工作

在Linux和Windows上使用Firefox时（在about:config中设置

network.congotiate auth.trusted URI

后），它会发送带有SPNEGO数据的

Authorization:congotiate

头，就像curl一样。但是这里我得到了

GSSException：检测到有缺陷的令牌。GSSHeader在ES日志中未找到正确的标签

，并且未经Kibana授权的401。在Kibana日志中我得到了

SPNEGO is supported by the backend
Re-initiating SPNEGO handshake
Authentication attempt failed: Unauthorized

我已经使用JVM命令行选项为ES激活了krb5和spnego调试。当我运行

curl--congregate

时，我在日志中看到很多Kerberos输出，但是当Kibana reuqest失败时，它是无声的。我只在ES日志中看到GSSException堆栈跟踪。在我看来，在尝试提取SPNEGO令牌时，它似乎很早就失败了

这不是NTLM（当您看到“有缺陷的令牌”时的常见错误），因为我在上得到了相同的错误Firefox@Linux这个标记看起来和我用curl得到的类似

是否可以将原始http请求记录到ES中？要把交通从Kibana分流到ES是很不容易的。我想应该发生的是Kibana将

Authorization

头转发给ES

需要采取其他调试步骤吗？

解决了这个问题

您需要使用Kibana主机（HTTP/Kibana）的FQDN向主节点Kerberos id添加SPN-fqdn@REALM)

或者，您可以将ES协调节点安装到Kibana服务器

这两种方法都实现了相同的目标：ES节点需要接受为HTTP/kibana创建的SPNEGO令牌-fqdn@REALM.

Elastic将修复文档：