Can't Activate LDAP Module 5.0-7

I’ve installed and run the searchguard demo without any problem. I’ve also configured the Kibana plugin and I was able to login with users kibanaro and admin, provided on the demo configs.

Now, I downloaded the LDAP module and I’m tryng to integrate the login page with my LDAP server, but something is missing and searchguard completely ignores the new LDAP configuration. It continues to authenticate against the demo configs (users kibanaro and admin).

I copied dlic-search-guard-authbackend-ldap-5.0-7-jar-with-dependencies.jar to /opt/elasticsearch-5.4.3/plugins/search-guard-5/

And included the LDAP configs in the sg_config.yml

Is there anything else I need to change in elasticsearch.yml or kibana.yml in order to use LDAP authentication?

I’m using ELK 5.4.3, search-guard-5-5.4.3-14 and searchguard-kibana-5.4.3-3

In my sg_config.yml I have the following configuration:

searchguard:

dynamic:

kibana:

Kibana multitenancy - NOT FREE FOR COMMERCIAL USE

see https://github.com/floragunncom/search-guard-docs/blob/master/multitenancy.md

To make this work you need to install https://github.com/floragunncom/search-guard-module-kibana-multitenancy/wiki

#multitenancy_enabled: true

#server_username: kibanaserver

#index: ‘.kibana’

#do_not_fail_on_forbidden: false

http:

anonymous_auth_enabled: false

xff:

enabled: false

internalProxies: ‘192.168.0.10|192.168.0.11’ # regex pattern

#internalProxies: ‘.*’ # trust all internal proxies, regex pattern

remoteIpHeader: ‘x-forwarded-for’

proxiesHeader: ‘x-forwarded-by’

#trustedProxies: ‘.*’ # trust all external proxies, regex pattern

see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
and here https://tools.ietf.org/html/rfc7239
and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve

authc:

kerberos_auth_domain:

enabled: false

order: 6

http_authenticator:

type: kerberos # NOT FREE FOR COMMERCIAL USE

challenge: true

config:

If true a lot of kerberos/security related debugging output will be logged to standard out

krb_debug: false

If true then the realm will be stripped from the user name

strip_realm_from_principal: true

authentication_backend:

type: noop

basic_internal_auth_domain:

enabled: false

order: 1

http_authenticator:

type: basic

challenge: false

authentication_backend:

type: intern

proxy_auth_domain:

enabled: false

order: 3

http_authenticator:

type: proxy

challenge: false

config:

user_header: “x-proxy-user”

roles_header: “x-proxy-roles”

authentication_backend:

type: noop

host_auth_domain:

enabled: false

order: 1

http_authenticator:

type: host #DEPRECATED, will be removed in a future version

challenge: false

authentication_backend:

type: noop

jwt_auth_domain:

enabled: false

order: 0

http_authenticator:

type: jwt

challenge: false

config:

signing_key: “base64 encoded key”

jwt_header: “Authorization”

jwt_url_parameter: null

roles_key: null

subject_key: null

authentication_backend:

type: noop

clientcert_auth_domain:

enabled: false

order: 2

http_authenticator:

type: clientcert

config:

username_attribute: cn #optional, if omitted DN becomes username

challenge: false

authentication_backend:

type: noop

ldap:

enabled: true

order: 0

http_authenticator:

type: basic

challenge: false

authentication_backend:

config:

enable_ssl: true

enable_start_tls: false

enable_ssl_client_auth: false

verify_hostnames: true

hosts:

- :636

bind_dn: cn=,ou=ServiceAccounts,ou=people,o=,c=

password:

userbase: 'ou=people,o=,c='

usersearch: '(uid={0})'

username_attribute: name

authz:

roles_from_myldap:

enabled: false

authorization_backend:

LDAP authorization backend (gather roles from a LDAP or Active Directory, you have to configure the above LDAP authentication backend settings too)

type: ldap # NOT FREE FOR COMMERCIAL USE

config:

enable ldaps

enable_ssl: false

enable start tls, enable_ssl should be false

enable_start_tls: false

send client certificate

enable_ssl_client_auth: false

verify ldap hostname

verify_hostnames: true

hosts:

  • localhost:8389

bind_dn: null

password: null

rolebase: ‘ou=groups,dc=example,dc=com’

