故障排除安全问题

验证与用户关联的角色名称是否与roles.yml文件中定义的角色匹配。您可以使用elasticsearch-users工具列出所有用户。任何未知角色都会被标记为*。

bin/elasticsearch-users list
rdeniro        : admin
alpacino       : power_user
jacknich       : monitoring,unknown_role* 

有关此命令的更多信息，请参阅 elasticsearch-users 命令。

如果你正在向LDAP进行身份验证，一些配置选项可能会导致这个错误。

为了帮助追踪这些可能性，启用额外的日志记录以进一步进行故障排除。 您可以通过配置以下持久设置来启用调试日志记录：

PUT /_cluster/settings
{
  "persistent": {
    "logger.org.elasticsearch.xpack.security.authc": "debug"
  }
}

或者，您可以将以下行添加到ES_PATH_CONF中的log4j2.properties配置文件的末尾：

logger.authc.name = org.elasticsearch.xpack.security.authc
logger.authc.level = DEBUG

请参阅配置日志级别以获取更多信息。

成功的身份验证应生成列出组和角色映射的调试语句。

症状:

Kibana中的身份验证失败，并且在Elasticsearch日志中打印了以下错误：

Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=saml1,
assertionConsumerServiceURL=https://my.kibana.url/api/security/saml/callback}]

解决方案：

为了启动SAML认证，Kibana需要知道它应该从Elasticsearch中配置的SAML领域中使用哪一个。您可以使用xpack.security.authc.providers.saml..realm设置在Kibana中显式设置SAML领域名称。它必须与在Elasticsearch中配置的SAML领域名称匹配。

如果你遇到上述错误，可能意味着你的 Kibana 配置中的 xpack.security.authc.providers.saml..realm 值是错误的。请确认它与 Elasticsearch 中配置的 realm 名称匹配，该名称是 Elasticsearch 配置中 xpack.security.authc.realms.saml. 之后的字符串。

症状:

Kibana中的身份验证失败，并且在Elasticsearch日志中打印了以下错误：

Authentication to realm saml1 failed - Provided SAML response is not valid for realm
saml/saml1 (Caused by ElasticsearchSecurityException[Conditions
[https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company....ple.com/]
do not match required audience
[https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com]])

解决方案：

我们收到一个SAML响应，该响应是发给另一个SAML服务提供商的。 这通常意味着在elasticsearch.yml中配置的SAML服务提供商实体ID（sp.entity_id）与SAML身份提供商文档中配置的SAML服务提供商实体ID不匹配。

要解决此问题，请确保 Elasticsearch 中的 SAML 领域和 IdP 都配置了相同的字符串作为服务提供商的 SAML 实体 ID。

在Elasticsearch日志中，在异常消息（上方）之前，还会有一个或多个形式为INFO级别的日志消息。

