No Kibana prompt with "401"

For some reason I can’t seem to get Kibana working with ReadonlyREST. My kibana.stderr log shows a number of the following messages, and Kibana is not prompting me to enter any user credentials. Not sure what I’m doing wrong.

Unhandled rejection Authentication Exception :: {"path":"/_xpack","statusCode":401,"response":"Forbidden by ReadonlyREST ES plugin","wwwAuthenticateDirective":"Basic"}
    at respond (/usr/share/kibana/node_modules/elasticsearch/src/lib/transport.js:295:15)
    at checkRespForFailure (/usr/share/kibana/node_modules/elasticsearch/src/lib/transport.js:254:7)
    at HttpConnector.<anonymous> (/usr/share/kibana/node_modules/elasticsearch/src/lib/connectors/http.js:157:7)
    at IncomingMessage.bound (/usr/share/kibana/node_modules/elasticsearch/node_modules/lodash/dist/lodash.js:729:21)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:80:11)
    at process._tickDomainCallback (internal/process/next_tick.js:128:9)

My configuration is essentially the following:

  enable: true
  response_if_req_forbidden: Forbidden by ReadonlyREST ES plugin

    # allow someone directly logged in to the server to perform any action
    - name: "::LOCALHOST::"
      auth_key: name:password
      hosts: []
      type: allow

    # we trust Logstash; access allowed via HTTP auth
    - name: "::LOGSTASH::"
      auth_key: logstash:logstash
      type: allow
      actions: ["cluster:monitor/main", "indices:admin/types/exists", "indices:data/read/*", "indices:data/write/*", "indices:admin/template/*", "indices:admin/create"]
      indices: ["logs-*"]

    # we trust Kibana; access allowed via HTTP auth
    - name: "::KIBANA-SERVER::"
      auth_key: kibana:kibana
      type: allow
      verbosity: error # don't log successful requests

    # this is for read-write user access via LDAP
    - name: "::RW ACCESS::"
        name: "ldap1"
        groups: ["group_does_not_exist"]
      type: allow
      kibana_access: rw
      indices: [".kibana", ".kibana-devnull", "logs-*"]

    # this is for read-only user access via LDAP
    - name: "::RO ACCESS::"
        name: "ldap1"
        groups: ["group_does_not_exist"]
      type: allow
      kibana_access: ro
      indices: [".kibana", ".kibana-devnull", "logs-*"]

    - name: ldap1
      host: ""
      port: 389
      ssl_enabled: false
      ssl_trust_all_certs: true
      search_user_base_DN: "ou=Users,ou=xxx,dc=xxx,dc=com"
      user_id_attribute: "uid"
      search_groups_base_DN: "ou=ELK,dc=xxx,dc=com"
      unique_member_attribute: "uniqueMember"
      connection_pool_size: 10
      connection_timeout_in_sec: 10
      request_timeout_in_sec: 10
      cache_ttl_in_sec: 60

Thoughts? Thanks!

yeah the kibana_action macro-rule is designed to work with the vanilla Kibana (no x-pack). So if you intend to use x-pack you need to add extra blocks to let xpack stuff through.

The workflow should be:

  1. Run elasticsearch and Kibana as like you don’t have x-pack
  2. See the Elasticsearch logs, look for forbidden requests
  3. Write custom rules to let them through

Of course the additional rules should require the same ldap authentication requirements of the standard case.

OK, thank you. I guess that makes sense at a high level. I’m just not clear how to implement it in practice. Take, for example, this particular Authentication Exception.

  1. The “path” is listed as “/_xpack”. Does this mean I should add “_xpack” to the “indices”? I wouldn’t have thought so.

  2. If I’m getting a “401” error in the logs, shouldn’t Kibana be prompting with a login box? How else will the user be given an opportunity to enter credentials? (At this point Kibana and ReadonlyREST don’t even know the identity of the user. How can authentication/authorization occur when the user is never prompted?)


Hold on. I think I’ve maybe gotten to the bottom of some of my problems. I had a tiny mistake in my “elasticsearch.password” in kibana.yml. I fixed that and now I’m getting prompted for credentials in Kibana (as I would expect).

Amazing how a small mistake like that can cause so many problems. Computers should be more forgiving :slight_smile:

Sorry for wasting your time with this!

You have to start from a “forbidden” log line on the Elasticsearch side.

Grep your logs for “_xpack”, you will find a “forbidden” request information take note of the “ACT:” action, and make a new rule allowing that action.

The new rule will look identical to the previous one on the authentication side (same ldap stuff), but instead of the kibana_access macro, you’ll just put the action(s) being forbidden in the logs.

    - name: "::RO ACCESS::"
        name: "ldap1"
        groups: ["group_does_not_exist"]
      type: allow
      actions: ["the xpack action you discovered being rejected in the ES logs"]

Ah, that makes sense. Thanks for clarifying!

In this particular case it seems fixing the bad password has resolved the problem, but I’ll certainly keep this in mind if a similar issue occurs in future. Appreciate the help!

1 Like