Filter to search for roles (currently in the whole subtree beneath rolebase)

{0} is substituted with the DN of the user

{1} is substituted with the username

{2} is substituted with an attribute value from user’s directory entry, of the authenticated user. Use userroleattribute to specify the name of the attribute

rolesearch: ‘(member={0})’

Specify the name of the attribute which value should be substituted with {2} above

userroleattribute: null

Roles as an attribute of the user entry

userrolename: disabled

#userrolename: memberOf

The attribute in a role entry containing the name of that role, Default is “name”.

Can also be “dn” to use the full DN as rolename.

rolename: cn

Resolve nested roles transitive (roles which are members of other roles and so on …)

resolve_nested_roles: true

userbase: ‘ou=people,dc=example,dc=com’

Filter to search for users (currently in the whole subtree beneath userbase)

{0} is substituted with the username

usersearch: ‘(uid={0})’

Skip users matching a user name, a wildcard or a regex pattern

#skip_users:

- ‘cn=Michael Jackson,ou*people,o=TEST’

- ‘/\S*/’

roles_from_another_ldap:

enabled: false

authorization_backend:

type: ldap # NOT FREE FOR COMMERCIAL USE

#config goes here …

No, this should work without problems, your configuration looks fine.

Are you sure you have updated the changed configuration with sgadmin after you made the changes?

If in doubt, you can always retrieve the currently active configuration from the Search Guard index with sgadmin and the -r/–retrieve option, and check which modules are enabled.

···

On Tuesday, July 18, 2017 at 7:57:56 PM UTC+2, Enio Perpetuo Junior wrote:

I’ve installed and run the searchguard demo without any problem. I’ve also configured the Kibana plugin and I was able to login with users kibanaro and admin, provided on the demo configs.

Now, I downloaded the LDAP module and I’m tryng to integrate the login page with my LDAP server, but something is missing and searchguard completely ignores the new LDAP configuration. It continues to authenticate against the demo configs (users kibanaro and admin).

I copied dlic-search-guard-authbackend-ldap-5.0-7-jar-with-dependencies.jar to /opt/elasticsearch-5.4.3/plugins/search-guard-5/

And included the LDAP configs in the sg_config.yml

Is there anything else I need to change in elasticsearch.yml or kibana.yml in order to use LDAP authentication?

I’m using ELK 5.4.3, search-guard-5-5.4.3-14 and searchguard-kibana-5.4.3-3

In my sg_config.yml I have the following configuration:

searchguard:

dynamic:

kibana:

Kibana multitenancy - NOT FREE FOR COMMERCIAL USE

see https://github.com/floragunncom/search-guard-docs/blob/master/multitenancy.md

To make this work you need to install https://github.com/floragunncom/search-guard-module-kibana-multitenancy/wiki

#multitenancy_enabled: true

#server_username: kibanaserver

#index: ‘.kibana’

#do_not_fail_on_forbidden: false

http:

anonymous_auth_enabled: false

xff:

enabled: false

internalProxies: ‘192.168.0.10|192.168.0.11’ # regex pattern

#internalProxies: ‘.*’ # trust all internal proxies, regex pattern

remoteIpHeader: ‘x-forwarded-for’

proxiesHeader: ‘x-forwarded-by’

#trustedProxies: ‘.*’ # trust all external proxies, regex pattern

see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
and here https://tools.ietf.org/html/rfc7239
and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve

authc:

kerberos_auth_domain:

enabled: false

order: 6

http_authenticator:

type: kerberos # NOT FREE FOR COMMERCIAL USE

challenge: true

config:

If true a lot of kerberos/security related debugging output will be logged to standard out

krb_debug: false

If true then the realm will be stripped from the user name

strip_realm_from_principal: true

authentication_backend:

type: noop

basic_internal_auth_domain:

enabled: false

order: 1

http_authenticator:

type: basic

challenge: false

authentication_backend:

type: intern

proxy_auth_domain:

enabled: false

order: 3

http_authenticator:

type: proxy

challenge: false

config:

user_header: “x-proxy-user”

roles_header: “x-proxy-roles”

authentication_backend:

type: noop

host_auth_domain:

enabled: false

order: 1

http_authenticator:

type: host #DEPRECATED, will be removed in a future version

challenge: false

authentication_backend:

type: noop

jwt_auth_domain:

enabled: false

order: 0

http_authenticator:

type: jwt

challenge: false

config:

signing_key: “base64 encoded key”

jwt_header: “Authorization”

jwt_url_parameter: null

roles_key: null

subject_key: null

authentication_backend:

type: noop

clientcert_auth_domain:

enabled: false

order: 2

http_authenticator:

type: clientcert

config:

username_attribute: cn #optional, if omitted DN becomes username

challenge: false

authentication_backend:

type: noop

ldap:

enabled: true

order: 0

http_authenticator:

type: basic

challenge: false

authentication_backend:

config:

enable_ssl: true

enable_start_tls: false

enable_ssl_client_auth: false

verify_hostnames: true

hosts:

- :636

bind_dn: cn=,ou=ServiceAccounts,ou=people,o=,c=

password:

userbase: 'ou=people,o=,c='

usersearch: '(uid={0})'

username_attribute: name

authz:

roles_from_myldap:

enabled: false

authorization_backend:

LDAP authorization backend (gather roles from a LDAP or Active Directory, you have to configure the above LDAP authentication backend settings too)

type: ldap # NOT FREE FOR COMMERCIAL USE

config:

enable ldaps

enable_ssl: false

enable start tls, enable_ssl should be false

enable_start_tls: false

send client certificate

enable_ssl_client_auth: false

verify ldap hostname

verify_hostnames: true

hosts:

  • localhost:8389

bind_dn: null

password: null

rolebase: ‘ou=groups,dc=example,dc=com’

Filter to search for roles (currently in the whole subtree beneath rolebase)

{0} is substituted with the DN of the user

{1} is substituted with the username

{2} is substituted with an attribute value from user’s directory entry, of the authenticated user. Use userroleattribute to specify the name of the attribute

rolesearch: ‘(member={0})’

Specify the name of the attribute which value should be substituted with {2} above

userroleattribute: null

Roles as an attribute of the user entry

userrolename: disabled

#userrolename: memberOf

The attribute in a role entry containing the name of that role, Default is “name”.

Can also be “dn” to use the full DN as rolename.

rolename: cn

Resolve nested roles transitive (roles which are members of other roles and so on …)

resolve_nested_roles: true

userbase: ‘ou=people,dc=example,dc=com’

Filter to search for users (currently in the whole subtree beneath userbase)

{0} is substituted with the username

usersearch: ‘(uid={0})’

Skip users matching a user name, a wildcard or a regex pattern

#skip_users:

- ‘cn=Michael Jackson,ou*people,o=TEST’

- ‘/\S*/’

roles_from_another_ldap:

enabled: false

authorization_backend:

type: ldap # NOT FREE FOR COMMERCIAL USE

#config goes here …

Thank you for your help.
I’ve not run sgadmin again after making the changes. So the configuration haven’t be applied at all.

After runing ./sgadmin_demo.sh e restarting the elastic nodes, the log messages helped me to complete the extra configs needed:

  • searchguard.cookie.password: “12345678901234567890123456789012”
  • searchguard.cookie.secure: true
    Now I’m getting another error, but because sg is not being able to connect to the ldapserver

[2017-07-20T10:47:54,337][WARN ][c.f.d.a.l.b.LDAPAuthorizationBackend] Unable to connect to ldapserver:636 due to [org.ldaptive.provider.ConnectionException@1104210828::resultCode=null, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, message=javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms., providerException=javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms.]. Try next.

[2017-07-20T10:47:54,339][WARN ][c.f.s.a.BackendRegistry ] Authentication finally failed for eperpetuo

Can you double check that the elasticsearch nodes are able to connect to ldapserver:636 (so that you can establish a tcp connection or try to connect to ldap with command line tools). Timeout maybe means that your firewall is dropping all packets or the ldap server runs on a different port.

···

On Thursday, 20 July 2017 16:07:01 UTC+2, Enio Perpetuo Junior wrote:

Thank you for your help.
I’ve not run sgadmin again after making the changes. So the configuration haven’t be applied at all.

After runing ./sgadmin_demo.sh e restarting the elastic nodes, the log messages helped me to complete the extra configs needed:

  • searchguard.cookie.password: “12345678901234567890123456789012”
  • searchguard.cookie.secure: true
    Now I’m getting another error, but because sg is not being able to connect to the ldapserver