Audience restriction
[https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com/]
does not match required audience
[https://5aadb9778c594cc3aad0efc126a0f92e.kibana.company.example.com]
(difference starts at character [#68] [/] vs [])

此日志消息可以帮助确定从IdP接收到的值与在Elasticsearch中配置的值之间的差异。只有在两个受众标识符被认为是相似的情况下，描述这两个标识符之间差异的括号中的文本才会显示。

症状:

Kibana中的身份验证失败，并且在Elasticsearch日志中打印了以下错误：

Cannot find metadata for entity [your:entity.id] in [metadata.xml]

解决方案：

我们无法在配置的元数据文件（metadata.xml）中找到SAML实体ID your:entity.id 的元数据。

症状:

Kibana中的身份验证失败，并且在Elasticsearch日志中打印了以下错误：

unable to authenticate user []
for action [cluster:admin/xpack/security/saml/authenticate]

解决方案：

此错误表明 Elasticsearch 未能处理传入的 SAML 认证消息。由于无法处理该消息，Elasticsearch 不知道待认证用户是谁，因此使用 占位符代替。要诊断 实际 问题，您必须检查 Elasticsearch 日志以获取更多详细信息。

症状:

Kibana中的身份验证失败，并且在Elasticsearch日志中打印了以下错误：

Authentication to realm  failed - SAML Attribute [] for
[xpack.security.authc.realms.saml..attributes.principal] not found in saml attributes
[=, =, ...] or NameID [ NameID(format)=value ]

解决方案：

此错误表明 Elasticsearch 在身份提供者发送的 SAML 响应中未能找到必要的 SAML 属性。在此示例中，Elasticsearch 的配置如下：

xpack.security.authc.realms.saml..attributes.principal: AttributeName0

此配置意味着 Elasticsearch 期望在 SAML 响应中找到一个名为 AttributeName0 的 SAML 属性或具有适当格式的 NameID，以便 将其映射到 principal 用户属性。principal 用户属性是强制性的，因此如果无法进行此映射，则身份验证将失败。

如果您正在尝试映射一个NameID，请确保预期的NameID格式与发送的格式匹配。 有关更多详细信息，请参阅特殊属性名称。

如果您尝试映射一个SAML属性，而该属性不在错误消息的列表中，这可能意味着您拼错了属性名称，或者IdP没有发送这个特定的属性。您可能可以使用列表中的另一个属性来映射到principal，或者咨询您的IdP管理员以确定是否可以发送所需的属性。

症状:

Kibana中的身份验证失败，并且在Elasticsearch日志中打印了以下错误：

Cannot find [{urn:oasis:names:tc:SAML:2.0:metadata}IDPSSODescriptor]/[urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect] in descriptor

解决方案：

此错误表明您的身份提供者的SAML元数据不包含绑定为HTTP-Redirect（urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect）的端点。Elasticsearch仅支持SAML身份验证请求的HTTP-Redirect绑定（并且不支持HTTP-POST绑定）。请咨询您的IdP管理员，以启用至少一个支持HTTP-Redirect绑定的，并更新您的IdP SAML元数据。

症状:

Kibana中的身份验证失败，并且在Elasticsearch日志中打印了以下错误：

Authentication to realm my-saml-realm failed -
Provided SAML response is not valid for realm saml/my-saml-realm
(Caused by ElasticsearchSecurityException[SAML Response is not a 'success' response:
 The SAML IdP did not grant the request. It indicated that the Elastic Stack side sent
 something invalid (urn:oasis:names:tc:SAML:2.0:status:Requester). Specific status code which might
 indicate what the issue is: [urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy]]
)

解决方案：

这意味着SAML身份提供者未能对用户进行身份验证，并向服务提供者（Elastic Stack）发送了一个SAML响应，表明了这一失败。消息将传达SAML身份提供者认为问题是出在服务提供者（Elastic Stack）还是身份提供者本身，并且随后的特定状态代码非常有用，因为它通常指示了潜在的问题。特定错误代码的列表在SAML 2.0核心规范 - 第3.2.2.2节中定义，最常遇到的错误代码包括：

症状:

Kibana中的身份验证失败，并且在Elasticsearch日志中打印了以下错误：

The XML Signature of this SAML message cannot be validated. Please verify that the saml
realm uses the correct SAMLmetadata file/URL for this Identity Provider

解决方案：

这意味着 Elasticsearch 未能验证身份提供者发送的 SAML 消息的数字签名。Elasticsearch 使用 SAML 元数据中包含的身份提供者的公钥来验证身份提供者使用其对应的私钥创建的签名。未能验证的原因可能有多种：

症状:

由于启用了 SAML，用户无法使用本地用户名和密码登录 Kibana。

解决方案：

如果您希望用户能够使用本地凭据进行身份验证，除了使用SAML领域进行单点登录外，您必须在Kibana中启用basic authProvider。该过程记录在SAML指南中

<span class="strong

Elasticsearch 正在运行 HTTPS，但命令未能检测到它并返回以下错误：

无法连接到 elasticsearch 节点。
java.net.SocketException: 来自服务器的文件意外结束
...
错误：无法连接到位于
http://127.0.0.1:9200/_security/_authenticate?pretty 的 elasticsearch。
URL 是否正确且 elasticsearch 正在运行？

SSL/TLS 已配置，但无法建立信任。该命令返回以下错误：

到
https://127.0.0.1:9200/_security/_authenticate?pretty 的 SSL 连接失败：
sun.security.validator.ValidatorException:
PKIX 路径构建失败：
sun.security.provider.certpath.SunCertPathBuilderException:
无法找到请求目标的有效证书路径
请检查 xpack.security.http.ssl 下的 elasticsearch SSL 设置。
...
错误：无法在
https://127.0.0.1:9200/_security/_authenticate?pretty 建立到 elasticsearch 的 SSL 连接。

命令失败是因为主机名验证失败，导致出现以下错误：

到
https://idp.localhost.test:9200/_security/_authenticate?pretty 的 SSL 连接失败：
java.security.cert.CertificateException:
未找到与 elasticsearch.example.com 匹配的主题备用 DNS 名称。
请检查 xpack.security.http.ssl 下的 elasticsearch SSL 设置。
...
错误：无法在
https://elasticsearch.example.com:9200/_security/_authenticate?pretty 建立到 elasticsearch 的 SSL 连接。