Elasticsearch 7.4 enable x-pack kerberos authentication,elasticsearch handle two times for one post request,and the first request authencation failed,why?, this is a kind of scheduler?

enable x-pack kerberos authentication,and i debug the elasticsearch source code with following method:

  1. kinit a kerberos principal;
    2.send a post request in the termination as follows:
    curl -XPOST --negotiate -u : "http://ip:9200/my_index/doc1/?pretty=true" -H 'Content-Type:application/json' -d '{"text":"hello world"}'
  2. check elasticsearch log and find the first handle throws exception “ElasticsearchSecurityException: missing authentication credentials for REST request [/my_index/doc1/?pretty=true]” and the twice handle throws exception "ElasticsearchSecurityException: action [indices:data/write/index] is unauthorized for user [solr/node1.hde.com@TESTES.COM]",i want to know why there are two times handler and the first hander throw "missing authentication",the detail log as follows:

org.elasticsearch.ElasticsearchSecurityException: missing authentication credentials for REST request [/my_index/doc1/?pretty=true]
at org.elasticsearch.xpack.core.security.support.Exceptions.authenticationError(Exceptions.java:18) ~[x-pack-core-7.4.0.jar:7.4.0]
at org.elasticsearch.xpack.core.security.authc.DefaultAuthenticationFailureHandler.createAuthenticationError(DefaultAuthenticationFailureHandler.java:154) ~[x-pack-core-7.4.0.jar:7.4.0]
at org.elasticsearch.xpack.core.security.authc.DefaultAuthenticationFailureHandler.missingToken(DefaultAuthenticationFailureHandler.java:104) ~[x-pack-core-7.4.0.jar:7.4.0]
at org.elasticsearch.xpack.security.authc.AuthenticationService$AuditableRestRequest.anonymousAccessDenied(AuthenticationService.java:729) ~[x-pack-security-7.4.0.jar:7.4.0]
at org.elasticsearch.xpack.security.authc.AuthenticationService$Authenticator.lambda$handleNullToken$19(AuthenticationService.java:474) ~[x-pack-security-7.4.0.jar:7.4.0]
at org.elasticsearch.xpack.security.authc.AuthenticationService$Authenticator.handleNullToken(AuthenticationService.java:479) ~[x-pack-security-7.4.0.jar:7.4.0]
.......................................
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:551) [netty-transport-4.1.38.Final.jar:4.1.38.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:511) [netty-transport-4.1.38.Final.jar:4.1.38.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918) [netty-common-4.1.38.Final.jar:4.1.38.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.38.Final.jar:4.1.38.Final]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0-internal]
[2019-12-18T14:34:54,440][INFO ][o.e.x.s.a.s.m.NativeRoleMappingStore] [node1.hde.com] The security index is not yet available - no role mappings can be loaded
[2019-12-18T14:34:54,440][DEBUG][o.e.x.s.a.s.m.NativeRoleMappingStore] [node1.hde.com] Security Index [.security] [exists: false] [available: false] [mapping up to date: true]
[2019-12-18T14:34:54,460][DEBUG][o.e.x.s.a.s.m.NativeRoleMappingStore] [node1.hde.com] Mapping user [UserData{username:solr/node1.hde.com@TESTES.COM; dn:null; groups:; metadata:{kerberos_user_principal_name=solr/node1.hde.com@TESTES.COM, kerberos_realm=TESTES.COM}; realm=kerb1}] to roles []

org.elasticsearch.ElasticsearchSecurityException: action [indices:data/write/index] is unauthorized for user [solr/node1.hde.com@TESTES.COM]

org.elasticsearch.ElasticsearchSecurityException: action [indices:data/write/index] is unauthorized for user [solr/node1.hde.com@TESTES.COM]
at org.elasticsearch.xpack.core.security.support.Exceptions.authorizationError(Exceptions.java:34) ~[?:?]
at org.elasticsearch.xpack.security.authz.AuthorizationService.denialException(AuthorizationService.java:585) ~[?:?]
at org.elasticsearch.xpack.security.authz.AuthorizationService.access$300(AuthorizationService.java:89) ~[?:?]
org.elasticsearch.xpack.security.authz.AuthorizationService.maybeAuthorizeRunAs(AuthorizationService.java:225) ~[?:?]
at org.elasticsearch.xpack.security.authz.AuthorizationService.lambda$authorize$1(AuthorizationService.java:191) ~[?:?]
at org.elasticsearch.action.ActionListener$1.onResponse(ActionListener.java:62) ~[elasticsearch-7.4.0.jar:7.4.0]
at org.elasticsearch.action.support.ContextPreservingActionListener.onResponse(ContextPreservingActionListener.java:43) ~[elasticsearch-7.4.0.jar:7.4.0]
at org.elasticsearch.xpack.security.authz.RBACEngine.lambda$resolveAuthorizationInfo$1(RBACEngine.java:117) ~[?:?]


at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918) [netty-common-4.1.38.Final.jar:4.1.38.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.38.Final.jar:4.1.38.Final]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0-internal]

This is common with Kerberos. The Kerberos authentication process typically requires sending a challenge to the client to tell it that Kerberos authentication is supported, and then the client retries the request with a Kerberos ticket.

Some clients might support a configuration that causes it to send the ticket up front

This mean that your authentication is working, but you have not mapped your Kerberos user to the correct roles to grant them access to write to this index.
You should look at the role mapping API or authorization_realms in the ES docs in order to solve this.

Many thanks for your reply, that is to say the post request don't take authentication header first time and x-pack or kdc trigger the client retries, and the retry request take the authentication header? if can i simulate this scene and to trigger the client retries?

I'm sorry, I don't really understand the question.

Kerberos over HTTP uses "SPNEGO".
The flow roughly looks like:

  1. Browser sends a request
  2. Server returns 401 Unauthorized with a WWW-Authenticate: Negotiate response header.
  3. Browser obtains a Kerberos ticket
  4. Browser retries request with a Authorization: Negotiate <based64-encoded-kerberos-ticket> request header
  5. Server validates ticket (athuenticates the user)
  6. Server checks whether the user is allowed to access the resource

You can see the full detail in this blog post, if you're interested.

You are seeing 2 requests because of steps 1 and 4.
Your client might support "pre-emptive authentication" in which case, it will skip steps 1 & 2 and jump straight to obtaining a Kerberos ticket.

The other error you are seeing is due to step 6. This user does not have access to perform the request

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.