LDAP assistance

1

Can someone assist me with my LDAP configuration?

Notice that “groups” contains “group_does_not_exist”. Not surprisingly, this group does not exist on my LDAP server. In spite of this, though, it appears that the first (and only) access control rule is being used for all users.

If I simply execute the statement curl 'localhost:9200/_cat/indices?v' (even from an external machine), it returns a valid list of indexes. If I set “indexes” to “", all indices will be returned. But if I set “indexes” to "logs-”, then only the subset of indices are returned. This indicates to me that this rule is being used for authorization. Yet how is it being matched if the LDAP group doesn’t exist (and I’m not even specifying a user when executing the statement)?

What am I missing? Any help appreciated.

readonlyrest:
  enable: true
  response_if_req_forbidden: Forbidden by ReadonlyREST ES plugin

  access_control_rules:
    - name: Access control rule 1
      type: allow
      ldap_authentication: "ldap1"
      ldap_authorization:
        name: "ldap1"
        groups: ["group_does_not_exist"]
      indices: ["*"]

  ldaps:
    - name: ldap1
      host: "my_host.com"
      port: 389
      ssl_enabled: false
      ssl_trust_all_certs: true
      search_user_base_DN: "ou=Users,ou=xxxx,dc=xxxx,dc=com"
      user_id_attribute: "cn"
      search_groups_base_DN: "ou=ELK,dc=xxxx,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

Thanks,
Greg

2

Sorry about the lost indentation. Wish I knew how to preserve that correctly.

3

FYI, when I execute a GET x.x.x.x:9200/_cat/indices?v from Postman on my local machine it works and I get the following response. It seems to be matching the only access control rule. Just not sure how.

[2017-05-05T12:03:18,178][INFO ][o.e.p.r.a.ACL ] request: { ID:f79e32d9324645f5ab60324f5fbf9f15, TYP:IndicesStatsRequest, USR:null (?), BRS:true, ACT:indices:monitor/stats, OA:10.239.234.207, IDX:, MET:GET, PTH:/_cat/indices, CNT:<OMITTED, LENGTH=0>, HDR:Accept,Accept-Encoding,Accept-Language,Cache-Control,Connection,content-length,Host,Postman-Token,User-Agent, EFF:0, HIS:[Access control rule 1->], [Access control rule 1->[indices->true]] } matched block: Access control rule 1 match: true}

4

BTW, I’m using “ldap_authentication” and “ldap_authorization” in my configuration because I couldn’t get “ldap_auth” to work. (When I configure with “ldap_auth” I get endlessly repeating “SSL: Disabled” statements in the logs.) Maybe this is part of the issue.

5

Once I got my “ldap_auth” configuration to work (see Possible documentation issue 2), the rule now seems to correctly restrict access.

I’m guessing my use of “ldap_authentication” and “ldap_authorization” was incorrect. (If you can suggest what I did wrong, I’d be interested to know. Always want to learn.)

Thanks,
Greg

6

the busy loop is something that happens in ES when there’s an exception in the handlers setup phase (which is when ROR reads the settings). Not much we can do there, except defer the settings read to a separate thread. But ideally settings parsers should not throw unhandled exceptions.

Do you have this issue with 1.15.0 ?