[2017-07-20T10:47:54,337][WARN ][c.f.d.a.l.b.LDAPAuthorizationBackend] Unable to connect to ldapserver:636 due to [org.ldaptive.provider.ConnectionException@1104210828::resultCode=null, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, message=javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms., providerException=javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms.]. Try next.

[2017-07-20T10:47:54,339][WARN ][c.f.s.a.BackendRegistry ] Authentication finally failed for eperpetuo

Thanks again.

Yes, the servers are communicating. Changing the log level, I noticed that, if I use the following configuration:

config: enable_ssl: false enable_start_tls: true

Then I got the following error message:

[2017-07-21T09:40:49,946][DEBUG][c.f.d.a.l.b.LDAPAuthorizationBackend] enabled ssl/tls protocols for ldaps [TLSv1.1, TLSv1.2] [2017-07-21T09:40:49,955][DEBUG][o.l.p.j.NamingExceptionUtils] naming exception class javax.naming.NamingException is ambiguous, maps to multiple result codes: [OPERATIONS_ERROR, ALIAS_PROBLEM, ALIAS_DEREFERENCING_PROBLEM, LOOP_DETECT, AFFECTS_MULTIPLE_DSAS, OTHER] [2017-07-21T09:40:49,955][DEBUG][o.l.p.j.JndiStartTLSConnectionFactory] Error connecting to LDAP URL: ldap://ldapserver:636 org.ldaptive.provider.ConnectionException: javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms. ... Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms.

Note that it is trying to connect to ldap://ldapserver:636 instead of ldaps://ldapserver:636

So, I changed the configuration to:

config: enable_ssl: **true **<===== enable_start_tls: **true**

Then, I got a different error when trying to login. Note that now it is trying to connect to ldaps://ldapserver:636:

[2017-07-21T09:51:07,095][DEBUG][c.f.d.a.l.b.LDAPAuthorizationBackend] enabled ssl/tls protocols for ldaps [TLSv1.1, TLSv1.2] ... [2017-07-21T09:51:07,161][DEBUG][o.l.p.j.JndiStartTLSConnectionFactory] Error connecting to LDAP URL: **ldaps****://ldapserver:636** org.ldaptive.provider.ConnectionException: javax.naming.CommunicationExcetion: ldapserver:636 [Root exception isjavax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed:sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target] ... Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed:sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[?:?] ... Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target ... Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145) ~[?:?]

My elasticsearch.yml:

`######## Start Search Guard Demo Configuration ########
searchguard.ssl.transport.keystore_filepath: keystore.jks
searchguard.ssl.transport.truststore_filepath: truststore.jks
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_filepath: keystore.jks
searchguard.ssl.http.truststore_filepath: truststore.jks
searchguard.authcz.admin_dn:

  • CN=kirk,OU=client,O=client,L=test, C=de

cluster.name: searchguard_demo
network.host: 0.0.0.0
######## End Search Guard Demo Configuration ########`

To solve "PKIX path building failed:sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target" the certificate issued by the ldap server
must be trusted by the truststore configured in searchguard.ssl.transport.truststore_filepath. Either you import the ldap certificate directly into the truststore or you need a ldap certificate signed with the root certificate which resides in your truststore.
Maybe you can connect to your ldap server using port 389 and without ssl (but this is less secure and requires that ldap is configured properly)

Is your ldap server an Active Directory?

If you are using ssl (enable_ssl: true) you maybe want to set enable_start_tls: false because both makes no sense. Ask your ldap admin whats the right way here.

···

Am 21.07.2017 um 15:36 schrieb Enio Perpetuo Junior <eniojr@gmail.com>:

Thanks again.

Yes, the servers are communicating. Changing the log level, I noticed that, if I use the following configuration:

config:
   enable_ssl: false
   enable_start_tls: true

Then I got the following error message:

[2017-07-21T09:40:49,946][DEBUG][c.f.d.a.l.b.LDAPAuthorizationBackend] enabled ssl/tls protocols for ldaps [TLSv1.1, TLSv1.2]
[2017-07-21T09:40:49,955][DEBUG][o.l.p.j.NamingExceptionUtils] naming exception class javax.naming.NamingException is ambiguous, maps to multiple result codes: [OPERATIONS_ERROR, ALIAS_PROBLEM, ALIAS_DEREFERENCING_PROBLEM, LOOP_DETECT, AFFECTS_MULTIPLE_DSAS, OTHER]
[2017-07-21T09:40:49,955][DEBUG][o.l.p.j.JndiStartTLSConnectionFactory] Error connecting to LDAP URL: ldap://ldapserver:636
org.ldaptive.provider.ConnectionException: javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms.
...
Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms.

Note that it is trying to connect to ldap://ldapserver:636 instead of ldaps://ldapserver:636

So, I changed the configuration to:

config:
   enable_ssl: true <=====
   enable_start_tls: true

Then, I got a different error when trying to login. Note that now it is trying to connect to ldaps://ldapserver:636:
  
[2017-07-21T09:51:07,095][DEBUG][c.f.d.a.l.b.LDAPAuthorizationBackend] enabled ssl/tls protocols for ldaps [TLSv1.1, TLSv1.2]
...
[2017-07-21T09:51:07,161][DEBUG][o.l.p.j.JndiStartTLSConnectionFactory] Error connecting to LDAP URL: ldaps://ldapserver:636
org.ldaptive.provider.ConnectionException: javax.naming.CommunicationExcetion: ldapserver:636 [Root exception isjavax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed:sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]
...
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed:sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) ~[?:?]
...
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
...
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145) ~[?:?]

My elasticsearch.yml:

######## Start Search Guard Demo Configuration ########
searchguard.ssl.transport.keystore_filepath: keystore.jks
searchguard.ssl.transport.truststore_filepath: truststore.jks
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_filepath: keystore.jks
searchguard.ssl.http.truststore_filepath: truststore.jks
searchguard.authcz.admin_dn:
  - CN=kirk,OU=client,O=client,L=test, C=de

cluster.name: searchguard_demo
network.host: 0.0.0.0
######## End Search Guard Demo Configuration ########

--
You received this message because you are subscribed to the Google Groups "Search Guard" 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/2aec3509-005e-4b33-b587-ff92119ad363%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thanks, I imported the ldap certificate into the truststore and it solved the PKIX problem reported before.

However, a new error occured when I tried to login:

[2017-07-24T16:44:38,570][DEBUG][c.f.s.a.BackendRegistry ] Try to extract auth creds from http basic
[2017-07-24T16:44:38,570][DEBUG][c.f.s.a.BackendRegistry ] User ‘eperpetuo’ is in cache? false (cache size: 1)
[2017-07-24T16:44:38,570][DEBUG][c.f.s.a.BackendRegistry ] eperpetuo not cached, return from ldap backend directly
[2017-07-24T16:44:38,573][DEBUG][c.f.d.a.l.b.LDAPAuthorizationBackend] enabled ssl/tls protocols for ldaps [TLSv1.1, TLSv1.2]
[2017-07-24T16:44:38,574][DEBUG][c.f.d.a.l.b.LDAPAuthorizationBackend] bindDn cn=XXXXX,ou=XXXXX,ou=XXXXX,o=XXXXX,c=XXXXX, password ****
[2017-07-24T16:44:38,785][DEBUG][o.l.p.j.NamingExceptionUtils] naming exception class javax.naming.NamingException is ambiguous, maps to multiple result codes: [OPERATIONS_ERROR, ALIAS_PROBLEM, ALIAS_DEREFERENCING_PROBLEM, LOOP_DETECT, AFFECTS_MULTIPLE_DSAS, OTHER]
[2017-07-24T16:44:38,785][DEBUG][o.l.p.j.JndiStartTLSConnectionFactory] Error connecting to LDAP URL: ldaps://ldapserver:636
org.ldaptive.provider.ConnectionException: javax.naming.NamingException: [LDAP: error code 1 - 00000000: LdapErr: DSID-0C090DE6, comment: TLS or SSL already in effect, data 0, v1771]; remaining name ‘’

``

I’m pretty sure the error message is related to this configuration:

config:
enable_ssl: true <====
enable_start_tls: true <====
enable_ssl_client_auth: true
verify_hostnames: false
hosts:
- ldapserver:636

``

But the problem is:

  • If I disable enable_ssl, then I get the error:

[2017-07-21T09:40:49,955][DEBUG][o.l.p.j.JndiStartTLSConnectionFactory] Error connecting to LDAP URL: ldap://ldapserver:636
org.ldaptive.provider.ConnectionException: javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms.

``

  • If I disable enable_start_tls, then I get:

[2017-07-24T16:56:23,862][DEBUG][o.l.p.j.JndiConnectionFactory] Error connecting to LDAP URL: ldaps://ldapserver:636
org.ldaptive.provider.ConnectionException: javax.naming.CommunicationException: ldapserver:636 [Root exception is javax.net.ssl.SSLHandshakeException: Server chose TLSv1, but that protocol version is not enabled or not supported by the client.]
at org.ldaptive.provider.jndi.JndiConnectionFactory.createInternal(JndiConnectionFactory.java:88) ~[dlic-search-guard-authbackend-ldap-5.0-7-jar-with-dependencies.jar:?]

``

In summary:

  • enable_ssl: true <==== avoids naming exception
  • enable_start_tls: true <==== avoids ssl handshake exception

But they don’t work together.

My ldap server is an AD LDS and it does not allow me to connect on port 389.

Hi,

it seems that your LDAP / AD server only supports TLSv1, which is outdated and deemed insecure. By default, Search Guard requires TLSv1.1 and above. You can either upgrade your LDAP / AD server to use TLSv.1.1 (or above) for better security, or you can force Search Guard to accept TLSv1.

See also this issue here:

https://github.com/floragunncom/search-guard/issues/227

To enable TLSv1, add the “enabled protocols” config key to your LDAP configuration like:

config:

enabled_ssl_protocols:

- "TLSv1"

- "TLSv1.1"

- "TLSv1.2"
···

On Monday, July 24, 2017 at 10:17:15 PM UTC+2, Enio Perpetuo Junior wrote:

Thanks, I imported the ldap certificate into the truststore and it solved the PKIX problem reported before.

However, a new error occured when I tried to login:

[2017-07-24T16:44:38,570][DEBUG][c.f.s.a.BackendRegistry ] Try to extract auth creds from http basic
[2017-07-24T16:44:38,570][DEBUG][c.f.s.a.BackendRegistry ] User ‘eperpetuo’ is in cache? false (cache size: 1)
[2017-07-24T16:44:38,570][DEBUG][c.f.s.a.BackendRegistry ] eperpetuo not cached, return from ldap backend directly
[2017-07-24T16:44:38,573][DEBUG][c.f.d.a.l.b.LDAPAuthorizationBackend] enabled ssl/tls protocols for ldaps [TLSv1.1, TLSv1.2]
[2017-07-24T16:44:38,574][DEBUG][c.f.d.a.l.b.LDAPAuthorizationBackend] bindDn cn=XXXXX,ou=XXXXX,ou=XXXXX,o=XXXXX,c=XXXXX, password ****
[2017-07-24T16:44:38,785][DEBUG][o.l.p.j.NamingExceptionUtils] naming exception class javax.naming.NamingException is ambiguous, maps to multiple result codes: [OPERATIONS_ERROR, ALIAS_PROBLEM, ALIAS_DEREFERENCING_PROBLEM, LOOP_DETECT, AFFECTS_MULTIPLE_DSAS, OTHER]
[2017-07-24T16:44:38,785][DEBUG][o.l.p.j.JndiStartTLSConnectionFactory] Error connecting to LDAP URL: ldaps://ldapserver:636
org.ldaptive.provider.ConnectionException: javax.naming.NamingException: [LDAP: error code 1 - 00000000: LdapErr: DSID-0C090DE6, comment: TLS or SSL already in effect, data 0, v1771]; remaining name ‘’

``

I’m pretty sure the error message is related to this configuration:

config:
enable_ssl: true <====
enable_start_tls: true <====
enable_ssl_client_auth: true
verify_hostnames: false
hosts:
- ldapserver:636

``

But the problem is:

  • If I disable enable_ssl, then I get the error:

[2017-07-21T09:40:49,955][DEBUG][o.l.p.j.JndiStartTLSConnectionFactory] Error connecting to LDAP URL: ldap://ldapserver:636
org.ldaptive.provider.ConnectionException: javax.naming.NamingException: LDAP response read timed out, timeout used:-1ms.

``

  • If I disable enable_start_tls, then I get:

[2017-07-24T16:56:23,862][DEBUG][o.l.p.j.JndiConnectionFactory] Error connecting to LDAP URL: ldaps://ldapserver:636
org.ldaptive.provider.ConnectionException: javax.naming.CommunicationException: ldapserver:636 [Root exception is javax.net.ssl.SSLHandshakeException: Server chose TLSv1, but that protocol version is not enabled or not supported by the client.]
at org.ldaptive.provider.jndi.JndiConnectionFactory.createInternal(JndiConnectionFactory.java:88) ~[dlic-search-guard-authbackend-ldap-5.0-7-jar-with-dependencies.jar:?]

``

In summary:

  • enable_ssl: true <==== avoids naming exception
  • enable_start_tls: true <==== avoids ssl handshake exception

But they don’t work together.

My ldap server is an AD LDS and it does not allow me to connect on port 389.

Excelent! That worked just fine. The user is being validated.

However, after login, the user is not redirected to the Kibana page. The login page is reloaded instead.

The same occours even if I log in with admin internal user.

My configs:

https://localhost:9200/_searchguard/authinfo returns:

{"user":"User [name=admin, roles=[]]","user_name":"admin","user_requested_tenant":null,"remote_address":"[::1]:56885","sg_roles":["sg_all_access","sg_own_index","sg_public"],"sg_tenants":{"test_tenant_ro":true,"admin":true,"adm_tenant":true},"principal":null,"peer_certificates":"0"}

In kibana.yml

# The URL of the Elasticsearch instance to use for all your queries.
elasticsearch.url: "https://localhost:9200"

elasticsearch.ssl.verificationMode: none
elasticsearch.username: "kibanaserver"
elasticsearch.password: "kibanaserver"

searchguard.cookie.password: "XXXXXX"
searchguard.cookie.secure: true

``

elasticsearch.yml:

######## Start Search Guard Demo Configuration ########
searchguard.ssl.transport.keystore_filepath: keystore.jks
searchguard.ssl.transport.truststore_filepath: truststore.jks
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_filepath: keystore.jks
searchguard.ssl.http.truststore_filepath: truststore.jks
searchguard.authcz.admin_dn:
  - CN=kirk,OU=client,O=client,L=test, C=de

cluster.name: searchguard_demo
######## End Search Guard Demo Configuration ########

``

sg_config.yml

searchguard:
  dynamic:
    kibana:
      # Kibana multitenancy - NOT FREE FOR COMMERCIAL USE
      # see https://github.com/floragunncom/search-guard-docs/blob/master/multitenancy.md
      # To make this work you need to install https://github.com/floragunncom/search-guard-module-kibana-multitenancy/wiki
      #multitenancy_enabled: true
      #server_username: kibanaserver
      #index: '.kibana'
      #do_not_fail_on_forbidden: false
    http:
      anonymous_auth_enabled: false
      xff:
        enabled: false
        internalProxies: '192\.168\.0\.10|192\.168\.0\.11' # regex pattern
        #internalProxies: '.*' # trust all internal proxies, regex pattern
        remoteIpHeader:  'x-forwarded-for'
        proxiesHeader:   'x-forwarded-by'
        #trustedProxies: '.*' # trust all external proxies, regex pattern
        ###### see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
        ###### more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
        ###### and here https://tools.ietf.org/html/rfc7239
        ###### and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve
    authc:
      kibana_auth_domain:
        enabled: true
        order: 0
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      basic_internal_auth_domain:
        enabled: true
        order: 1
        http_authenticator:
          type: basic
          challenge: true
        authentication_backend:
          type: intern
      ldap:
        enabled: true
        order: 2
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: ldap
          config:
            enable_ssl: true
            enable_start_tls: false
            enable_ssl_client_auth: true
            verify_hostnames: false
            hosts:
              - XXXXXX:636
            bind_dn: cn=XXXXXX,ou=XXXXXX,ou=XXXXXX,o=XXXXXX,c=XXXXXX
            password: XXXXXX
            userbase: 'o=XXXXXX,c=XXXXXX'
            usersearch: '(cn={0})'
            username_attribute: cn
            enabled_ssl_protocols:
              - "TLSv1"
              - "TLSv1.1"
              - "TLSv1.2"

``

I only added my user (registered in LDAP) to the sg_roles_mapping.yml

