Shield error. Authorization problem. [Even admin unable to access]

Elastic Stack Elasticsearch
1

Hi all,

Today I was trying out ES-beta2.
Gave a fresh extract. Installed shield and license.
Then edited the configs of ES. All the roles and role mappings with elasticsearch config.
[BTW I am using LDAP backend]

Then I started ES. Then I started Kibana 4.2.0-beta1

Kibana Says:

log [12:19:48.304] [info][status][plugin:statusPage] Status changed from uninitialized to green - Ready
log [12:19:48.311] [info][status][plugin:table_vis] Status changed from uninitialized to green - Ready
log [12:19:48.323] [info][listening] Server running at http://0.0.0.0:5601
log [12:19:48.561] [error][status][plugin:elasticsearch] Status changed from yellow to red - [security_exception] action [cluster:monitor/nodes/info] is una
uthorized for user [kibana]

ES says:

[2015-09-22 12:19:56,112][INFO ][rest.suppressed ] /_nodes Params: {settings_filter=shield.hide_settings,shield.ssl.,shield.authc.realms.ldap1.bind_dn
,shield.authc.realms.ldap1.bind_password,shield.authc.realms.ldap1.hostname_verification,transport.profiles.default.shield.}
ElasticsearchSecurityException[action [cluster:monitor/nodes/info] is unauthorized for user [kibana]]
at org.elasticsearch.shield.support.Exceptions.authorizationError(Exceptions.java:45)
at org.elasticsearch.shield.authz.InternalAuthorizationService.denialException(InternalAuthorizationService.java:296)
at org.elasticsearch.shield.authz.InternalAuthorizationService.denial(InternalAuthorizationService.java:270)

Tried a lot of stuff none is helping.
At last tried to go with curl to see if everything was working.

pranav is my admin account in ES.
Just see what happens.

user@system ~
$ curl -XGET pranav:secret@localhost:9200/
{
"name" : "Spike Freeman",
"cluster_name" : "elasticsearch",
"version" : {
"number" : "2.0.0-beta2",
"build_hash" : "91726c3f7cf57336f2f304a5cdc738db3b817234",
"build_timestamp" : "2015-09-14T14:58:02Z",
"build_snapshot" : false,
"lucene_version" : "5.2.1"
},
"tagline" : "You Know, for Search"
}

user@system ~
$ curl -XGET pranav:secret@localhost:9200/_count?pretty
{
"error" : {
"root_cause" : [ {
"type" : "security_exception",
"reason" : "action [indices:data/read/search] is unauthorized for user [pr
anav]"
} ],
"type" : "security_exception",
"reason" : "action [indices:data/read/search] is unauthorized for user [pran
av]"
},
"status" : 403
}

Even after giving all permission something is going wrong with permissions.
roles.yml

# All operations on all indices
admin:
 cluster: all
  indices:
    '*': all

Need help urgently. Please tell if you need any other details.

1 Like
3

Hey @skearns
Please look into this.

Thanks in advance. :+1:

4

Do you see any errors in your elasticsearch logs about invalid roles? Looking at the role you've pasted the indices line has an extra space, which could cause issues. I've corrected the spacing below:

# All operations on all indices
admin:
  cluster: all
  indices:
    '*': all

Since you are using LDAP, did you update the role mappings to map the admin role to your user? If you want to see what gets mapped, edit the config/logging.yml:

logger:
  ...
  index.search.slowlog: TRACE, index_search_slow_log_file
  index.indexing.slowlog: TRACE, index_indexing_slow_log_file

  shield.authc: TRACE

The shield.authc: TRACE is the only line you need to add under the logger section; the others are just from the default file.

5

Thank Jay for responding.

Indent was caused when editing in markdown, in the file it is correct...

Am gonna check for the logging trace will update here if i come against something.

Now feeling if this is a bug :bug: :beetle: or something.

6

Hello everyone.

I think I found out the problem. There has been a change in defining roles in roles.yml file.

So i re wrote the file in new format. Still the issue persists.
I guess, I am not writing roles properly.

Can anyone please give a full working roles.yml file for shield 2.0.0-beta2.

Thanks in advanced.

7

Hi Pranav,

The example file that comes with Shield 2.0 beta2 contains the new format, however the old format is also supported when you are not using field and document level security. Can you share your config files so we can take a look? If you do, please remember to remove any sensitive information.

-Jay

8

Hi Jay,
Pasting the roles files with just name changes as you asked..
Have a look.

#user Defined roles
role1:
  indices:
    'index1*':
      privileges: all

role2:
  indices:
    'index2*':
      privileges: all

# All cluster rights
# All operations on all indices
admin:
  cluster: all
  indices:
    '*':
      privileges: all

# monitoring cluster privileges
# All operations on all indices
power_user:
  cluster: monitor
  indices:
    '*':
      privileges: all

# Read-only operations on indices
user:
  indices:
    '*':
      privileges: read

