LDAP - Authentication works, Authorization doesn't

Elastic Stack Elasticsearch
1

Hi
I am trying to validate a simple LDAP setup on ElasticSearch with the SHIELD plugin. My Kibana setup is configured to use a LDAP user which in turn is configured and mapped to a role in ElasticSearch's role_mapping.yml file and that role has a corresponding entry in the roles.yml file. I also turned on DEBUG/TRACE logging on ElasticSearch. I can see that my LDAP user is authenticated, however it fails authorization with the following messages:

==> /data/ES/logs/es.log <==
[2016-01-04 15:42:19,955][DEBUG][shield.authc.ldap        ] [dataless-node] authenticated user [ldapuser1], with roles [[]]

[2016-01-04 15:42:19,956][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 [ldapuser1]]
	at org.elasticsearch.shield.support.Exceptions.authorizationError(Exceptions.java:45)
	at org.elasticsearch.shield.authz.InternalAuthorizationService.denialException(InternalAuthorizationService.java:294)
	at org.elasticsearch.shield.authz.InternalAuthorizationService.denial(InternalAuthorizationService.java:268)
	at org.elasticsearch.shield.authz.InternalAuthorizationService.authorize(InternalAuthorizationService.java:129)
	at org.elasticsearch.shield.action.ShieldActionFilter.apply(ShieldActionFilter.java:105)
	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)
.
.
.
.

==> /data/ES/logs/shield-access.log <==
[2016-01-04 15:42:19,955] [dataless-node] [transport] [access_denied]	origin_type=[rest], origin_address=[x.x.x.x], principal=[ldapuser1], action=[cluster:monitor/nodes/info], request=[NodesInfoRequest]

It seems like my roles or role_mapping entries are not being considered.

My LDAP config in elasticsearch.yml:

shield:
  authc:
    realms:
      ldap1:
        type: ldap
        order: 0
        url: "ldap://xxxx.xxxx.xxxx.xxxx:yyyy"
        bind_dn: "uid=xxxx,ou=xxxx xxxx,o=xxxx.xxxx"
        bind_password: xxxx
        user_search:
          base_dn: "o=xxxx.xxxx"
          attribute: xxxx
        group_search:
          base_dn: "o=xxxx.xxxx"
        files:
          role_mapping: "/etc/elasticsearch/shield/role_mapping.yml"
        unmapped_groups_as_roles: false

My configured role in roles.yml:

# LDAP user role
 ldap_users:
   cluster: all
   indices:
     '*':
       privileges: all

My configured mapping in role_mapping:

ldap_users:
    - "cn=ldapuser1,ou=xxxx xxxx,o=xxxx.xxxx"

Appreciate any insight.

Thanks

2

This sounds very similar to the issue I'm currently discussing at Action indices:data/read/mget is unauthorized but privilege listed.

3

In your debug logs do you see a line like the following:

the roles [], are mapped from the user [<your user's dn>] for realm []

If so, does the DN match what you have in the role mapping file?

4

As a matter of fact, I do:

[2016-01-04 19:37:34,852][DEBUG][shield.authc.support ] [dataless-node] the roles [[]], are mapped from these [ldap] groups [[]] for realm [ldap/ldap1]

It seems to be looking for ldap groups instead of ldap users?

5

Shield always will map to both groups and users but the log statement is only shown when something is mapped to a user (we can improve this to show all the time for better logging in a future release). This means that there is a mismatch between your user DN in the file and the DN retrieved from LDAP.

6

Curious - if there is a mismatch in the user DN between what's retrieved and what's in the config, then shouldn't authentication fail too?
In the meanwhile, I'll work on the LDAP specifics. Thank you.

7

Authentication is succeeding because we search for the user with the attribute matching the username that has been provided and authenticate with using the matching entry's DN. The DN defined in the role_mapping.yml is not checked as part of authentication.