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.
--
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.
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...@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.
For more options, visit https://groups.google.com/d/optout.
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
pls add this to the sg_config.yml (same indent level as enable_ssl)
pemtrustedcas_filepath: HadoopCertificates/incommon.crt
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
nothing attached
userbase:
username_attribute:
usersearch:
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
yes, authentication succeeded! now its about the roles ...
If that is working then try setting verify_hostnames to true (because false is insecure)
> 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...@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.
> For more options, visit https://groups.google.com/d/optout.
> <elasticsearch.yml><sg_config.yml>
--
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.
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/CB47BA77-DD0A-418A-9E01-8D259D9EB908%40search-guard.com.
For more options, visit https://groups.google.com/d/optout.
And another question: how to secure Kibana?In the demo kibanaserver user is created that uses password given in plain text in Kibana configuration file. I changed that password both on elasticsearch and kibana sides but it is still quite insecure. Do I understand correctly that I can instead use the same certificates as I used for LDAP to get rid of password authentication (or at least not to have it in a plain text format) and enable SSL?