# Defines the required permissions for transport clients
transport_client:
  cluster:
      - cluster:monitor/nodes/liveness
      #uncomment the following for sniffing
      #- cluster:monitor/state

# The required permissions for kibana 4 users.
kibana4:
  cluster: 
      - cluster:monitor/nodes/info
      - cluster:monitor/health 
  indices:
    '*':
      privileges: indices:admin/mappings/fields/get, indices:admin/validate/query, indices:data/read/search, indices:data/read/msearch, indices:admin/get
    '.kibana':
      privileges: indices:admin/exists, indices:admin/mapping/put, indices:admin/mappings/fields/get, indices:admin/refresh, indices:admin/validate/query, indices:data/read/get, indices:data/read/mget, indices:data/read/search, indices:data/write/delete, indices:data/write/index, indices:data/write/update, indices:admin/create

# The required permissions for the kibana 4 server
kibana4_server:
  cluster:
      - cluster:monitor/nodes/info
      - cluster:monitor/health
  indices:
    '.kibana':
      privileges: indices:admin/exists, indices:admin/mapping/put, indices:admin/mappings/fields/get, indices:admin/refresh, indices:admin/validate/query, indices:data/read/get, indices:data/read/mget, indices:data/read/search, indices:data/write/delete, indices:data/write/index, indices:data/write/update

# The required role for logstash users
logstash:
  cluster: indices:admin/template/get, indices:admin/template/put
  indices:
    'logstash-*':
      privileges: indices:data/write/bulk, indices:data/write/delete, indices:data/write/update, indices:data/read/search, indices:data/read/scroll, indices:create_index

Cheers and thanks.

9

The roles look correct to me. Lets try to narrow down the problem, pranav is a LDAP user correct? If so can you make a local user in the esusers realm with the admin role and test with this. This way we can see if the issue is with the roles or the role mapping.

10

Hey Jay,

I tried it with esusers. It works properly as expected. When the same is done with LDAP. Kibana is unable to start and ES gives:

[2015-09-23 17:21:45,604][INFO ][rest.suppressed          ] /_nodes Params: {settings_filter=shield.hide_settings,shield.ssl.*,shield.authc.realms.ldap1.bind_dn
,shield.authc.realms.ldap1.bind_password,shield.authc.realms.ldap1.hostname_verification,transport.profiles.default.shield.*}
ElasticsearchSecurityException[action [cluster:monitor/nodes/info] is unauthorized for user [kibana]]
        at org.elasticsearch.shield.support.Exceptions.authorizationError(Exceptions.java:45)
        at org.elasticsearch.shield.authz.InternalAuthorizationService.denialException(InternalAuthorizationService.java:296)
        at org.elasticsearch.shield.authz.InternalAuthorizationService.denial(InternalAuthorizationService.java:270)
        at org.elasticsearch.shield.authz.InternalAuthorizationService.authorize(InternalAuthorizationService.java:131)
        at org.elasticsearch.shield.action.ShieldActionFilter.apply(ShieldActionFilter.java:115)
        at org.elasticsearch.action.support.TransportAction$RequestFilterChain.proceed(TransportAction.java:99)
        at org.elasticsearch.action.support.TransportAction.execute(TransportAction.java:77)
        at org.elasticsearch.client.node.NodeClient.doExecute(NodeClient.java:58)
        at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:347)
        at org.elasticsearch.client.FilterClient.doExecute(FilterClient.java:52)
        at org.elasticsearch.rest.BaseRestHandler$HeadersAndContextCopyClient.doExecute(BaseRestHandler.java:83)
        at org.elasticsearch.client.support.AbstractClient.execute(AbstractClient.java:347)
        at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.execute(AbstractClient.java:835)
        at org.elasticsearch.client.support.AbstractClient$ClusterAdmin.nodesInfo(AbstractClient.java:915)
        at

Cut some lines at the end. Post didn't allow so much to be entered.

Thanks Jay. With your help I will crack this.

11

That tells us where to look. The next step is to setup the logging to trace like I posted above. Then why you try to authenticate as an LDAP user, look at the elasticearch log and you should see messages like:

the roles [<LIST OF ROLES>], are mapped from these [ldap] groups [<LIST OF LDAP GROUPS>]

This way we can see the the LDAP groups that are retrieved for your user and also the roles that have been mapped.

12

Hi Jay,

Using your steps and troubleshooting steps from https://www.elastic.co/guide/en/shield/current/troubleshooting.html

I did the instructed but didn't get any new lines in the logs or console.
What am I doing wrong?

13

Can you share your logging.yml file?

14

Hello J,

I found out the problem. It was a problem with LDAP groups.
Probably the new ES wants exact LDAP object classes to be in place for groups to work properly.

Thank you so much for the help. :beers:

15

can you explain what your fix was, maybe show what you had and then what worked.

Thanks,