# Empty file path for searchguard.ssl.transport.truststore\_filepath **URL:** \ **Category:** Search Guard\ **Created:** [February 18, 2018, 5:03am UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809 "2018-02-18T05:03:24Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [February 18, 2018, 5:03am UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/1 "2018-02-18T05:03:24Z")
Hello, I have just started playing with Search Guard and got stuck configuring LDAP. First I installed the demo. It worked OK except I do not see “Tenants” tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: [kibana.log](https://forum.search-guard.com/uploads/short-url/kbOipVaGQsSGjZER1ZZiAi1uHhI.log) (139 KB) [es.log](https://forum.search-guard.com/uploads/short-url/gqxlDP3WT4C2O9rtmDYgzvE8jP2.log) (34.5 KB) [elasticsearch.yml](https://forum.search-guard.com/uploads/short-url/cXie0v9rP7rQ2fljnp4HLrBlsoq.yml) (4.08 KB) [sg\_config.yml](https://forum.search-guard.com/uploads/short-url/jFwzWieh0BLfTx3QnhqAFQJXRKU.yml) (9.55 KB) ![](https://us1.discourse-cdn.com/flex019/uploads/search_guard/original/1X/d36f57f607d05ee0b4acc7c6010a6ff61cc074f8.png) ![](https://us1.discourse-cdn.com/flex019/uploads/search_guard/original/1X/293ed506438e52f534d0d9e7c768f9fe64c4df98.png) ![](https://us1.discourse-cdn.com/flex019/uploads/search_guard/original/1X/9acc1b99279245ecd2fcdb3fcb21c79f7b61fa60.png) ![](https://us1.discourse-cdn.com/flex019/uploads/search_guard/original/1X/266b213b3a520adf8e21f5c10d05dff6a0b5ac76.png) ![](https://us1.discourse-cdn.com/flex019/uploads/search_guard/original/1X/268753c0e8e021af4962174f569efc85cd9d07f4.png) > **···** > > ==== > > Unable to connect to ldapserver 128.135.112.111:389 due > to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > ==== > > How to fix it? > > Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b “dc=rcc,dc=uchicago,dc=edu” > > from the host I am running ES on works fine. > > Once I’ll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. > > What options do I need to specify to > > === > > from elasticsearch import Elasticsearch > > es = Elasticsearch() > > === > > to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > Thank you, > > Igor > > ===================== > > When asking questions, please provide the following information: > > - Search Guard and Elasticsearch version > > 6.2.1 > > - Installed and used enterprise modules, if any > > Elasticsearch, Kibana, Search Guard > > - JVM version and operating system version > > 1.8.0\_121 > > CentOS 7.2 > > - Search Guard configuration files > > Attached > > - Elasticsearch log messages on debug level > > Attached > > - Other installed Elasticsearch or Kibana plugins, if any > > None > > ======================= ---
**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\ **Post date:** [February 19, 2018, 10:54am UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/2 "2018-02-19T10:54:05Z")
From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: enable\_ssl: true verify\_hostnames: true This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: enable\_ssl: false verify\_hostnames: false > **···** > > On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, ivy2@uchicago.edu wrote: > > > Hello, > > > > > > I have just started playing with Search Guard and got stuck configuring LDAP. > > > > > > First I installed the demo. It worked OK except I do not see “Tenants” tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > > > > > Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > > ==== > > > Unable to connect to ldapserver [128.135.112.111:389](http://128.135.112.111:389) due > > to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > > ==== > > > > > > How to fix it? > > > Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > > > > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b “dc=rcc,dc=uchicago,dc=edu” > > > from the host I am running ES on works fine. > > > > > > Once I’ll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. > > > What options do I need to specify to > > > === > > > from elasticsearch import Elasticsearch > > > > es = Elasticsearch() > > > > === > > > to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > > > > > Thank you, > > > Igor > > > > > > > > > ===================== > > > When asking questions, please provide the following information: > > > - Search Guard and Elasticsearch version > > > > > > 6.2.1 > > > > > > - Installed and used enterprise modules, if any > > > > > > Elasticsearch, Kibana, Search Guard > > > > > > - JVM version and operating system version > > > > > > 1.8.0\_121 > > > CentOS 7.2 > > > > > > - Search Guard configuration files > > > > > > Attached > > > > > > - Elasticsearch log messages on debug level > > > > > > Attached > > > > > > - Other installed Elasticsearch or Kibana plugins, if any > > > > > > None > > > ======================= ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [February 19, 2018, 5:38pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/3 "2018-02-19T17:38:23Z")
Hi Jochen, After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > **···** > > ========= > > No password given for bind\_dn cn=admin,dc=rcc,dc=uchica > go,dc=edu. Will try to authenticate anonymously to ldap > > # [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > Thank you, > > Igor > > On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > > From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > > enable\_ssl: true > > > verify\_hostnames: true > > > > > > This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > > > > > However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > > > > > enable\_ssl: false > > > verify\_hostnames: false > > > > > > > > > > > > On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv…@uchicago.edu wrote: > > > > Hello, > > > > > > > > I have just started playing with Search Guard and got stuck configuring LDAP. > > > > > > > > First I installed the demo. It worked OK except I do not see “Tenants” tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > > > > > > > Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > > > ==== > > > > Unable to connect to ldapserver [128.135.112.111:389](http://128.135.112.111:389) due > > > to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > > > ==== > > > > > > > > How to fix it? > > > > Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > > > > > > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b “dc=rcc,dc=uchicago,dc=edu” > > > > from the host I am running ES on works fine. > > > > > > > > Once I’ll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. > > > > What options do I need to specify to > > > > === > > > > from elasticsearch import Elasticsearch > > > > > > es = Elasticsearch() > > > > > > === > > > > to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > > > > > > > Thank you, > > > > Igor > > > > > > > > > > > > ===================== > > > > When asking questions, please provide the following information: > > > > - Search Guard and Elasticsearch version > > > > > > > > 6.2.1 > > > > > > > > - Installed and used enterprise modules, if any > > > > > > > > Elasticsearch, Kibana, Search Guard > > > > > > > > - JVM version and operating system version > > > > > > > > 1.8.0\_121 > > > > CentOS 7.2 > > > > > > > > - Search Guard configuration files > > > > > > > > Attached > > > > > > > > - Elasticsearch log messages on debug level > > > > > > > > Attached > > > > > > > > - Other installed Elasticsearch or Kibana plugins, if any > > > > > > > > None > > > > ======================= ---
**Author:** ![jkressin](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/jkressin/32/9_2.png) [@jkressin](https://forum.search-guard.com/u/jkressin)\ **Post date:** [February 19, 2018, 8:44pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/4 "2018-02-19T20:44:17Z")
Yes, usually you need a user (in LDAP terminology: bind\_dn) and password to talk to an LDAP server. But this depends on how your LDAP is configured actually: If it allows anonymous (usually read-only) access then you can skip the bind\_dn and password section if the sg\_config LDAP configuration. Search Guard will then try to access the server without bind\_dn and password. But if your LDAP server requires authentication, then you need to add the bind\_dn and password. This depends on what server you user and how it is configured. > **···** > > On Monday, February 19, 2018 at 6:38:23 PM UTC+1, ivy2@uchicago.edu wrote: > > > Hi Jochen, > > After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > > ========= > > > No password given for bind\_dn cn=admin,dc=rcc,dc=uchica > > go,dc=edu. Will try to authenticate anonymously to ldap > > > > # [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > > Thank you, > > > Igor > > > > > > On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > > > > From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > > > enable\_ssl: true > > > > verify\_hostnames: true > > > > > > > > This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > > > > > > > However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > > > > > > > enable\_ssl: false > > > > verify\_hostnames: false > > > > > > > > > > > > > > > > On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv…@uchicago.edu wrote: > > > > > Hello, > > > > > > > > > > I have just started playing with Search Guard and got stuck configuring LDAP. > > > > > > > > > > First I installed the demo. It worked OK except I do not see “Tenants” tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > > > > > > > > > Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > > > > ==== > > > > > Unable to connect to ldapserver [128.135.112.111:389](http://128.135.112.111:389) due > > > > to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > > > > ==== > > > > > > > > > > How to fix it? > > > > > Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > > > > > > > > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b “dc=rcc,dc=uchicago,dc=edu” > > > > > from the host I am running ES on works fine. > > > > > > > > > > Once I’ll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. > > > > > What options do I need to specify to > > > > > === > > > > > from elasticsearch import Elasticsearch > > > > > > > > es = Elasticsearch() > > > > > > > > === > > > > > to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > > > > > > > > > Thank you, > > > > > Igor > > > > > > > > > > > > > > > ===================== > > > > > When asking questions, please provide the following information: > > > > > - Search Guard and Elasticsearch version > > > > > > > > > > 6.2.1 > > > > > > > > > > - Installed and used enterprise modules, if any > > > > > > > > > > Elasticsearch, Kibana, Search Guard > > > > > > > > > > - JVM version and operating system version > > > > > > > > > > 1.8.0\_121 > > > > > CentOS 7.2 > > > > > > > > > > - Search Guard configuration files > > > > > > > > > > Attached > > > > > > > > > > - Elasticsearch log messages on debug level > > > > > > > > > > Attached > > > > > > > > > > - Other installed Elasticsearch or Kibana plugins, if any > > > > > > > > > > None > > > > > ======================= ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [February 19, 2018, 10:00pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/5 "2018-02-19T22:00:54Z")
Is there a way to figure out how my server is configured by using for example 'ldapsearch' or some other tool? I looked into a working java program that creates a web page where users can type their credentials and get access via LDAP to our system and at first glance I do not see that it is using any password to query LDAP server (except for the credentials of the user that tries to login): > **···** > > On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin \ wrote: > > > Yes, usually you need a user (in LDAP terminology: bind\_dn) and password > > to talk to an LDAP server. But this depends on how your LDAP is configured > > actually: If it allows anonymous (usually read-only) access then you can > > skip the bind\_dn and password section if the sg\_config LDAP configuration. > > Search Guard will then try to access the server without bind\_dn and > > password. But if your LDAP server requires authentication, then you need to > > add the bind\_dn and password. This depends on what server you user and how > > it is configured. > > # ==========             environment.put(javax.naming.Context.PROVIDER\_URL, "ldaps:// ldap.uchicago.edu");             environment.put(javax.naming.Context.SECURITY\_AUTHENTICATION, "simple");             environment.put(javax.naming.Context.SECURITY\_PRINCIPAL, usernameFormatted);             environment.put(javax.naming.Context.SECURITY\_CREDENTIALS, password);             DirContext ctx = new InitialDirContext(environment);             SearchControls controls = new SearchControls();             controls.setSearchScope(SearchControls.SUBTREE\_SCOPE);             NamingEnumeration\ results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls); > > # Here is also a working php code > > \        $ldap\_dn = "uid=".$\_POST["username"].",dc=uchicago,dc=edu"; >        $ldap\_password = $\_POST["password"]; >        $ldap\_con = ldap\_connect("ldap.uchicago.edu","636"); >        ldap\_set\_option($ldap\_con, LDAP\_OPT\_PROTOCOL\_VERSION, 3); > > #        if(@ldap\_bind($ldap\_con,$ldap\_dn,$ldap\_password))                echo "Authenticated";        else                echo "Invalid Credential"; ?\> > > Apparently I should be using ldap.uchicago.edu:636. That probably means > that I should use > enable\_ssl\_client\_auth: true > ? > > Can you tell me from above what bind\_dn, userbase I should use? > > I tried the following settings for both authc and authz but still no luck: > > ========== >                     enable\_ssl\_client\_auth: true >           hosts: >              - ldap.uchicago.edu:636 >            bind\_dn: 'dc=uchicago,dc=edu' >            #password: password >            userbase: 'ou=people,dc=uchicago,dc=edu' > > ========== > LDAP response read timed out, timeout used:5000ms., > providerException=javax.naming. > NamingException: LDAP response read timed out, timeout used:5000ms.]. Try > next. > [2018-02-19T15:57:52,005][WARN][c.f.s.a.BackendRegistry] Authentication > finally failed for ivy2 > > ========== > > > On Monday, February 19, 2018 at 6:38:23 PM UTC+1, ivy2@uchicago.edu wrote: > > > > > # Hi Jochen, After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > > > > > # No password given for bind\_dn cn=admin,dc=rcc,dc=uchica go,dc=edu. Will try to authenticate anonymously to ldap [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > > > Does one normally have to use something like a password or certificate to > > > talk to LDAP? What bind\_dn is usually given? > > > Thank you, > > > Igor > > > > > > On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > > > > > > From the configs and screeshots and LDAP config you sent I see that you > > > > enable TLS and also want to verify hostnames: > > > > > > > > enable\_ssl: true > > > > verify\_hostnames: true > > > > > > > > This means that the connection to LDAP will be TLS encrypted and that > > > > Search Guard needs to verify the TLS certificate that the LDAP server sends > > > > against a Root CA / trusted CA. So in order to use TLS, you need to > > > > configure the trusted CAs in the LDAP module. This would be the root and/or > > > > signing certificate of the certificate you installed on the LDAP server. > > > > > > > > However, in the LDAP config you specify port 389 for the LDAP > > > > connection, which is usually used for plain / unencrypted connections. The > > > > port for TLS would be 636. Are you sure your LDAP server listens in port > > > > 389 for TLS connections? What happens if you configure: > > > > > > > > enable\_ssl: false > > > > verify\_hostnames: false > > > > > > > > On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv...@uchicago.edu \>\>\> wrote: > > > > > > > > > Hello, > > > > > > > > > > I have just started playing with Search Guard and got stuck configuring > > > > > LDAP. > > > > > > > > > > First I installed the demo. It worked OK except I do not see "Tenants" > > > > > tab on the left as the document says. See the screenshot. Is it a problem? > > > > > I do want each user to be able to store his Kibana dashboards both > > > > > privately and publicly. > > > > > > > > > > # Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > > > > > > > > > # Unable to connect to ldapserver 128.135.112.111:389 due to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > > > > > > > > > How to fix it? > > > > > Do I have to use truststore? Currently I just have whatever > > > > > certificates were generated by demo. > > > > > > > > > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b > > > > > "dc=rcc,dc=uchicago,dc=edu" > > > > > from the host I am running ES on works fine. > > > > > > > > > > # Once I'll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. What options do I need to specify to > > > > > > > > > > # from elasticsearch import Elasticsearch es = Elasticsearch() > > > > > > > > > > to connect to the protected ES when running on the same host where > > > > > Kibana and ES are running from inside user account known to LDAP? > > > > > > > > > > Thank you, > > > > > Igor > > > > > > > > > > ===================== > > > > > When asking questions, please provide the following information: > > > > > > > > > > \* Search Guard and Elasticsearch version > > > > > > > > > > 6.2.1 > > > > > > > > > > \* Installed and used enterprise modules, if any > > > > > > > > > > Elasticsearch, Kibana, Search Guard > > > > > > > > > > \* JVM version and operating system version > > > > > > > > > > 1.8.0\_121 > > > > > CentOS 7.2 > > > > > > > > > > \* Search Guard configuration files > > > > > > > > > > Attached > > > > > > > > > > \* Elasticsearch log messages on debug level > > > > > > > > > > Attached > > > > > > > > > > \* Other installed Elasticsearch or Kibana plugins, if any > > > > > > > > > > # None > > > > > > > > -- > > > > You received this message because you are subscribed to a topic in the > > Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this topic, visit [https://groups.google.com/d/to](https://groups.google.com/d/to) > > pic/search-guard/jVjrVCh0yLY/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/ms](https://groups.google.com/d/ms) > > gid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com > > \<[https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com?utm\_medium=email&utm\_source=footer>](https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com?utm_medium=email&utm_source=footer>); > > . > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > -- > Igor Yakushin, Ph.D. > Computational Scientist > Kavli Institute for Cosmological Physics, ERC #413 > Research Computing Center, room #2 > The University of Chicago > 773-834-5313 \<(773)%20834-5313\> > > > **[Research Computing Center](https://rcc.uchicago.edu)** > > > > University of Chicago ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [February 27, 2018, 5:49pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/6 "2018-02-27T17:49:07Z")
you can just omit the bind\_dn and password, then a LDAP anonymous bind will be performed which seems the way to go in your setup If this is still not working than pls enable debug logging and post (or mail) the complete logfile. Pls refer to [TLS help | Security for Elasticsearch | Search Guard](http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug) > **···** > > > Am 19.02.2018 um 23:00 schrieb Igor Yakushin \: > > > > On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin \ wrote: > > Yes, usually you need a user (in LDAP terminology: bind\_dn) and password to talk to an LDAP server. But this depends on how your LDAP is configured actually: If it allows anonymous (usually read-only) access then you can skip the bind\_dn and password section if the sg\_config LDAP configuration. Search Guard will then try to access the server without bind\_dn and password. But if your LDAP server requires authentication, then you need to add the bind\_dn and password. This depends on what server you user and how it is configured. > > > > Is there a way to figure out how my server is configured by using for example 'ldapsearch' or some other tool? > > > > # I looked into a working java program that creates a web page where users can type their credentials and get access via LDAP to our system and at first glance I do not see that it is using any password to query LDAP server (except for the credentials of the user that tries to login): > > > > #             environment.put(javax.naming.Context.PROVIDER\_URL, "ldaps://ldap.uchicago.edu");             environment.put(javax.naming.Context.SECURITY\_AUTHENTICATION, "simple");             environment.put(javax.naming.Context.SECURITY\_PRINCIPAL, usernameFormatted);             environment.put(javax.naming.Context.SECURITY\_CREDENTIALS, password);             DirContext ctx = new InitialDirContext(environment);             SearchControls controls = new SearchControls();             controls.setSearchScope(SearchControls.SUBTREE\_SCOPE);             NamingEnumeration\ results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls); > > > > # Here is also a working php code > > > > \ >        $ldap\_dn = "uid=".$\_POST["username"].",dc=uchicago,dc=edu"; > >        $ldap\_password = $\_POST["password"]; > >        $ldap\_con = ldap\_connect("ldap.uchicago.edu","636"); > >        ldap\_set\_option($ldap\_con, LDAP\_OPT\_PROTOCOL\_VERSION, 3); > > > > #        if(@ldap\_bind($ldap\_con,$ldap\_dn,$ldap\_password))                echo "Authenticated";        else                echo "Invalid Credential"; ?\> > > > > Apparently I should be using ldap.uchicago.edu:636. That probably means that I should use > > enable\_ssl\_client\_auth: true > > ? > > > > Can you tell me from above what bind\_dn, userbase I should use? > > > > I tried the following settings for both authc and authz but still no luck: > > > > ========== > >                     enable\_ssl\_client\_auth: true > >           hosts: > >              - ldap.uchicago.edu:636 > >            bind\_dn: 'dc=uchicago,dc=edu' > >            #password: password > >            userbase: 'ou=people,dc=uchicago,dc=edu' > > > > ========== > > LDAP response read timed out, timeout used:5000ms., providerException=javax.naming. > > NamingException: LDAP response read timed out, timeout used:5000ms.]. Try next. > > [2018-02-19T15:57:52,005][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > ========== > > > > # On Monday, February 19, 2018 at 6:38:23 PM UTC+1, ivy2@uchicago.edu wrote: Hi Jochen, After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > > > # No password given for bind\_dn cn=admin,dc=rcc,dc=uchica go,dc=edu. Will try to authenticate anonymously to ldap [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > Thank you, > > Igor > > > > On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > > > enable\_ssl: true > > verify\_hostnames: true > > > > This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > > > However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > > > enable\_ssl: false > > verify\_hostnames: false > > > > On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv...@uchicago.edu wrote: > > Hello, > > > > I have just started playing with Search Guard and got stuck configuring LDAP. > > > > First I installed the demo. It worked OK except I do not see "Tenants" tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > > > # Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > > > # Unable to connect to ldapserver 128.135.112.111:389 due to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > > > How to fix it? > > Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b "dc=rcc,dc=uchicago,dc=edu" > > from the host I am running ES on works fine. > > > > # Once I'll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. What options do I need to specify to > > > > # from elasticsearch import Elasticsearch es = Elasticsearch() > > > > to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > > > Thank you, > > Igor > > > > ===================== > > When asking questions, please provide the following information: > > > > \* Search Guard and Elasticsearch version > > > > 6.2.1 > > > > \* Installed and used enterprise modules, if any > > > > Elasticsearch, Kibana, Search Guard > > > > \* JVM version and operating system version > > > > 1.8.0\_121 > > CentOS 7.2 > > > > \* Search Guard configuration files > > > > Attached > > > > \* Elasticsearch log messages on debug level > > > > Attached > > > > \* Other installed Elasticsearch or Kibana plugins, if any > > > > # None > > > > -- > > You received this message because you are subscribed to a topic in the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe\](https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe%5C). > > To unsubscribe from this group and all its topics, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > > > -- > > Igor Yakushin, Ph.D. > > Computational Scientist > > Kavli Institute for Cosmological Physics, ERC #413 > > Research Computing Center, room #2 > > The University of Chicago > > 773-834-5313 > > [https://rcc.uchicago.edu](https://rcc.uchicago.edu) > > > > -- > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com\](https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [March 13, 2018, 8:50pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/7 "2018-03-13T20:50:45Z")
> you can just omit the bind\_dn and password, then a LDAP anonymous bind will be performed which seems the way to go in your setup > > If this is still not working than pls enable debug logging and post (or mail) the complete logfile. Pls refer to [http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug](http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug) Hello, I am still stuck with LDAP. The log file is attached. Thank you, Igor [log.txt](https://forum.search-guard.com/uploads/short-url/sMrUT26Qqmox4OrhmXnG3cokeE8.txt) (114 KB) > **···** > > On Tuesday, February 27, 2018 at 11:49:09 AM UTC-6, Search Guard wrote: > > > > Am 19.02.2018 um 23:00 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin [jkre...@floragunn.com](mailto:jkre...@floragunn.com) wrote: > > > > > Yes, usually you need a user (in LDAP terminology: bind\_dn) and password to talk to an LDAP server. But this depends on how your LDAP is configured actually: If it allows anonymous (usually read-only) access then you can skip the bind\_dn and password section if the sg\_config LDAP configuration. Search Guard will then try to access the server without bind\_dn and password. But if your LDAP server requires authentication, then you need to add the bind\_dn and password. This depends on what server you user and how it is configured. > > > > > Is there a way to figure out how my server is configured by using for example ‘ldapsearch’ or some other tool? > > > > > I looked into a working java program that creates a web page where users can type their credentials and get access via LDAP to our system and at first glance I do not see that it is using any password to query LDAP server (except for the credentials of the user that tries to login): > > > > > ========== > > > > > ``` > > > environment.put(javax.naming.Context.PROVIDER_URL, "ldaps://[ldap.uchicago.edu](http://ldap.uchicago.edu)"); > > > > > > ``` > > > > > ``` > > > environment.put(javax.naming.Context.SECURITY_AUTHENTICATION, "simple"); > > > > > > ``` > > > > > ``` > > > environment.put(javax.naming.Context.SECURITY_PRINCIPAL, usernameFormatted); > > > > > > ``` > > > > > ``` > > > environment.put(javax.naming.Context.SECURITY_CREDENTIALS, password); > > > > > > ``` > > > > > ``` > > > DirContext ctx = new InitialDirContext(environment); > > > > > > ``` > > > > > ``` > > > SearchControls controls = new SearchControls(); > > > > > > ``` > > > > > ``` > > > controls.setSearchScope(SearchControls.SUBTREE_SCOPE); > > > > > > ``` > > > > > ``` > > > NamingEnumeration results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls); > > > > > > ``` > > > > > ========== > > > > > Here is also a working php code > > > > > ========== > > > > > \ > > > > > ========== > > > > > Apparently I should be using [ldap.uchicago.edu:636](http://ldap.uchicago.edu:636). That probably means that I should use > > > enable\_ssl\_client\_auth: true > > > > > ? > > > > > Can you tell me from above what bind\_dn, userbase I should use? > > > > > I tried the following settings for both authc and authz but still no luck: > > > > > ========== > > > > > ``` > > > enable_ssl_client_auth: true > > > > > > ``` > > > > > ``` > > > hosts: > > > - [ldap.uchicago.edu:636](http://ldap.uchicago.edu:636) > > > > > > ``` > > > > > ``` > > > bind_dn: 'dc=uchicago,dc=edu' > > > #password: password > > > userbase: 'ou=people,dc=uchicago,dc=edu' > > > > > > ``` > > > > > ========== > > > > > LDAP response read timed out, timeout used:5000ms., providerException=javax.naming. > > > > > NamingException: LDAP response read timed out, timeout used:5000ms.]. Try next. > > > [2018-02-19T15:57:52,005][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > > ========== > > > > > On Monday, February 19, 2018 at 6:38:23 PM UTC+1, iv…@uchicago.edu wrote: > > > > > Hi Jochen, > > > > > After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > > > > ========= > > > > > No password given for bind\_dn cn=admin,dc=rcc,dc=uchica > > > > > go,dc=edu. Will try to authenticate anonymously to ldap > > > [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > > ========= > > > > > Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > > > > Thank you, > > > > > Igor > > > > > On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > > > > From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > > > > enable\_ssl: true > > > > > verify\_hostnames: true > > > > > This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > > > > However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > > > > enable\_ssl: false > > > > > verify\_hostnames: false > > > > > On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv…@uchicago.edu wrote: > > > > > Hello, > > > > > I have just started playing with Search Guard and got stuck configuring LDAP. > > > > > First I installed the demo. It worked OK except I do not see “Tenants” tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > > > > Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > > > > ==== > > > > > Unable to connect to ldapserver [128.135.112.111:389](http://128.135.112.111:389) due > > > > > to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > > > > ==== > > > > > How to fix it? > > > > > Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > > > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b “dc=rcc,dc=uchicago,dc=edu” > > > > > from the host I am running ES on works fine. > > > > > Once I’ll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. > > > > > What options do I need to specify to > > > > > === > > > > > from elasticsearch import Elasticsearch > > > es = Elasticsearch() > > > > > === > > > > > to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > > > > Thank you, > > > > > Igor > > > > > ===================== > > > > > When asking questions, please provide the following information: > > > > > - Search Guard and Elasticsearch version > > > > > 6.2.1 > > > > > > - Installed and used enterprise modules, if any > > > > > Elasticsearch, Kibana, Search Guard > > > > > - JVM version and operating system version > > > > > 1.8.0\_121 > > > > > CentOS 7.2 > > > > > - Search Guard configuration files > > > > > Attached > > > > > - Elasticsearch log messages on debug level > > > > > Attached > > > > > - Other installed Elasticsearch or Kibana plugins, if any > > > > > None > > > > > ======================= > > > > > – > > > You received this message because you are subscribed to a topic in the Google Groups “Search Guard Community Forum” group. > > > > > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe](https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe). > > > > > To unsubscribe from this group and all its topics, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com). > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > – > > > Igor Yakushin, Ph.D. > > > > > Computational Scientist > > > > > Kavli Institute for Cosmological Physics, ERC #413 > > > > > Research Computing Center, room #2 > > > > > The University of Chicago > > > > > 773-834-5313 > > > > > [https://rcc.uchicago.edu](https://rcc.uchicago.edu) > > > > > – > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com). > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [March 13, 2018, 8:56pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/8 "2018-03-13T20:56:04Z")
pls post your complete sg\_config.yml (beware of sensitive information like passwords!) > **···** > > > Am 13.03.2018 um 21:50 schrieb ivy2@uchicago.edu: > > > > On Tuesday, February 27, 2018 at 11:49:09 AM UTC-6, Search Guard wrote: > > you can just omit the bind\_dn and password, then a LDAP anonymous bind will be performed which seems the way to go in your setup > > > > If this is still not working than pls enable debug logging and post (or mail) the complete logfile. Pls refer to [TLS help | Security for Elasticsearch | Search Guard](http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug) > > > > Hello, > > I am still stuck with LDAP. The log file is attached. > > Thank you, > > Igor > > > > \> Am 19.02.2018 um 23:00 schrieb Igor Yakushin \: > > \> > > \> > > \> > > \> On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin \ wrote: > > \> Yes, usually you need a user (in LDAP terminology: bind\_dn) and password to talk to an LDAP server. But this depends on how your LDAP is configured actually: If it allows anonymous (usually read-only) access then you can skip the bind\_dn and password section if the sg\_config LDAP configuration. Search Guard will then try to access the server without bind\_dn and password. But if your LDAP server requires authentication, then you need to add the bind\_dn and password. This depends on what server you user and how it is configured. > > \> > > \> > > \> Is there a way to figure out how my server is configured by using for example 'ldapsearch' or some other tool? > > \> > > \> I looked into a working java program that creates a web page where users can type their credentials and get access via LDAP to our system and at first glance I do not see that it is using any password to query LDAP server (except for the credentials of the user that tries to login): > > \> ========== > > \> environment.put(javax.naming.Context.PROVIDER\_URL, "ldaps://ldap.uchicago.edu"); > > \> environment.put(javax.naming.Context.SECURITY\_AUTHENTICATION, "simple"); > > \> environment.put(javax.naming.Context.SECURITY\_PRINCIPAL, usernameFormatted); > > \> environment.put(javax.naming.Context.SECURITY\_CREDENTIALS, password); > > \> DirContext ctx = new InitialDirContext(environment); > > \> SearchControls controls = new SearchControls(); > > \> controls.setSearchScope(SearchControls.SUBTREE\_SCOPE); > > \> NamingEnumeration\ results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls); > > \> ========== > > \> Here is also a working php code > > \> ========== > > \> \ > \> $ldap\_dn = "uid=".$\_POST["username"].",dc=uchicago,dc=edu"; > > \> $ldap\_password = $\_POST["password"]; > > \> $ldap\_con = ldap\_connect("ldap.uchicago.edu","636"); > > \> ldap\_set\_option($ldap\_con, LDAP\_OPT\_PROTOCOL\_VERSION, 3); > > \> > > \> if(@ldap\_bind($ldap\_con,$ldap\_dn,$ldap\_password)) > > \> echo "Authenticated"; > > \> else > > \> echo "Invalid Credential"; > > \> ?\> > > \> ========== > > \> Apparently I should be using ldap.uchicago.edu:636. That probably means that I should use > > \> enable\_ssl\_client\_auth: true > > \> ? > > \> > > \> Can you tell me from above what bind\_dn, userbase I should use? > > \> > > \> I tried the following settings for both authc and authz but still no luck: > > \> > > \> ========== > > \> enable\_ssl\_client\_auth: true > > \> hosts: > > \> - ldap.uchicago.edu:636 > > \> bind\_dn: 'dc=uchicago,dc=edu' > > \> #password: password > > \> userbase: 'ou=people,dc=uchicago,dc=edu' > > \> > > \> ========== > > \> LDAP response read timed out, timeout used:5000ms., providerException=javax.naming. > > \> NamingException: LDAP response read timed out, timeout used:5000ms.]. Try next. > > \> [2018-02-19T15:57:52,005][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > \> > > \> ========== > > \> > > \> > > \> On Monday, February 19, 2018 at 6:38:23 PM UTC+1, iv...@uchicago.edu wrote: > > \> Hi Jochen, > > \> After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > \> ========= > > \> No password given for bind\_dn cn=admin,dc=rcc,dc=uchica > > \> go,dc=edu. Will try to authenticate anonymously to ldap > > \> [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > \> ========= > > \> Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > \> Thank you, > > \> Igor > > \> > > \> > > \> On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > \> From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > \> > > \> enable\_ssl: true > > \> verify\_hostnames: true > > \> > > \> This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > \> > > \> However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > \> > > \> enable\_ssl: false > > \> verify\_hostnames: false > > \> > > \> > > \> > > \> On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv...@uchicago.edu wrote: > > \> Hello, > > \> > > \> I have just started playing with Search Guard and got stuck configuring LDAP. > > \> > > \> First I installed the demo. It worked OK except I do not see "Tenants" tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > \> > > \> Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > \> ==== > > \> Unable to connect to ldapserver 128.135.112.111:389 due > > \> to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > \> ==== > > \> > > \> How to fix it? > > \> Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > \> > > \> ldapsearch -x -v -h 128.135.112.111 -p 389 -b "dc=rcc,dc=uchicago,dc=edu" > > \> from the host I am running ES on works fine. > > \> > > \> Once I'll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. > > \> What options do I need to specify to > > \> === > > \> from elasticsearch import Elasticsearch > > \> es = Elasticsearch() > > \> === > > \> to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > \> > > \> Thank you, > > \> Igor > > \> > > \> > > \> ===================== > > \> When asking questions, please provide the following information: > > \> > > \> \* Search Guard and Elasticsearch version > > \> > > \> 6.2.1 > > \> > > \> \* Installed and used enterprise modules, if any > > \> > > \> Elasticsearch, Kibana, Search Guard > > \> > > \> \* JVM version and operating system version > > \> > > \> 1.8.0\_121 > > \> CentOS 7.2 > > \> > > \> \* Search Guard configuration files > > \> > > \> Attached > > \> > > \> \* Elasticsearch log messages on debug level > > \> > > \> Attached > > \> > > \> \* Other installed Elasticsearch or Kibana plugins, if any > > \> > > \> None > > \> ======================= > > \> > > \> -- > > \> You received this message because you are subscribed to a topic in the Google Groups "Search Guard Community Forum" group. > > \> To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe\](https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe%5C). > > \> To unsubscribe from this group and all its topics, send an email to search-guard...@googlegroups.com. > > \> To post to this group, send email to search...@googlegroups.com. > > \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com%5C). > > \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \> > > \> > > \> > > \> -- > > \> Igor Yakushin, Ph.D. > > \> Computational Scientist > > \> Kavli Institute for Cosmological Physics, ERC #413 > > \> Research Computing Center, room #2 > > \> The University of Chicago > > \> 773-834-5313 > > \> [https://rcc.uchicago.edu](https://rcc.uchicago.edu) > > \> > > \> > > \> -- > > \> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > \> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com. > > \> To post to this group, send email to search...@googlegroups.com. > > \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com\](https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com%5C). > > \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > > > -- > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \ ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [March 13, 2018, 9:19pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/9 "2018-03-13T21:19:31Z")
> pls post your complete sg\_config.yml (beware of sensitive information like passwords!) Attached. [elasticsearch.yml](https://forum.search-guard.com/uploads/short-url/qFKXdhFMDDMtFrzvkerSsNgD9qP.yml) (4.91 KB) [sg\_config.yml](https://forum.search-guard.com/uploads/short-url/57XcDNDikYQXqA0PZHvirerum32.yml) (9.82 KB) > **···** > > On Tuesday, March 13, 2018 at 3:56:07 PM UTC-5, Search Guard wrote: > > > > Am 13.03.2018 um 21:50 schrieb iv…@uchicago.edu: > > > > > On Tuesday, February 27, 2018 at 11:49:09 AM UTC-6, Search Guard wrote: > > > > > you can just omit the bind\_dn and password, then a LDAP anonymous bind will be performed which seems the way to go in your setup > > > > > > If this is still not working than pls enable debug logging and post (or mail) the complete logfile. Pls refer to [http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug](http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug) > > > > > Hello, > > > > > I am still stuck with LDAP. The log file is attached. > > > > > Thank you, > > > > > Igor > > > > > > > > > > > Am 19.02.2018 um 23:00 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > > > > On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin [jkre...@floragunn.com](mailto:jkre...@floragunn.com) wrote: > > > > Yes, usually you need a user (in LDAP terminology: bind\_dn) and password to talk to an LDAP server. But this depends on how your LDAP is configured actually: If it allows anonymous (usually read-only) access then you can skip the bind\_dn and password section if the sg\_config LDAP configuration. Search Guard will then try to access the server without bind\_dn and password. But if your LDAP server requires authentication, then you need to add the bind\_dn and password. This depends on what server you user and how it is configured. > > > > > > > > Is there a way to figure out how my server is configured by using for example ‘ldapsearch’ or some other tool? > > > > > > > > # I looked into a working java program that creates a web page where users can type their credentials and get access via LDAP to our system and at first glance I do not see that it is using any password to query LDAP server (except for the credentials of the user that tries to login): > > > > > > > > ``` > > > > environment.put(javax.naming.Context.PROVIDER_URL, "ldaps://[ldap.uchicago.edu](http://ldap.uchicago.edu)"); > > > > environment.put(javax.naming.Context.SECURITY_AUTHENTICATION, "simple"); > > > > environment.put(javax.naming.Context.SECURITY_PRINCIPAL, usernameFormatted); > > > > environment.put(javax.naming.Context.SECURITY_CREDENTIALS, password); > > > > DirContext ctx = new InitialDirContext(environment); > > > > SearchControls controls = new SearchControls(); > > > > controls.setSearchScope(SearchControls.SUBTREE_SCOPE); > > > > NamingEnumeration results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls); > > > > > > > > ``` > > > > > > > > # ========== Here is also a working php code > > > > \ > > > > > > > > ========== > > > > Apparently I should be using [ldap.uchicago.edu:636](http://ldap.uchicago.edu:636). That probably means that I should use > > > > enable\_ssl\_client\_auth: true > > > > ? > > > > > > > > Can you tell me from above what bind\_dn, userbase I should use? > > > > > > > > I tried the following settings for both authc and authz but still no luck: > > > > > > > > ========== > > > > enable\_ssl\_client\_auth: true > > > > hosts: > > > > - [ldap.uchicago.edu:636](http://ldap.uchicago.edu:636) > > > > > > ``` > > > > bind_dn: 'dc=uchicago,dc=edu' > > > > #password: password > > > > userbase: 'ou=people,dc=uchicago,dc=edu' > > > > > > > > ``` > > > > > > > > ========== > > > > LDAP response read timed out, timeout used:5000ms., providerException=javax.naming. > > > > NamingException: LDAP response read timed out, timeout used:5000ms.]. Try next. > > > > [2018-02-19T15:57:52,005][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > > > > > ========== > > > > > > > > # On Monday, February 19, 2018 at 6:38:23 PM UTC+1, iv…@uchicago.edu wrote: Hi Jochen, After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > > > > > > > # No password given for bind\_dn cn=admin,dc=rcc,dc=uchica go,dc=edu. Will try to authenticate anonymously to ldap [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > > > > > Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > > > Thank you, > > > > Igor > > > > > > > > On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > > > From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > > > > > > > enable\_ssl: true > > > > verify\_hostnames: true > > > > > > > > This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > > > > > > > However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > > > > > > > enable\_ssl: false > > > > verify\_hostnames: false > > > > > > > > On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv…@uchicago.edu wrote: > > > > Hello, > > > > > > > > I have just started playing with Search Guard and got stuck configuring LDAP. > > > > > > > > First I installed the demo. It worked OK except I do not see “Tenants” tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > > > > > > > # Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > > > > > > > # Unable to connect to ldapserver [128.135.112.111:389](http://128.135.112.111:389) due to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > > > > > > > How to fix it? > > > > Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > > > > > > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b “dc=rcc,dc=uchicago,dc=edu” > > > > from the host I am running ES on works fine. > > > > > > > > # Once I’ll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. What options do I need to specify to > > > > > > > > # from elasticsearch import Elasticsearch es = Elasticsearch() > > > > > > > > to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > > > > > > > Thank you, > > > > Igor > > > > > > > > ===================== > > > > When asking questions, please provide the following information: > > > > > > > > - Search Guard and Elasticsearch version > > > > > > > > 6.2.1 > > > > > > > > - Installed and used enterprise modules, if any > > > > > > > > Elasticsearch, Kibana, Search Guard > > > > > > > > - JVM version and operating system version > > > > > > > > 1.8.0\_121 > > > > CentOS 7.2 > > > > > > > > - Search Guard configuration files > > > > > > > > Attached > > > > > > > > - Elasticsearch log messages on debug level > > > > > > > > Attached > > > > > > > > - Other installed Elasticsearch or Kibana plugins, if any > > > > > > > > # None > > > > > > > > – > > > > You received this message because you are subscribed to a topic in the Google Groups “Search Guard Community Forum” group. > > > > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe](https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe). > > > > To unsubscribe from this group and all its topics, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com). > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > – > > > > Igor Yakushin, Ph.D. > > > > Computational Scientist > > > > Kavli Institute for Cosmological Physics, ERC #413 > > > > Research Computing Center, room #2 > > > > The University of Chicago > > > > 773-834-5313 > > > > [https://rcc.uchicago.edu](https://rcc.uchicago.edu) > > > > > > – > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com). > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > – > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com). > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > \ ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [March 13, 2018, 9:42pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/10 "2018-03-13T21:42:37Z")
enable\_ssl\_client\_auth: true --\> but no client certificates denoted! So i think you should set this to false. This has nothing to do with port 636 or 389 !! And if you use enable\_start\_tls than normally the port is 389, so i think you can remove the 636 entries (but configuration maybe different for your servers) On the other hand you can set enable\_start\_tls to false and set enable\_ssl to true and omit all the 389 entries From the example code you mentioned earlier i suggest you try: enable\_ssl: true enable\_start\_tls: false enable\_ssl\_client\_auth: false verify\_hostnames: false hosts:   - ldap.rcc.uchicago.edu:636   - ldap.uchicago.edu:636 If that is working then try setting verify\_hostnames to true (because false is insecure) > **···** > > > Am 13.03.2018 um 22:19 schrieb ivy2@uchicago.edu: > > > > On Tuesday, March 13, 2018 at 3:56:07 PM UTC-5, Search Guard wrote: > > pls post your complete sg\_config.yml (beware of sensitive information like passwords!) > > > > Attached. > > > > \> Am 13.03.2018 um 21:50 schrieb iv...@uchicago.edu: > > \> > > \> > > \> > > \> On Tuesday, February 27, 2018 at 11:49:09 AM UTC-6, Search Guard wrote: > > \> you can just omit the bind\_dn and password, then a LDAP anonymous bind will be performed which seems the way to go in your setup > > \> > > \> If this is still not working than pls enable debug logging and post (or mail) the complete logfile. Pls refer to [TLS help | Security for Elasticsearch | Search Guard](http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug) > > \> > > \> Hello, > > \> I am still stuck with LDAP. The log file is attached. > > \> Thank you, > > \> Igor > > \> > > \> > > \> > > \> > > \> > > \> > > \> \> Am 19.02.2018 um 23:00 schrieb Igor Yakushin \: > > \> \> > > \> \> > > \> \> > > \> \> On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin \ wrote: > > \> \> Yes, usually you need a user (in LDAP terminology: bind\_dn) and password to talk to an LDAP server. But this depends on how your LDAP is configured actually: If it allows anonymous (usually read-only) access then you can skip the bind\_dn and password section if the sg\_config LDAP configuration. Search Guard will then try to access the server without bind\_dn and password. But if your LDAP server requires authentication, then you need to add the bind\_dn and password. This depends on what server you user and how it is configured. > > \> \> > > \> \> > > \> \> Is there a way to figure out how my server is configured by using for example 'ldapsearch' or some other tool? > > \> \> > > \> \> I looked into a working java program that creates a web page where users can type their credentials and get access via LDAP to our system and at first glance I do not see that it is using any password to query LDAP server (except for the credentials of the user that tries to login): > > \> \> ========== > > \> \> environment.put(javax.naming.Context.PROVIDER\_URL, "ldaps://ldap.uchicago.edu"); > > \> \> environment.put(javax.naming.Context.SECURITY\_AUTHENTICATION, "simple"); > > \> \> environment.put(javax.naming.Context.SECURITY\_PRINCIPAL, usernameFormatted); > > \> \> environment.put(javax.naming.Context.SECURITY\_CREDENTIALS, password); > > \> \> DirContext ctx = new InitialDirContext(environment); > > \> \> SearchControls controls = new SearchControls(); > > \> \> controls.setSearchScope(SearchControls.SUBTREE\_SCOPE); > > \> \> NamingEnumeration\ results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls); > > \> \> ========== > > \> \> Here is also a working php code > > \> \> ========== > > \> \> \ > \> \> $ldap\_dn = "uid=".$\_POST["username"].",dc=uchicago,dc=edu"; > > \> \> $ldap\_password = $\_POST["password"]; > > \> \> $ldap\_con = ldap\_connect("ldap.uchicago.edu","636"); > > \> \> ldap\_set\_option($ldap\_con, LDAP\_OPT\_PROTOCOL\_VERSION, 3); > > \> \> > > \> \> if(@ldap\_bind($ldap\_con,$ldap\_dn,$ldap\_password)) > > \> \> echo "Authenticated"; > > \> \> else > > \> \> echo "Invalid Credential"; > > \> \> ?\> > > \> \> ========== > > \> \> Apparently I should be using ldap.uchicago.edu:636. That probably means that I should use > > \> \> enable\_ssl\_client\_auth: true > > \> \> ? > > \> \> > > \> \> Can you tell me from above what bind\_dn, userbase I should use? > > \> \> > > \> \> I tried the following settings for both authc and authz but still no luck: > > \> \> > > \> \> ========== > > \> \> enable\_ssl\_client\_auth: true > > \> \> hosts: > > \> \> - ldap.uchicago.edu:636 > > \> \> bind\_dn: 'dc=uchicago,dc=edu' > > \> \> #password: password > > \> \> userbase: 'ou=people,dc=uchicago,dc=edu' > > \> \> > > \> \> ========== > > \> \> LDAP response read timed out, timeout used:5000ms., providerException=javax.naming. > > \> \> NamingException: LDAP response read timed out, timeout used:5000ms.]. Try next. > > \> \> [2018-02-19T15:57:52,005][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > \> \> > > \> \> ========== > > \> \> > > \> \> > > \> \> On Monday, February 19, 2018 at 6:38:23 PM UTC+1, iv...@uchicago.edu wrote: > > \> \> Hi Jochen, > > \> \> After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > \> \> ========= > > \> \> No password given for bind\_dn cn=admin,dc=rcc,dc=uchica > > \> \> go,dc=edu. Will try to authenticate anonymously to ldap > > \> \> [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > \> \> ========= > > \> \> Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > \> \> Thank you, > > \> \> Igor > > \> \> > > \> \> > > \> \> On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > \> \> From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > \> \> > > \> \> enable\_ssl: true > > \> \> verify\_hostnames: true > > \> \> > > \> \> This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > \> \> > > \> \> However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > \> \> > > \> \> enable\_ssl: false > > \> \> verify\_hostnames: false > > \> \> > > \> \> > > \> \> > > \> \> On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv...@uchicago.edu wrote: > > \> \> Hello, > > \> \> > > \> \> I have just started playing with Search Guard and got stuck configuring LDAP. > > \> \> > > \> \> First I installed the demo. It worked OK except I do not see "Tenants" tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > \> \> > > \> \> Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > \> \> ==== > > \> \> Unable to connect to ldapserver 128.135.112.111:389 due > > \> \> to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > \> \> ==== > > \> \> > > \> \> How to fix it? > > \> \> Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > \> \> > > \> \> ldapsearch -x -v -h 128.135.112.111 -p 389 -b "dc=rcc,dc=uchicago,dc=edu" > > \> \> from the host I am running ES on works fine. > > \> \> > > \> \> Once I'll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. > > \> \> What options do I need to specify to > > \> \> === > > \> \> from elasticsearch import Elasticsearch > > \> \> es = Elasticsearch() > > \> \> === > > \> \> to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > \> \> > > \> \> Thank you, > > \> \> Igor > > \> \> > > \> \> > > \> \> ===================== > > \> \> When asking questions, please provide the following information: > > \> \> > > \> \> \* Search Guard and Elasticsearch version > > \> \> > > \> \> 6.2.1 > > \> \> > > \> \> \* Installed and used enterprise modules, if any > > \> \> > > \> \> Elasticsearch, Kibana, Search Guard > > \> \> > > \> \> \* JVM version and operating system version > > \> \> > > \> \> 1.8.0\_121 > > \> \> CentOS 7.2 > > \> \> > > \> \> \* Search Guard configuration files > > \> \> > > \> \> Attached > > \> \> > > \> \> \* Elasticsearch log messages on debug level > > \> \> > > \> \> Attached > > \> \> > > \> \> \* Other installed Elasticsearch or Kibana plugins, if any > > \> \> > > \> \> None > > \> \> ======================= > > \> \> > > \> \> -- > > \> \> You received this message because you are subscribed to a topic in the Google Groups "Search Guard Community Forum" group. > > \> \> To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe\](https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe%5C). > > \> \> To unsubscribe from this group and all its topics, send an email to search-guard...@googlegroups.com. > > \> \> To post to this group, send email to search...@googlegroups.com. > > \> \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com%5C). > > \> \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \> \> > > \> \> > > \> \> > > \> \> -- > > \> \> Igor Yakushin, Ph.D. > > \> \> Computational Scientist > > \> \> Kavli Institute for Cosmological Physics, ERC #413 > > \> \> Research Computing Center, room #2 > > \> \> The University of Chicago > > \> \> 773-834-5313 > > \> \> [https://rcc.uchicago.edu](https://rcc.uchicago.edu) > > \> \> > > \> \> > > \> \> -- > > \> \> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > \> \> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com. > > \> \> To post to this group, send email to search...@googlegroups.com. > > \> \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com\](https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com%5C). > > \> \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \> > > \> > > \> -- > > \> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > \> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com. > > \> To post to this group, send email to search...@googlegroups.com. > > \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com%5C). > > \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \> \ > > > > -- > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/6f62d946-09ff-4512-867d-930551947e39%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/6f62d946-09ff-4512-867d-930551947e39%40googlegroups.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \\ ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [March 13, 2018, 10:06pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/11 "2018-03-13T22:06:38Z")
Still the same problems. The logs and config files are attached. How does one usually authenticate to LDAP server? [log.txt](https://forum.search-guard.com/uploads/short-url/eVf3i3wBXa9Sm7BVYHGP30LvOoG.txt) (91.4 KB) [sg\_config.yml](https://forum.search-guard.com/uploads/short-url/owoQNhybEW2IjlupANtIH3eY2lk.yml) (9.67 KB) > **···** > > On Tuesday, March 13, 2018 at 4:42:42 PM UTC-5, Search Guard wrote: > > > enable\_ssl\_client\_auth: true → but no client certificates denoted! So i think you should set this to false. This has nothing to do with port 636 or 389 !! > > > > And if you use enable\_start\_tls than normally the port is 389, so i think you can remove the 636 entries (but configuration maybe different for your servers) > > > > On the other hand you can set enable\_start\_tls to false and set enable\_ssl to true and omit all the 389 entries > > > > From the example code you mentioned earlier i suggest you try: > > > > enable\_ssl: true > > > > enable\_start\_tls: false > > > > enable\_ssl\_client\_auth: false > > > > verify\_hostnames: false > > > > hosts: > > > > - [ldap.rcc.uchicago.edu:636](http://ldap.rcc.uchicago.edu:636) > > > > - [ldap.uchicago.edu:636](http://ldap.uchicago.edu:636) > > > > If that is working then try setting verify\_hostnames to true (because false is insecure) > > > > > Am 13.03.2018 um 22:19 schrieb iv…@uchicago.edu: > > > > > On Tuesday, March 13, 2018 at 3:56:07 PM UTC-5, Search Guard wrote: > > > > > pls post your complete sg\_config.yml (beware of sensitive information like passwords!) > > > > > > Attached. > > > > > > > > > > > Am 13.03.2018 um 21:50 schrieb iv…@uchicago.edu: > > > > > > > > On Tuesday, February 27, 2018 at 11:49:09 AM UTC-6, Search Guard wrote: > > > > you can just omit the bind\_dn and password, then a LDAP anonymous bind will be performed which seems the way to go in your setup > > > > > > > > If this is still not working than pls enable debug logging and post (or mail) the complete logfile. Pls refer to [http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug](http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug) > > > > > > Hello, > > > > I am still stuck with LDAP. The log file is attached. > > > > Thank you, > > > > Igor > > > > > > > > > Am 19.02.2018 um 23:00 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > > > > > > On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin [jkre...@floragunn.com](mailto:jkre...@floragunn.com) wrote: > > > > > Yes, usually you need a user (in LDAP terminology: bind\_dn) and password to talk to an LDAP server. But this depends on how your LDAP is configured actually: If it allows anonymous (usually read-only) access then you can skip the bind\_dn and password section if the sg\_config LDAP configuration. Search Guard will then try to access the server without bind\_dn and password. But if your LDAP server requires authentication, then you need to add the bind\_dn and password. This depends on what server you user and how it is configured. > > > > > > > > > > Is there a way to figure out how my server is configured by using for example ‘ldapsearch’ or some other tool? > > > > > > > > > > # I looked into a working java program that creates a web page where users can type their credentials and get access via LDAP to our system and at first glance I do not see that it is using any password to query LDAP server (except for the credentials of the user that tries to login): > > > > > > > > > > ``` > > > > > environment.put(javax.naming.Context.PROVIDER_URL, "ldaps://[ldap.uchicago.edu](http://ldap.uchicago.edu)"); > > > > > environment.put(javax.naming.Context.SECURITY_AUTHENTICATION, "simple"); > > > > > environment.put(javax.naming.Context.SECURITY_PRINCIPAL, usernameFormatted); > > > > > environment.put(javax.naming.Context.SECURITY_CREDENTIALS, password); > > > > > DirContext ctx = new InitialDirContext(environment); > > > > > SearchControls controls = new SearchControls(); > > > > > controls.setSearchScope(SearchControls.SUBTREE_SCOPE); > > > > > NamingEnumeration results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls); > > > > > > > > > > ``` > > > > > > > > > > # ========== Here is also a working php code > > > > > \ > > > > > > > > > > ========== > > > > > Apparently I should be using [ldap.uchicago.edu:636](http://ldap.uchicago.edu:636). That probably means that I should use > > > > > enable\_ssl\_client\_auth: true > > > > > ? > > > > > > > > > > Can you tell me from above what bind\_dn, userbase I should use? > > > > > > > > > > I tried the following settings for both authc and authz but still no luck: > > > > > > > > > > ========== > > > > > enable\_ssl\_client\_auth: true > > > > > hosts: > > > > > - [ldap.uchicago.edu:636](http://ldap.uchicago.edu:636) > > > > > > > ``` > > > > > bind_dn: 'dc=uchicago,dc=edu' > > > > > #password: password > > > > > userbase: 'ou=people,dc=uchicago,dc=edu' > > > > > > > > > > ``` > > > > > > > > > > ========== > > > > > LDAP response read timed out, timeout used:5000ms., providerException=javax.naming. > > > > > NamingException: LDAP response read timed out, timeout used:5000ms.]. Try next. > > > > > [2018-02-19T15:57:52,005][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > > > > > > > ========== > > > > > > > > > > # On Monday, February 19, 2018 at 6:38:23 PM UTC+1, iv…@uchicago.edu wrote: Hi Jochen, After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > > > > > > > > > # No password given for bind\_dn cn=admin,dc=rcc,dc=uchica go,dc=edu. Will try to authenticate anonymously to ldap [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > > > > > > > > > Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > > > > Thank you, > > > > > Igor > > > > > > > > > > On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > > > > From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > > > > > > > > > enable\_ssl: true > > > > > verify\_hostnames: true > > > > > > > > > > This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > > > > > > > > > However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > > > > > > > > > enable\_ssl: false > > > > > verify\_hostnames: false > > > > > > > > > > On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv…@uchicago.edu wrote: > > > > > Hello, > > > > > > > > > > I have just started playing with Search Guard and got stuck configuring LDAP. > > > > > > > > > > First I installed the demo. It worked OK except I do not see “Tenants” tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > > > > > > > > > # Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > > > > > > > > > # Unable to connect to ldapserver [128.135.112.111:389](http://128.135.112.111:389) due to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > > > > > > > > > How to fix it? > > > > > Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > > > > > > > > > ldapsearch -x -v -h 128.135.112.111 -p 389 -b “dc=rcc,dc=uchicago,dc=edu” > > > > > from the host I am running ES on works fine. > > > > > > > > > > # Once I’ll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. What options do I need to specify to > > > > > > > > > > # from elasticsearch import Elasticsearch es = Elasticsearch() > > > > > > > > > > to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > > > > > > > > > Thank you, > > > > > Igor > > > > > > > > > > ===================== > > > > > When asking questions, please provide the following information: > > > > > > > > > > - Search Guard and Elasticsearch version > > > > > > > > > > 6.2.1 > > > > > > > > > > - Installed and used enterprise modules, if any > > > > > > > > > > Elasticsearch, Kibana, Search Guard > > > > > > > > > > - JVM version and operating system version > > > > > > > > > > 1.8.0\_121 > > > > > CentOS 7.2 > > > > > > > > > > - Search Guard configuration files > > > > > > > > > > Attached > > > > > > > > > > - Elasticsearch log messages on debug level > > > > > > > > > > Attached > > > > > > > > > > - Other installed Elasticsearch or Kibana plugins, if any > > > > > > > > > > # None > > > > > > > > > > – > > > > > You received this message because you are subscribed to a topic in the Google Groups “Search Guard Community Forum” group. > > > > > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe](https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe). > > > > > To unsubscribe from this group and all its topics, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com). > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > – > > > > > Igor Yakushin, Ph.D. > > > > > Computational Scientist > > > > > Kavli Institute for Cosmological Physics, ERC #413 > > > > > Research Computing Center, room #2 > > > > > The University of Chicago > > > > > 773-834-5313 > > > > > [https://rcc.uchicago.edu](https://rcc.uchicago.edu) > > > > > > > – > > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com). > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > – > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com). > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > \ > > > > > > – > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/6f62d946-09ff-4512-867d-930551947e39%40googlegroups.com](https://groups.google.com/d/msgid/search-guard/6f62d946-09ff-4512-867d-930551947e39%40googlegroups.com). > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > \\ ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [March 13, 2018, 10:54pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/12 "2018-03-13T22:54:11Z")
pls add this to the sg\_config.yml (same indent level as enable\_ssl) pemtrustedcas\_filepath: HadoopCertificates/incommon.crt > **···** > > > Am 13.03.2018 um 23:06 schrieb ivy2@uchicago.edu: > > > > Still the same problems. > > The logs and config files are attached. > > > > How does one usually authenticate to LDAP server? > > > > On Tuesday, March 13, 2018 at 4:42:42 PM UTC-5, Search Guard wrote: > > enable\_ssl\_client\_auth: true --\> but no client certificates denoted! So i think you should set this to false. This has nothing to do with port 636 or 389 !! > > > > And if you use enable\_start\_tls than normally the port is 389, so i think you can remove the 636 entries (but configuration maybe different for your servers) > > On the other hand you can set enable\_start\_tls to false and set enable\_ssl to true and omit all the 389 entries > > > > From the example code you mentioned earlier i suggest you try: > > > > enable\_ssl: true > > enable\_start\_tls: false > > enable\_ssl\_client\_auth: false > > verify\_hostnames: false > > hosts: > >   - ldap.rcc.uchicago.edu:636 > >   - ldap.uchicago.edu:636 > > > > If that is working then try setting verify\_hostnames to true (because false is insecure) > > > > \> Am 13.03.2018 um 22:19 schrieb iv...@uchicago.edu: > > \> > > \> > > \> > > \> On Tuesday, March 13, 2018 at 3:56:07 PM UTC-5, Search Guard wrote: > > \> pls post your complete sg\_config.yml (beware of sensitive information like passwords!) > > \> > > \> > > \> Attached. > > \> > > \> > > \> > > \> > > \> \> Am 13.03.2018 um 21:50 schrieb iv...@uchicago.edu: > > \> \> > > \> \> > > \> \> > > \> \> On Tuesday, February 27, 2018 at 11:49:09 AM UTC-6, Search Guard wrote: > > \> \> you can just omit the bind\_dn and password, then a LDAP anonymous bind will be performed which seems the way to go in your setup > > \> \> > > \> \> If this is still not working than pls enable debug logging and post (or mail) the complete logfile. Pls refer to [TLS help | Security for Elasticsearch | Search Guard](http://docs.search-guard.com/latest/troubleshooting-tls#setting-the-log-level-to-debug) > > \> \> > > \> \> Hello, > > \> \> I am still stuck with LDAP. The log file is attached. > > \> \> Thank you, > > \> \> Igor > > \> \> > > \> \> > > \> \> > > \> \> > > \> \> > > \> \> > > \> \> \> Am 19.02.2018 um 23:00 schrieb Igor Yakushin \: > > \> \> \> > > \> \> \> > > \> \> \> > > \> \> \> On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin \ wrote: > > \> \> \> Yes, usually you need a user (in LDAP terminology: bind\_dn) and password to talk to an LDAP server. But this depends on how your LDAP is configured actually: If it allows anonymous (usually read-only) access then you can skip the bind\_dn and password section if the sg\_config LDAP configuration. Search Guard will then try to access the server without bind\_dn and password. But if your LDAP server requires authentication, then you need to add the bind\_dn and password. This depends on what server you user and how it is configured. > > \> \> \> > > \> \> \> > > \> \> \> Is there a way to figure out how my server is configured by using for example 'ldapsearch' or some other tool? > > \> \> \> > > \> \> \> I looked into a working java program that creates a web page where users can type their credentials and get access via LDAP to our system and at first glance I do not see that it is using any password to query LDAP server (except for the credentials of the user that tries to login): > > \> \> \> ========== > > \> \> \> environment.put(javax.naming.Context.PROVIDER\_URL, "ldaps://ldap.uchicago.edu"); > > \> \> \> environment.put(javax.naming.Context.SECURITY\_AUTHENTICATION, "simple"); > > \> \> \> environment.put(javax.naming.Context.SECURITY\_PRINCIPAL, usernameFormatted); > > \> \> \> environment.put(javax.naming.Context.SECURITY\_CREDENTIALS, password); > > \> \> \> DirContext ctx = new InitialDirContext(environment); > > \> \> \> SearchControls controls = new SearchControls(); > > \> \> \> controls.setSearchScope(SearchControls.SUBTREE\_SCOPE); > > \> \> \> NamingEnumeration\ results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls); > > \> \> \> ========== > > \> \> \> Here is also a working php code > > \> \> \> ========== > > \> \> \> \ > \> \> \> $ldap\_dn = "uid=".$\_POST["username"].",dc=uchicago,dc=edu"; > > \> \> \> $ldap\_password = $\_POST["password"]; > > \> \> \> $ldap\_con = ldap\_connect("ldap.uchicago.edu","636"); > > \> \> \> ldap\_set\_option($ldap\_con, LDAP\_OPT\_PROTOCOL\_VERSION, 3); > > \> \> \> > > \> \> \> if(@ldap\_bind($ldap\_con,$ldap\_dn,$ldap\_password)) > > \> \> \> echo "Authenticated"; > > \> \> \> else > > \> \> \> echo "Invalid Credential"; > > \> \> \> ?\> > > \> \> \> ========== > > \> \> \> Apparently I should be using ldap.uchicago.edu:636. That probably means that I should use > > \> \> \> enable\_ssl\_client\_auth: true > > \> \> \> ? > > \> \> \> > > \> \> \> Can you tell me from above what bind\_dn, userbase I should use? > > \> \> \> > > \> \> \> I tried the following settings for both authc and authz but still no luck: > > \> \> \> > > \> \> \> ========== > > \> \> \> enable\_ssl\_client\_auth: true > > \> \> \> hosts: > > \> \> \> - ldap.uchicago.edu:636 > > \> \> \> bind\_dn: 'dc=uchicago,dc=edu' > > \> \> \> #password: password > > \> \> \> userbase: 'ou=people,dc=uchicago,dc=edu' > > \> \> \> > > \> \> \> ========== > > \> \> \> LDAP response read timed out, timeout used:5000ms., providerException=javax.naming. > > \> \> \> NamingException: LDAP response read timed out, timeout used:5000ms.]. Try next. > > \> \> \> [2018-02-19T15:57:52,005][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > \> \> \> > > \> \> \> ========== > > \> \> \> > > \> \> \> > > \> \> \> On Monday, February 19, 2018 at 6:38:23 PM UTC+1, iv...@uchicago.edu wrote: > > \> \> \> Hi Jochen, > > \> \> \> After following your recommendations I am now getting a different kind of error when trying to use my LDAP credentials to log into ES: > > \> \> \> ========= > > \> \> \> No password given for bind\_dn cn=admin,dc=rcc,dc=uchica > > \> \> \> go,dc=edu. Will try to authenticate anonymously to ldap > > \> \> \> [2018-02-19T11:20:13,156][WARN][c.f.s.a.BackendRegistry] Authentication finally failed for ivy2 > > \> \> \> ========= > > \> \> \> Does one normally have to use something like a password or certificate to talk to LDAP? What bind\_dn is usually given? > > \> \> \> Thank you, > > \> \> \> Igor > > \> \> \> > > \> \> \> > > \> \> \> On Monday, February 19, 2018 at 4:54:05 AM UTC-6, Jochen Kressin wrote: > > \> \> \> From the configs and screeshots and LDAP config you sent I see that you enable TLS and also want to verify hostnames: > > \> \> \> > > \> \> \> enable\_ssl: true > > \> \> \> verify\_hostnames: true > > \> \> \> > > \> \> \> This means that the connection to LDAP will be TLS encrypted and that Search Guard needs to verify the TLS certificate that the LDAP server sends against a Root CA / trusted CA. So in order to use TLS, you need to configure the trusted CAs in the LDAP module. This would be the root and/or signing certificate of the certificate you installed on the LDAP server. > > \> \> \> > > \> \> \> However, in the LDAP config you specify port 389 for the LDAP connection, which is usually used for plain / unencrypted connections. The port for TLS would be 636. Are you sure your LDAP server listens in port 389 for TLS connections? What happens if you configure: > > \> \> \> > > \> \> \> enable\_ssl: false > > \> \> \> verify\_hostnames: false > > \> \> \> > > \> \> \> > > \> \> \> > > \> \> \> On Sunday, February 18, 2018 at 6:03:25 AM UTC+1, iv...@uchicago.edu wrote: > > \> \> \> Hello, > > \> \> \> > > \> \> \> I have just started playing with Search Guard and got stuck configuring LDAP. > > \> \> \> > > \> \> \> First I installed the demo. It worked OK except I do not see "Tenants" tab on the left as the document says. See the screenshot. Is it a problem? I do want each user to be able to store his Kibana dashboards both privately and publicly. > > \> \> \> > > \> \> \> Next I tried to enable LDAP. When I try to connect to ES from a web browser using userid/password from LDAP, I am getting in ES logs: > > \> \> \> ==== > > \> \> \> Unable to connect to ldapserver 128.135.112.111:389 due > > \> \> \> to ElasticsearchException[Empty file path for searchguard.ssl.transport.truststore\_filepath] > > \> \> \> ==== > > \> \> \> > > \> \> \> How to fix it? > > \> \> \> Do I have to use truststore? Currently I just have whatever certificates were generated by demo. > > \> \> \> > > \> \> \> ldapsearch -x -v -h 128.135.112.111 -p 389 -b "dc=rcc,dc=uchicago,dc=edu" > > \> \> \> from the host I am running ES on works fine. > > \> \> \> > > \> \> \> Once I'll manage to configure LDAP, besides Kibana, I want to be able to use ES from python. > > \> \> \> What options do I need to specify to > > \> \> \> === > > \> \> \> from elasticsearch import Elasticsearch > > \> \> \> es = Elasticsearch() > > \> \> \> === > > \> \> \> to connect to the protected ES when running on the same host where Kibana and ES are running from inside user account known to LDAP? > > \> \> \> > > \> \> \> Thank you, > > \> \> \> Igor > > \> \> \> > > \> \> \> > > \> \> \> ===================== > > \> \> \> When asking questions, please provide the following information: > > \> \> \> > > \> \> \> \* Search Guard and Elasticsearch version > > \> \> \> > > \> \> \> 6.2.1 > > \> \> \> > > \> \> \> \* Installed and used enterprise modules, if any > > \> \> \> > > \> \> \> Elasticsearch, Kibana, Search Guard > > \> \> \> > > \> \> \> \* JVM version and operating system version > > \> \> \> > > \> \> \> 1.8.0\_121 > > \> \> \> CentOS 7.2 > > \> \> \> > > \> \> \> \* Search Guard configuration files > > \> \> \> > > \> \> \> Attached > > \> \> \> > > \> \> \> \* Elasticsearch log messages on debug level > > \> \> \> > > \> \> \> Attached > > \> \> \> > > \> \> \> \* Other installed Elasticsearch or Kibana plugins, if any > > \> \> \> > > \> \> \> None > > \> \> \> ======================= > > \> \> \> > > \> \> \> -- > > \> \> \> You received this message because you are subscribed to a topic in the Google Groups "Search Guard Community Forum" group. > > \> \> \> To unsubscribe from this topic, visit [https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe\](https://groups.google.com/d/topic/search-guard/jVjrVCh0yLY/unsubscribe%5C). > > \> \> \> To unsubscribe from this group and all its topics, send an email to search-guard...@googlegroups.com. > > \> \> \> To post to this group, send email to search...@googlegroups.com. > > \> \> \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/8d481577-a50a-4343-aaa2-9af7c39f4ed8%40googlegroups.com%5C). > > \> \> \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \> \> \> > > \> \> \> > > \> \> \> > > \> \> \> -- > > \> \> \> Igor Yakushin, Ph.D. > > \> \> \> Computational Scientist > > \> \> \> Kavli Institute for Cosmological Physics, ERC #413 > > \> \> \> Research Computing Center, room #2 > > \> \> \> The University of Chicago > > \> \> \> 773-834-5313 > > \> \> \> [https://rcc.uchicago.edu](https://rcc.uchicago.edu) > > \> \> \> > > \> \> \> > > \> \> \> -- > > \> \> \> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > \> \> \> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com. > > \> \> \> To post to this group, send email to search...@googlegroups.com. > > \> \> \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com\](https://groups.google.com/d/msgid/search-guard/CALQ0CdWtMVG1cC328x3Fdu3NHtvKBb2DQRLxgh3jjrkUSXSrsA%40mail.gmail.com%5C). > > \> \> \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \> \> > > \> \> > > \> \> -- > > \> \> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > \> \> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com. > > \> \> To post to this group, send email to search...@googlegroups.com. > > \> \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/4ebf3dfe-f450-4a0e-8bc4-959c4e367301%40googlegroups.com%5C). > > \> \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \> \> \ > > \> > > \> > > \> -- > > \> You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > \> To unsubscribe from this group and stop receiving emails from it, send an email to search-guard...@googlegroups.com. > > \> To post to this group, send email to search...@googlegroups.com. > > \> To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/6f62d946-09ff-4512-867d-930551947e39%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/6f62d946-09ff-4512-867d-930551947e39%40googlegroups.com%5C). > > \> For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \> \\ > > > > -- > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/14d553e7-4c21-47da-9a4c-eb30fb41eb61%40googlegroups.com\](https://groups.google.com/d/msgid/search-guard/14d553e7-4c21-47da-9a4c-eb30fb41eb61%40googlegroups.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \\ ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [March 14, 2018, 1:16am UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/13 "2018-03-14T01:16:45Z")
The error changed but still no luck. The files are attached. Is the user from which account Elastic Search is running supposed to be known to LDAP? I created a local elasticsearch account that LDAP does not know about. Does it matter? If I can run ldapsearch from this account successfully: ldapsearch -x -v -h ldap.rcc.uchicago.edu -p 389 -b "uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu" does it tell anything about SearchGuard's ability to use LDAP or this is not related? [log.txt](https://forum.search-guard.com/uploads/short-url/38PR3bdgWy6PqYiXw6ZynV2yx56.txt) (169 KB) [sg\_config.yml](https://forum.search-guard.com/uploads/short-url/gZqpHzI4KqQbJXKBV37HveqMpN1.yml) (9.9 KB) > **···** > > On Tue, Mar 13, 2018 at 5:54 PM, SG \ wrote: > > > pls add this to the sg\_config.yml (same indent level as enable\_ssl) > > > > pemtrustedcas\_filepath: HadoopCertificates/incommon.crt ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [March 14, 2018, 11:44am UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/14 "2018-03-14T11:44:35Z")
If ldapsearch -x -v -h ldap.rcc.uchicago.edu -p 389 -b "uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu" works then you can also try enable\_ssl: false enable\_start\_tls: false enable\_ssl\_client\_auth: false verify\_hostnames: false hosts:   - ldap.rcc.uchicago.edu:389   - ldap.uchicago.edu:389 > **···** > > > Am 14.03.2018 um 02:16 schrieb Igor Yakushin \: > > > > On Tue, Mar 13, 2018 at 5:54 PM, SG \ wrote: > > pls add this to the sg\_config.yml (same indent level as enable\_ssl) > > > > pemtrustedcas\_filepath: HadoopCertificates/incommon.crt > > > > The error changed but still no luck. The files are attached. > > > > Is the user from which account Elastic Search is running supposed to be known to LDAP? I created a local elasticsearch account that LDAP does not know about. Does it matter? > > > > If I can run ldapsearch from this account successfully: > > ldapsearch -x -v -h ldap.rcc.uchicago.edu -p 389 -b "uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu" > > does it tell anything about SearchGuard's ability to use LDAP or this is not related? > > > > -- > > You received this message because you are subscribed to the Google Groups "Search Guard Community Forum" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com. > > To post to this group, send email to search-guard@googlegroups.com. > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha\_0AWe4ikAfunbO\_eYCZv26D7J\_2bbZai%3DmJD\_PRA%40mail.gmail.com\](https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha_0AWe4ikAfunbO_eYCZv26D7J_2bbZai%3DmJD_PRA%40mail.gmail.com%5C). > > For more options, visit [https://groups.google.com/d/optout\](https://groups.google.com/d/optout%5C). > > \\ ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [March 14, 2018, 3:58pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/15 "2018-03-14T15:58:52Z")
> If ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” works then you can also try > > enable\_ssl: false > > enable\_start\_tls: false > enable\_ssl\_client\_auth: false > verify\_hostnames: false > hosts: > > - [ldap.rcc.uchicago.edu:389](http://ldap.rcc.uchicago.edu:389) > > - [ldap.uchicago.edu:389](http://ldap.uchicago.edu:389) It still does not work. The logs and the configuration file is attached. I have root access to ldap.rcc.uchicago.edu. Is there some log that would tell if my request reaches LDAP server and if it does, why the user is not found? At first glance, I did not find such a log. > **···** > > On Wednesday, March 14, 2018 at 6:44:38 AM UTC-5, Search Guard wrote: > > > > Am 14.03.2018 um 02:16 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > On Tue, Mar 13, 2018 at 5:54 PM, SG [in...@search-guard.com](mailto:in...@search-guard.com) wrote: > > > > > pls add this to the sg\_config.yml (same indent level as enable\_ssl) > > > > > pemtrustedcas\_filepath: HadoopCertificates/incommon.crt > > > > > The error changed but still no luck. The files are attached. > > > > > Is the user from which account Elastic Search is running supposed to be known to LDAP? I created a local elasticsearch account that LDAP does not know about. Does it matter? > > > > > If I can run ldapsearch from this account successfully: > > > > > ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” > > > > > does it tell anything about SearchGuard’s ability to use LDAP or this is not related? > > > > > – > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha\_0AWe4ikAfunbO\_eYCZv26D7J\_2bbZai%3DmJD\_PRA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha_0AWe4ikAfunbO_eYCZv26D7J_2bbZai%3DmJD_PRA%40mail.gmail.com). > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > \\ ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [March 14, 2018, 4:02pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/16 "2018-03-14T16:02:43Z")
nothing attached On Wednesday, 14 March 2018 16:58:53 UTC+1 > **···** > > > On Wednesday, March 14, 2018 at 6:44:38 AM UTC-5, Search Guard wrote: > > > > > If ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” works then you can also try > > > > > > enable\_ssl: false > > > > > > enable\_start\_tls: false > > > enable\_ssl\_client\_auth: false > > > verify\_hostnames: false > > > hosts: > > > > > > - [ldap.rcc.uchicago.edu:389](http://ldap.rcc.uchicago.edu:389) > > > > > > - [ldap.uchicago.edu:389](http://ldap.uchicago.edu:389) > > > > > > It still does not work. The logs and the configuration file is attached. > > > > > > I have root access to [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu). Is there some log that would tell if my request reaches LDAP server and if it does, why the user is not found? > > > At first glance, I did not find such a log. > > > > > > > > > > > Am 14.03.2018 um 02:16 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > > > On Tue, Mar 13, 2018 at 5:54 PM, SG [in...@search-guard.com](mailto:in...@search-guard.com) wrote: > > > > > > > pls add this to the sg\_config.yml (same indent level as enable\_ssl) > > > > > > > pemtrustedcas\_filepath: HadoopCertificates/incommon.crt > > > > > > > The error changed but still no luck. The files are attached. > > > > > > > Is the user from which account Elastic Search is running supposed to be known to LDAP? I created a local elasticsearch account that LDAP does not know about. Does it matter? > > > > > > > If I can run ldapsearch from this account successfully: > > > > > > > ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” > > > > > > > does it tell anything about SearchGuard’s ability to use LDAP or this is not related? > > > > > > > – > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha\_0AWe4ikAfunbO\_eYCZv26D7J\_2bbZai%3DmJD\_PRA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha_0AWe4ikAfunbO_eYCZv26D7J_2bbZai%3DmJD_PRA%40mail.gmail.com). > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > \\ ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [March 14, 2018, 4:10pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/17 "2018-03-14T16:10:50Z")
Oh, sorry, fixed. How important are permissions on certificate files? Originally there were complaints about insecure permissions. I fixed that. Also, to double check how changes from sg\_config.yml propagate into Elastic Search: once I change this file, I run: [log.txt](https://forum.search-guard.com/uploads/short-url/rhpiL2Fc1m6mO51otu2J2SiYfcB.txt) (64.9 KB) [sg\_config.yml](https://forum.search-guard.com/uploads/short-url/ey5YsBZuYkzcuUQvtalI3sc6fxt.yml) (10.1 KB) > **···** > > On Wednesday, March 14, 2018 at 11:02:43 AM UTC-5, Search Guard wrote: > > > nothing attached > > === > > /home\_local/elasticsearch/elasticsearch-6.2.1/plugins/search-guard-6/tools/sgadmin.sh -cd /home\_local/elasticsearch/ela > sticsearch-6.2.1/plugins/search-guard-6/sgconfig -icl -key /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopC > ertificates/hadoop.rcc.uchicago.edu-key.pem -cert /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopCertificat > es/hadoop.rcc.uchicago.edu-chain.crt -cacert /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopCertificates/in > common.crt -nhnv > > === > > from tools directory and get messages that the changes were successful (provided that elastic search is running). > > As far as I understand, elasticsearch does not have to be restarted after such changes? > > > On Wednesday, 14 March 2018 16:58:53 UTC+1 > > > > > On Wednesday, March 14, 2018 at 6:44:38 AM UTC-5, Search Guard wrote: > > > > > > > If ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” works then you can also try > > > > > > > > enable\_ssl: false > > > > > > > > enable\_start\_tls: false > > > > enable\_ssl\_client\_auth: false > > > > verify\_hostnames: false > > > > hosts: > > > > > > > > - [ldap.rcc.uchicago.edu:389](http://ldap.rcc.uchicago.edu:389) > > > > > > > > - [ldap.uchicago.edu:389](http://ldap.uchicago.edu:389) > > > > > > > > It still does not work. The logs and the configuration file is attached. > > > > > > > > I have root access to [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu). Is there some log that would tell if my request reaches LDAP server and if it does, why the user is not found? > > > > At first glance, I did not find such a log. > > > > > > > > > > > > > > Am 14.03.2018 um 02:16 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > > > > > On Tue, Mar 13, 2018 at 5:54 PM, SG [in...@search-guard.com](mailto:in...@search-guard.com) wrote: > > > > > > > > > pls add this to the sg\_config.yml (same indent level as enable\_ssl) > > > > > > > > > pemtrustedcas\_filepath: HadoopCertificates/incommon.crt > > > > > > > > > The error changed but still no luck. The files are attached. > > > > > > > > > Is the user from which account Elastic Search is running supposed to be known to LDAP? I created a local elasticsearch account that LDAP does not know about. Does it matter? > > > > > > > > > If I can run ldapsearch from this account successfully: > > > > > > > > > ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” > > > > > > > > > does it tell anything about SearchGuard’s ability to use LDAP or this is not related? > > > > > > > > > – > > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha\_0AWe4ikAfunbO\_eYCZv26D7J\_2bbZai%3DmJD\_PRA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha_0AWe4ikAfunbO_eYCZv26D7J_2bbZai%3DmJD_PRA%40mail.gmail.com). > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > \\ ---
**Author:** ![searchguard\_google\_group](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.search-guard.com/searchguard_google_group/32/462_2.png) [@searchguard\_google\_group](https://forum.search-guard.com/u/searchguard_google_group)\ **Post date:** [March 14, 2018, 4:34pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/18 "2018-03-14T16:34:06Z")
connection seems ok but the user is not found. you need to set these props correctly: userbase: username\_attribute: usersearch: see [LDAP Authentication | Security for Elasticsearch | Search Guard](https://docs.search-guard.com/latest/active-directory-ldap-authentication#active-directory-and-ldap-authentication) On Wednesday, 14 March 2018 17:10:50 UTC+1, > **···** > > > On Wednesday, March 14, 2018 at 11:02:43 AM UTC-5, Search Guard wrote: > > > > > nothing attached > > > > > > Oh, sorry, fixed. > > > > > > How important are permissions on certificate files? Originally there were complaints about insecure permissions. I fixed that. > > > > > > Also, to double check how changes from sg\_config.yml propagate into Elastic Search: once I change this file, I run: > > > === > > > /home\_local/elasticsearch/elasticsearch-6.2.1/plugins/search-guard-6/tools/sgadmin.sh -cd /home\_local/elasticsearch/ela > > sticsearch-6.2.1/plugins/search-guard-6/sgconfig -icl -key /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopC > > ertificates/hadoop.rcc.uchicago.edu-key.pem -cert /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopCertificat > > es/hadoop.rcc.uchicago.edu-chain.crt -cacert /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopCertificates/in > > common.crt -nhnv > > > === > > > from tools directory and get messages that the changes were successful (provided that elastic search is running). > > > As far as I understand, elasticsearch does not have to be restarted after such changes? > > > > > > > > > > > > > On Wednesday, 14 March 2018 16:58:53 UTC+1 > > > > > > > On Wednesday, March 14, 2018 at 6:44:38 AM UTC-5, Search Guard wrote: > > > > > > > > > If ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” works then you can also try > > > > > > > > > > enable\_ssl: false > > > > > > > > > > enable\_start\_tls: false > > > > > enable\_ssl\_client\_auth: false > > > > > verify\_hostnames: false > > > > > hosts: > > > > > > > > > > - [ldap.rcc.uchicago.edu:389](http://ldap.rcc.uchicago.edu:389) > > > > > > > > > > - [ldap.uchicago.edu:389](http://ldap.uchicago.edu:389) > > > > > > > > > > It still does not work. The logs and the configuration file is attached. > > > > > > > > > > I have root access to [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu). Is there some log that would tell if my request reaches LDAP server and if it does, why the user is not found? > > > > > At first glance, I did not find such a log. > > > > > > > > > > > > > > > > > Am 14.03.2018 um 02:16 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > > > > > > > On Tue, Mar 13, 2018 at 5:54 PM, SG [in...@search-guard.com](mailto:in...@search-guard.com) wrote: > > > > > > > > > > > pls add this to the sg\_config.yml (same indent level as enable\_ssl) > > > > > > > > > > > pemtrustedcas\_filepath: HadoopCertificates/incommon.crt > > > > > > > > > > > The error changed but still no luck. The files are attached. > > > > > > > > > > > Is the user from which account Elastic Search is running supposed to be known to LDAP? I created a local elasticsearch account that LDAP does not know about. Does it matter? > > > > > > > > > > > If I can run ldapsearch from this account successfully: > > > > > > > > > > > ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” > > > > > > > > > > > does it tell anything about SearchGuard’s ability to use LDAP or this is not related? > > > > > > > > > > > – > > > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > > > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > > > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha\_0AWe4ikAfunbO\_eYCZv26D7J\_2bbZai%3DmJD\_PRA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha_0AWe4ikAfunbO_eYCZv26D7J_2bbZai%3DmJD_PRA%40mail.gmail.com). > > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > > \\ ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [March 14, 2018, 7:45pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/19 "2018-03-14T19:45:59Z")
> connection seems ok but the user is not found. > you need to set these props correctly: > > userbase: > username\_attribute: > usersearch: > > see [https://docs.search-guard.com/latest/active-directory-ldap-authentication#active-directory-and-ldap-authentication](https://docs.search-guard.com/latest/active-directory-ldap-authentication#active-directory-and-ldap-authentication) It does not really explain to me how to find out those strings. Based on the fact that ldapsearch works: ldapsearch -x -v -h ldap.rcc.uchicago.edu -p 389 -b "uid=ivy2,ou=People,dc=rcc,dc =uchicago,dc=edu" I tried the following: authentication\_backend: bind\_dn: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ userbase: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ usersearch: ‘(sAMAccountName={0})’ username\_attribute: uid authz: bind\_dn: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ rolebase: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ rolesearch: ‘(member={0})’ userbase: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ usersearch: ‘(uid={0})’ [log.txt](https://forum.search-guard.com/uploads/short-url/1DEJgLFn8f8SBk5vitt53IJxcjF.txt) (66.1 KB) [sg\_config.yml](https://forum.search-guard.com/uploads/short-url/qIexoeMa6Jmmgd6O7AgJYJk4JF1.yml) (9.9 KB) > **···** > > On Wednesday, March 14, 2018 at 11:34:06 AM UTC-5, Search Guard wrote: > > > On Wednesday, 14 March 2018 17:10:50 UTC+1, > > > > > On Wednesday, March 14, 2018 at 11:02:43 AM UTC-5, Search Guard wrote: > > > > > > > nothing attached > > > > > > > > Oh, sorry, fixed. > > > > > > > > How important are permissions on certificate files? Originally there were complaints about insecure permissions. I fixed that. > > > > > > > > Also, to double check how changes from sg\_config.yml propagate into Elastic Search: once I change this file, I run: > > > > === > > > > /home\_local/elasticsearch/elasticsearch-6.2.1/plugins/search-guard-6/tools/sgadmin.sh -cd /home\_local/elasticsearch/ela > > > sticsearch-6.2.1/plugins/search-guard-6/sgconfig -icl -key /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopC > > > ertificates/hadoop.rcc.uchicago.edu-key.pem -cert /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopCertificat > > > es/hadoop.rcc.uchicago.edu-chain.crt -cacert /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopCertificates/in > > > common.crt -nhnv > > > > === > > > > from tools directory and get messages that the changes were successful (provided that elastic search is running). > > > > As far as I understand, elasticsearch does not have to be restarted after such changes? > > > > > > > > > > > > > > > > > On Wednesday, 14 March 2018 16:58:53 UTC+1 > > > > > > > > > On Wednesday, March 14, 2018 at 6:44:38 AM UTC-5, Search Guard wrote: > > > > > > > > > > > If ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” works then you can also try > > > > > > > > > > > > enable\_ssl: false > > > > > > > > > > > > enable\_start\_tls: false > > > > > > enable\_ssl\_client\_auth: false > > > > > > verify\_hostnames: false > > > > > > hosts: > > > > > > > > > > > > - [ldap.rcc.uchicago.edu:389](http://ldap.rcc.uchicago.edu:389) > > > > > > > > > > > > - [ldap.uchicago.edu:389](http://ldap.uchicago.edu:389) > > > > > > > > > > > > It still does not work. The logs and the configuration file is attached. > > > > > > > > > > > > I have root access to [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu). Is there some log that would tell if my request reaches LDAP server and if it does, why the user is not found? > > > > > > At first glance, I did not find such a log. > > > > > > > > > > > > > > > > > > > > Am 14.03.2018 um 02:16 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > > > > > > > > > On Tue, Mar 13, 2018 at 5:54 PM, SG [in...@search-guard.com](mailto:in...@search-guard.com) wrote: > > > > > > > > > > > > > pls add this to the sg\_config.yml (same indent level as enable\_ssl) > > > > > > > > > > > > > pemtrustedcas\_filepath: HadoopCertificates/incommon.crt > > > > > > > > > > > > > The error changed but still no luck. The files are attached. > > > > > > > > > > > > > Is the user from which account Elastic Search is running supposed to be known to LDAP? I created a local elasticsearch account that LDAP does not know about. Does it matter? > > > > > > > > > > > > > If I can run ldapsearch from this account successfully: > > > > > > > > > > > > > ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” > > > > > > > > > > > > > does it tell anything about SearchGuard’s ability to use LDAP or this is not related? > > > > > > > > > > > > > – > > > > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > > > > > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > > > > > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha\_0AWe4ikAfunbO\_eYCZv26D7J\_2bbZai%3DmJD\_PRA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha_0AWe4ikAfunbO_eYCZv26D7J_2bbZai%3DmJD_PRA%40mail.gmail.com). > > > > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > > > > \\ ---
**Author:** ![Igor\_Yakushin](https://avatars.discourse-cdn.com/v4/letter/i/898d66/32.png) [@Igor\_Yakushin](https://forum.search-guard.com/u/Igor_Yakushin)\ **Post date:** [March 14, 2018, 8:39pm UTC](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809/20 "2018-03-14T20:39:01Z")
I think, I am getting somewhere after changing usersearch. Now in the web browser I am getting an error: [log.txt](https://forum.search-guard.com/uploads/short-url/xCybHkg9Q73VaLa502dQUpxPX4m.txt) (34.1 KB) [sg\_config.yml](https://forum.search-guard.com/uploads/short-url/l4SsPUmO6ci1MYI2Qp7uj4JwinO.yml) (9.94 KB) > **···** > > ===================== > > {“error”:{“root\_cause”:[{“type”:“security\_exception”,“reason”:“no permissions for [cluster:monitor/main] and User [name=ivy2, roles=, requestedTenant=null]”}],“type”:“security\_exception”,“reason”:“no permissions for [cluster:monitor/main] and User [name=ivy2, roles=, requestedTenant=null]”},“status”:403} > > ===================== > > Does that mean that I finally got through LDAP but I need to configure the role somehow? > > The logs and configuration are attached. > > On Wednesday, March 14, 2018 at 2:45:59 PM UTC-5, iv…@uchicago.edu wrote: > > > On Wednesday, March 14, 2018 at 11:34:06 AM UTC-5, Search Guard wrote: > > > > > connection seems ok but the user is not found. > > > you need to set these props correctly: > > > > > > > > userbase: > > > > username\_attribute: > > > > usersearch: > > > > > > > > see [https://docs.search-guard.com/latest/active-directory-ldap-authentication#active-directory-and-ldap-authentication](https://docs.search-guard.com/latest/active-directory-ldap-authentication#active-directory-and-ldap-authentication) > > > > > > > > > It does not really explain to me how to find out those strings. > > > Based on the fact that ldapsearch works: > > > > > > ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b "uid=ivy2,ou=People,dc=rcc,dc > > > =uchicago,dc=edu" > > > > > > > > > I tried the following: > > > > > > authentication\_backend: > > > > > > bind\_dn: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ > > > userbase: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ > > > usersearch: ‘(sAMAccountName={0})’ > > > username\_attribute: uid > > > > > > authz: > > > bind\_dn: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ > > > rolebase: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ > > > rolesearch: ‘(member={0})’ > > > userbase: ‘ou=People,dc=rcc,dc=uchicago,dc=edu’ > > > usersearch: ‘(uid={0})’ > > > > > > > > > > > > > > > > On Wednesday, 14 March 2018 17:10:50 UTC+1, > > > > > > > On Wednesday, March 14, 2018 at 11:02:43 AM UTC-5, Search Guard wrote: > > > > > > > > > nothing attached > > > > > > > > > > Oh, sorry, fixed. > > > > > > > > > > How important are permissions on certificate files? Originally there were complaints about insecure permissions. I fixed that. > > > > > > > > > > Also, to double check how changes from sg\_config.yml propagate into Elastic Search: once I change this file, I run: > > > > > === > > > > > /home\_local/elasticsearch/elasticsearch-6.2.1/plugins/search-guard-6/tools/sgadmin.sh -cd /home\_local/elasticsearch/ela > > > > sticsearch-6.2.1/plugins/search-guard-6/sgconfig -icl -key /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopC > > > > ertificates/hadoop.rcc.uchicago.edu-key.pem -cert /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopCertificat > > > > es/hadoop.rcc.uchicago.edu-chain.crt -cacert /home\_local/elasticsearch/elasticsearch-6.2.1/config/HadoopCertificates/in > > > > common.crt -nhnv > > > > > === > > > > > from tools directory and get messages that the changes were successful (provided that elastic search is running). > > > > > As far as I understand, elasticsearch does not have to be restarted after such changes? > > > > > > > > > > > > > > > > > > > > > On Wednesday, 14 March 2018 16:58:53 UTC+1 > > > > > > > > > > > On Wednesday, March 14, 2018 at 6:44:38 AM UTC-5, Search Guard wrote: > > > > > > > > > > > > > If ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” works then you can also try > > > > > > > > > > > > > > enable\_ssl: false > > > > > > > > > > > > > > enable\_start\_tls: false > > > > > > > enable\_ssl\_client\_auth: false > > > > > > > verify\_hostnames: false > > > > > > > hosts: > > > > > > > > > > > > > > - [ldap.rcc.uchicago.edu:389](http://ldap.rcc.uchicago.edu:389) > > > > > > > > > > > > > > - [ldap.uchicago.edu:389](http://ldap.uchicago.edu:389) > > > > > > > > > > > > > > It still does not work. The logs and the configuration file is attached. > > > > > > > > > > > > > > I have root access to [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu). Is there some log that would tell if my request reaches LDAP server and if it does, why the user is not found? > > > > > > > At first glance, I did not find such a log. > > > > > > > > > > > > > > > > > > > > > > > Am 14.03.2018 um 02:16 schrieb Igor Yakushin [iv...@uchicago.edu](mailto:iv...@uchicago.edu): > > > > > > > > > > > > > > > On Tue, Mar 13, 2018 at 5:54 PM, SG [in...@search-guard.com](mailto:in...@search-guard.com) wrote: > > > > > > > > > > > > > > > pls add this to the sg\_config.yml (same indent level as enable\_ssl) > > > > > > > > > > > > > > > pemtrustedcas\_filepath: HadoopCertificates/incommon.crt > > > > > > > > > > > > > > > The error changed but still no luck. The files are attached. > > > > > > > > > > > > > > > Is the user from which account Elastic Search is running supposed to be known to LDAP? I created a local elasticsearch account that LDAP does not know about. Does it matter? > > > > > > > > > > > > > > > If I can run ldapsearch from this account successfully: > > > > > > > > > > > > > > > ldapsearch -x -v -h [ldap.rcc.uchicago.edu](http://ldap.rcc.uchicago.edu) -p 389 -b “uid=ivy2,ou=People,dc=rcc,dc=uchicago,dc=edu” > > > > > > > > > > > > > > > does it tell anything about SearchGuard’s ability to use LDAP or this is not related? > > > > > > > > > > > > > > > – > > > > > > > > You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group. > > > > > > > > > > > > > > > To unsubscribe from this group and stop receiving emails from it, send an email to [search-guard...@googlegroups.com](mailto:search-guard...@googlegroups.com). > > > > > > > > > > > > > > > To post to this group, send email to [search...@googlegroups.com](mailto:search...@googlegroups.com). > > > > > > > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha\_0AWe4ikAfunbO\_eYCZv26D7J\_2bbZai%3DmJD\_PRA%40mail.gmail.com](https://groups.google.com/d/msgid/search-guard/CALQ0CdW9ha_0AWe4ikAfunbO_eYCZv26D7J_2bbZai%3DmJD_PRA%40mail.gmail.com). > > > > > > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > > > > > > > > > > > > \\ [Next page](https://forum.search-guard.com/t/empty-file-path-for-searchguard-ssl-transport-truststore-filepath/809.md?page=2)