sg_all_access:
  users:
    - admin
    - eperpetuo

``

Just a very quick guess:

You have set:

searchguard.cookie.secure: true

If you set this to true, then cookies are only accepted when you access Kibana via https. If you have not configured SSL for Kibana, means you access Kibana via http, then HTTP cookies are not accepted. In this case, authentication succeeds, but the session cookie can’t be stored.

If this is the case, simply set

searchguard.cookie.secure: false

Please let me know if this is the cause of the issue.

···

On Tuesday, July 25, 2017 at 4:31:31 PM UTC+2, Enio Perpetuo Junior wrote:

Excelent! That worked just fine. The user is being validated.

However, after login, the user is not redirected to the Kibana page. The login page is reloaded instead.

The same occours even if I log in with admin internal user.

My configs:

https://localhost:9200/_searchguard/authinfo returns:

{"user":"User [name=admin, roles=[]]","user_name":"admin","user_requested_tenant":null,"remote_address":"[::1]:56885","sg_roles":["sg_all_access","sg_own_index","sg_public"],"sg_tenants":{"test_tenant_ro":true,"admin":true,"adm_tenant":true},"principal":null,"peer_certificates":"0"}

In kibana.yml

The URL of the Elasticsearch instance to use for all your queries.

elasticsearch.url: “https://localhost:9200

elasticsearch.ssl.verificationMode: none
elasticsearch.username: “kibanaserver”
elasticsearch.password: “kibanaserver”

searchguard.cookie.password: “XXXXXX”
searchguard.cookie.secure: true

``

elasticsearch.yml:

######## Start Search Guard Demo Configuration ########
searchguard.ssl.transport.keystore_filepath: keystore.jks
searchguard.ssl.transport.truststore_filepath: truststore.jks
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_filepath: keystore.jks
searchguard.ssl.http.truststore_filepath: truststore.jks
searchguard.authcz.admin_dn:

  • CN=kirk,OU=client,O=client,L=test, C=de

cluster.name: searchguard_demo
######## End Search Guard Demo Configuration ########

``

sg_config.yml

searchguard:
dynamic:
kibana:
# Kibana multitenancy - NOT FREE FOR COMMERCIAL USE
# see https://github.com/floragunncom/search-guard-docs/blob/master/multitenancy.md
# To make this work you need to install https://github.com/floragunncom/search-guard-module-kibana-multitenancy/wiki
#multitenancy_enabled: true
#server_username: kibanaserver
#index: ‘.kibana’
#do_not_fail_on_forbidden: false
http:
anonymous_auth_enabled: false
xff:
enabled: false
internalProxies: ‘192.168.0.10|192.168.0.11’ # regex pattern
#internalProxies: ‘.’ # trust all internal proxies, regex pattern
remoteIpHeader: ‘x-forwarded-for’
proxiesHeader: ‘x-forwarded-by’
#trustedProxies: '.
’ # trust all external proxies, regex pattern
###### see https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html for regex help
###### more information about XFF https://en.wikipedia.org/wiki/X-Forwarded-For
###### and here https://tools.ietf.org/html/rfc7239
###### and https://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Remote_IP_Valve
authc:
kibana_auth_domain:
enabled: true
order: 0
http_authenticator:
type: basic
challenge: true
authentication_backend:
type: intern
basic_internal_auth_domain:
enabled: true
order: 1
http_authenticator:
type: basic
challenge: true
authentication_backend:
type: intern
ldap:
enabled: true
order: 2
http_authenticator:
type: basic
challenge: false
authentication_backend:
type: ldap
config:
enable_ssl: true
enable_start_tls: false
enable_ssl_client_auth: true
verify_hostnames: false
hosts:
- XXXXXX:636
bind_dn: cn=XXXXXX,ou=XXXXXX,ou=XXXXXX,o=XXXXXX,c=XXXXXX
password: XXXXXX
userbase: ‘o=XXXXXX,c=XXXXXX’
usersearch: ‘(cn={0})’
username_attribute: cn
enabled_ssl_protocols:
- “TLSv1”
- “TLSv1.1”
- “TLSv1.2”

``

I only added my user (registered in LDAP) to the sg_roles_mapping.yml

sg_all_access:
users:
- admin
- eperpetuo

``

Super!!!

Thanks a lot for your support.