LDAP module : feedback, questions, and issues

Hello,

Here I come back with some feedback from my tests (es 2.4.5 , kibana 4.6.4, RoR 15.1 :slight_smile:) :

First, nice work , it is top feature.
I just had to change some stuff in configuration because I am using some MS ldap.
I also tested on basic authentication, not with kibana plugin.

The points I think need to be improved (or I was not able to fix by myself) :
1- Using a username formatted like “DOMAIN\toto” generates an error in logs, regarding parsing username.

[2017-06-27 13:31:11,350][ERROR][plugin.readonlyrest.ldap.unboundid] LDAP getting user operation failed
LDAPException(resultCode=87 (filter error), errorMessage=‘Invalid hex character ‘t’ encountered at position 12.’)
at com.unboundid.ldap.sdk.Filter.readEscapedHexString(Filter.java:1905)
at com.unboundid.ldap.sdk.Filter.create(Filter.java:1681)

In my opinion, this should be escaped, or else a parse should be done to ignore characters from 0 to the "" included.
In the futur, it could be an idea to use this part to identify which domain the user belong to, and then to test against.

2- username/password for ldap account to connect to ldap server are stored in clear in elasticsearch.yml
This point should be addressed in a futur step.

3- If in the case of one of ldap server is not reachable, elasticsearch will refuse to start.

[2017-06-28 15:26:17,924][ERROR][bootstrap ] Guice Exception: org.elasticsearch.plugin.readonlyrest.ldap.LdapClientException$InitializationException: LDAP connection problem
Likely root cause: java.net.UnknownHostException: superdc03.enovos.root.corp

in my opinion, a warning should be raised, but it should not prevent Es to start :
My opinion is we should be able to mix RoR local authentication/authorization, and ldap authentication/authorization.
If ldap(s) are not reachable, they should be skipped.
4- If in the case of credential are wrong for a ldap configuration, elasticsearch refuses to start.

in my opinion, a warning should be raised, but it should not prevent Es to start :
My opinion is we should be able to mix RoR local authentication/authorization, and ldap authentication/authorization.
If ldap(s) are not reachable or not testable, they should be skipped.

5- I see that ldap tcp session are established permanently. I could not test what happens if ldap connection is lost and the ldap server remains unreachable.
I tested by cutting out local network of ES, but no message came in log, and was able to woke RoR. (this could be a good result, it seems (behavior) RoR is bypassing ldap authentication and working only with lcoal account)
More test must be done.

6- I see that nested groups are not supported , same with users (forest wide) :
I mean :
ldap connector defined to domain A
having a local group in domain A
having a domain B user in the domain A local group.
well it is unable to authenticate in RoR
here a discussion about that kind of point, in another project.

7- To workaround the point 5 , I have to create 2 ldaps entries, one for domain A, and one for domain B, and I have to duplicate the RoR block , and to change ldap_authorization and ldap_authentication entries.
it is not a problem with 2-3 domain, but here with 14 domains, it could be … mmmh you can imagine.
maybe some improvement can be analysed.

8- Error message regarding ldap initialisation, in logs are not enough explicit : in fact, I have the message like invalid credential, but I do not know which one of ldap blocks is generating the issue…

9- Questions : I did not find how to make working ldap authentication by group membership.
In fact, using Microsoft active directory, does not contain attribute uid and unique_member.
then for now , I am able to login when using a username, against a user in an OU.
here my example of configuration.

- name: ADldap
  host: "FQDNOfAD"
  port: 389
  ssl_enabled: false
  ssl_trust_all_certs: true
  bind_dn: "CN=svc_elk_ldap,OU=Service_Account,OU=Admin,DC=xxx,DC=xxx,DC=xxx"
  bind_password: "blahblah"
  search_user_base_DN: "OU=ELK,OU=Service_Account,DC=xxx,DC=xxx,DC=xxx"
  user_id_attribute: "sAMAccountName"
  search_groups_base_DN: "OU=ELKG,OU=Service_Account,DC=xxx,DC=xxx,DC=xxx"
  unique_member_attribute: "member"
  connection_pool_size: 10
  connection_timeout_in_sec: 10
  request_timeout_in_sec: 10
  cache_ttl_in_sec: 60

the user tries to login using is accountname toto.r

in ldap query against a group, my result is :
member : CN=Toto Robert TheBest,OU=Test_purpose,OU=users,DC=xxx,DC=xxx,DC=xxx

of course it does not work.

10- special characters in password prevent the module to run correctly. ( aka , ; : @# / \ )
these should be escaped. to easier the operation, I would suggest to work in other way : Escape everything except alphanumeric ( because of german character, russian character, and last but not least, asian character…)

regarding point 10 , I found this at oracle , I dunno if it can help , but maybe the last part of document
http://docs.oracle.com/javase/jndi/tutorial/beyond/names/syntax.html

so, for now, that’s enough :slight_smile: keeping testing

Well, it seems I need help to configure, it does not work fine on my side.

I had in mind to give elastic access to users by having them in a Active directory group.
I also asked to other users on Github to see how they dealed.

Maybe it is related to my special version 15.1 ?

here my RoR block :

    - name: elkg test LAB (read)
      ldap_authentication: "srvldap"
      ldap_authorization:
        name: "srvldap"
        groups: ["L_elkg_test_vcsa6_R"]
      type: allow
      kibana_access: ro
      indices: ["<no-index>", "watcher", "watcher_alarms", ".kibana*", "log_lu_ei_sys_vcsa6*", "home"]
    ldaps:

    - name: srvldap
      host: "srvldap.root.corp"
      port: 389
      ssl_enabled: false
      ssl_trust_all_certs: true
      bind_dn: "CN=elk_account_ldap,OU=Service_Account,DC=srvldap,DC=root,DC=corp"
      bind_password: "pouetpouet"
      search_user_base_DN: "DC=srvldap,DC=root,DC=corp"
      user_id_attribute: "sAMAccountName"
      search_groups_base_DN: "OU=ELK,OU=LAB,DC=srvldap,DC=root,DC=corp"
      unique_member_attribute: "member"
      connection_pool_size: 10
      connection_timeout_in_sec: 10
      request_timeout_in_sec: 10
      cache_ttl_in_sec: 60      

I had in mind to obtain this behavior :
Users belonging to group L_elkg_test_vcsa6_R (CN=L_elkg_test_vcsa6_R,OU=ELK,OU=LAB,DC=srvldap,DC=root,DC=corp) would only match to the block, and gets access to kibana ro, indices “”, “watcher”, “watcher_alarms”, “.kibana*”, “log_lu_ei_sys_vcsa6*”, “home” etc.

Currently the group has no member inside, but all users in ldaps srvldap are able and match the block…

what did I do wrong in my block rule ? or I should not do like this ?

@ld57 were you able to resolve this issue? Looks like the issue that I raised is similar to the one that is mentioned by you. I am trying to use group membership as well.

Hi @askids,

yep it worked on my side.

but it was with an old version.
I will implement in a short delay the updated version of RoR, and will enable ldaps.

also, I guess I still have my configuration on my test server, I ll give a check on it.

let me just wait for the updated version of RoR.