Kibana will let any credentials pass

378 views
Skip to first unread message

Sean I

unread,
Jun 8, 2017, 4:40:40 PM6/8/17
to Search Guard

I am setting up search guard. Ibhave it working, however at the login page you can put in any username and password and it will let you in. Below are my elasticsearch.yml and the kibana.yml. not quite aute what i am doing wrong. The enceution aeema to bw working fine.

Elasticsearch.yml
cluster.name: mycoolclustername
node.name: myserver.mydomain
network.host: localhost
index.codec: best_compression
searchguard.ssl.transport.enabled: true
searchguard.ssl.transport.keystore_type: JKS
searchguard.ssl.transport.keystore_filepath: myserver.mydomain
searchguard.ssl.transport.keystore_password: password
searchguard.ssl.transport.truststore_type: JKS
searchguard.ssl.transport.truststore_filepath: truststore.jks
searchguard.ssl.transport.truststore_password: password
searchguard.ssl.transport.enforce_hostname_verification: false
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_type: JKS
searchguard.ssl.http.keystore_filepath: myserver.mydomain
searchguard.ssl.http.keystore_password: password
searchguard.ssl.http.truststore_type: JKS
searchguard.ssl.http.truststore_filepath: truststore.jks
searchguard.ssl.http.truststore_password: password

Kibana.yml
server.host: "xxx.xxx.xxx.xxx"
server.name: "myserver.mydomain"
elasticsearch.url: "https://localhost:9200"
elasticsearch.username: kibanaserver
elasticsearch.password: kibanaserver
server.ssl.certificate: /etc/pki/tls/certs/localhost.crt
server.ssl.key: /etc/pki/tls/private/kibana.key
elasticsearch.ssl.certificate: /etc/pki/tls/certs/localhost.crt
elasticsearch.ssl.key: /etc/pki/tls/private/kibana.key
elasticsearch.ssl.verificationMode: none
searchguard.basicauth.enabled: true
searchguard.cookie.secure: true
searchguard.cookie.name: searchguard_authentication
searchguard.cookie.password: 32characterstring
searchguard.session.keepalive: true

Thanks
Sean

Sean I

unread,
Jun 8, 2017, 4:49:01 PM6/8/17
to Search Guard
Sorry meant to say

Not quite sure what I am doing wrong. The encryption seems to be working fine.

I was trying to type on my phone.

Jochen Kressin

unread,
Jun 10, 2017, 12:11:11 PM6/10/17
to Search Guard
Please also post your sg_config.yml here.

Sean I

unread,
Jun 12, 2017, 9:26:16 AM6/12/17
to Search Guard
I probably overlooked something, but here it is.

thanks,
Sean

# This is the main configuration file where the authentication and authorization
# backends as well as the http authenticators and other settings will be defined.
#
# The authentication works like that:
#
# If there are no authenticators (authc) defined a implicit one will be created.
# This will authenticate against the internal user database and use HTTP Basic.
#
# If more than one is configured the first one which succeeds wins. If all fail then the request will be unauthenticated
# and a respective exception is thrown and/or the HTTP status is set to 401.
#
# After authentication authorization (authz) will be applied. There can be zero or more authorizers which collect
# the roles from a given backend for the authenticated user.
#
# For HTTP is possible to allow anonymous authentication. If that is allowed then the http authenticators try to
# find user credentials in the HTTP request and if such where found then the user gets regularly authenticated.
# If none can be found the user will be authenticated as an "anonymous" user. This user has always the username "sg_anonymous"
# and one role named "sg_anonymous_backendrole". If you enable anonymous authentication for all http authenticators will not challenge.
#
#
# Notice: If you define more than one authenticator make sure to put non-challenging authenticators like "proxy" or "clientcert"
# at the beginning and the challenging one at the end. If you configure more than one challenging authenticator you have to deal with
# the "challenge" flag. Because its not possible to challenge a client with two different authentication methods (for example
# Kerberos and Basic) only one can have challenge: true. All others need to have challenge: false and that means
# they look into the request and if they found no credentials they will not challenge. You can cope with this situation
# with pre-authentication. That is submitting credentials for non-challenging authenticators within the first request
# (Thats especially easy for Basic authentication).
# Default value of the challenge flag is true.
#
#
#
# HTTP
#   basic (challenging)
#   proxy (not challenging, needs xff)
#   kerberos (challenging) NOT FREE FOR COMMERCIAL
#   clientcert (not challenging, needs https)
#   jwt (not challenging) NOT FREE FOR COMMERCIAL
#   host (not challenging) #DEPRECATED, will be removed in a future version.
#                           host based authentication is configurable in sg_roles_mapping,
#                           so no need for a "host http authenticator"

# Authc
#   internal
#   noop
#   ldap  NOT FREE FOR COMMERCIAL USE

# Authz
#   ldap  NOT FREE FOR COMMERCIAL USE
#   noop

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: true
        order: 1
        http_authenticator:
          type: basic
          challenge: true
        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: 4
        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: false
        order: 5
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          # LDAP authentication backend (authenticate users against a LDAP or Active Directory)
          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
            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: '(sAMAccountName={0})'
            # Use this attribute from the user as username (if not set then DN is used)
            username_attribute: null
    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

unread,
Jun 17, 2017, 5:36:07 AM6/17/17
to Search Guard
So what happens when you access ES directly, without Kibana? 

Also, can you try to add this to your elasticsearch.yml and try again with Kibana?

searchguard.ssl.http.clientauth_mode: NONE

bah djibril djibril

unread,
Jul 24, 2017, 11:15:38 PM7/24/17
to Search Guard
I am facing the same issue. When I add "searchguard.ssl.http.clientauth_mode: NONE" the authentication works but the cluster state is now red.

Jochen Kressin

unread,
Jul 25, 2017, 3:45:34 AM7/25/17
to Search Guard
Please check these entries:

elasticsearch.ssl.certificate: /etc/pki/tls/certs/localhost.crt
elasticsearch.ssl.key: /etc/pki/tls/private/kibana.key

The certificate used here are added to the calls from KI to ES. You usually use this feature to authenticate calls from the internal Kibana service user. The certificate has to be a simple client certificate, especially it

* must not be a node certificate
* must not be an admin certificate

The order of the authenticators also plays a role when you use SSO like JWT or Kerberos. Please post your sg_config.yml and kibana.yml if the error perists.

Jasmine Hegman

unread,
Dec 13, 2017, 8:16:45 PM12/13/17
to Search Guard Community Forum
I am also facing this issue. It seems to be impossible to use clientauth with anything but NONE here, but TLS over REST cannot accept NONE as a value. I will investigate running kibana without any TLS to see if I can force basic auth to be used.

Jasmine Hegman

unread,
Dec 13, 2017, 8:25:59 PM12/13/17
to Search Guard Community Forum
Just wanted to report back that sadly removing SSL configs from kibana totally fixed the issue. I am able to leave clientauth as OPTIONAL allowing both methods of access.

# Optional settings that provide the paths to the PEM-format SSL certificate and key files.
# These files validate that your Elasticsearch backend uses the same key files.
#elasticsearch.ssl.certificate: /tls/kibana.crt
#elasticsearch.ssl.key: /tls/kibana.key

Note that elasticsearch.username and elasticsearch.password are still provided to kibana, just not elasticsearch.ssl.certificate and elasticsearch.ssl.key anymore in my configs.

Hope this helps others!
Reply all
Reply to author
Forward
0 new messages