Am 19.02.2018 um 23:00 schrieb Igor Yakushin <ivy2@uchicago.edu>:
On Mon, Feb 19, 2018 at 2:44 PM, Jochen Kressin <jkressin@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");
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<SearchResult> results = ctx.search("ou=people,dc=uchicago,dc=edu", "uid="+username, controls);
Here is also a working php code
<?php
$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\.
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\.
For more options, visit 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
--
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\.
For more options, visit https://groups.google.com/d/optout\.
