Can't Activate LDAP Module 5.0-7

[Enio Perpetuo Junior]

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:

            - <hostname>:636

          bind_dn: cn=<usermane>,ou=ServiceAccounts,ou=people,o=<companyname>,c=<country>

          password: <password>

          userbase: 'ou=people,o=<companyname>,c=<country>'

          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 ...

[Jochen Kressin]

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.    

[Enio Perpetuo Junior]

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

[Search Guard]

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.

[Enio Perpetuo Junior]

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 ########

[SG]

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.

> --
> 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...@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/2aec3509-005e-4b33-b587-ff92119ad363%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Enio Perpetuo Junior]

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.

[Jochen Kressin]

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"

[Enio Perpetuo Junior]

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

[Jochen Kressin]

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.

[Enio Perpetuo Junior]

Super!!!!

Thanks a lot for your support.