Shield accepts any username/password combination

Elastic Stack Elasticsearch
21

Why does the message say it can't authenticate the user to the domain? I thought the user does not need to exist on the domain (kibana4-server)? If not, that is a very misleading error message and I think Elastic should revisit how they're logging that.

22

Realms are defined in a chain, so each realm that supports a type of token will be called in order until one has successful authentication or the chain ends.

Can you share your full configuration? I am not sure but maybe docker plays an issue here. What image are you using?

23

ES config ::

cluster.name: TrainingProd
node.name: "Training1 - Wolverine"

path.conf: /data/elk-conf
path.data: /data/elasticsearch_data
path.logs: /data/elasticsearch_data/elastic_logs

bootstrap.mlockall: true

network.bind_host: 0.0.0.0
network.publish_host: 10.183.216.30
transport.tcp.port: 9300
http.port: 9200

gateway.recover_after_nodes: 3
gateway.recover_after_time: 5m
gateway.expected_nodes: 4

discovery.zen.minimum_master_nodes: 3
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["10.183.216.30", "10.183.216.31", "10.183.216.32"]

cloud:
azure:
storage:
account: "account"
key: "key"

node.box_type: hot

shield.authc.realms:
esusers:
type: esusers
order: 0
active_directory:
type: active_directory
order: 1
domain_name: mydomain.com
unmapped_groups_as_roles: true
url: ldap://dc01.mydomain.com

Kibana config ::

port: 5601
host: "0.0.0.0"

elasticsearch_url: "http://10.183.216.30:9200"
elasticsearch_preserve_host: true

elasticsearch.username: "kibana4-server"
elasticsearch.password: "kibanaserverpw"

server.ssl.key: /data/elk-conf/nginx-kibana.key
server.ssl.cert: /data/elk-conf/nginx-kibana.crt

shield.encryptionKey: "encryptionkeyhere"

kibana_index: ".kibana"

default_app_id: "discover"

request_timeout: 600000

shard_timeout: 0

verify_ssl: true

bundled_plugin_ids:

  • plugins/dashboard/index
  • plugins/discover/index
  • plugins/doc/index
  • plugins/kibana/index
  • plugins/markdown_vis/index
  • plugins/metric_vis/index
  • plugins/settings/index
  • plugins/table_vis/index
  • plugins/vis_types/index
  • plugins/visualize/index

NGINX Reverse Proxy Config ::

server {
listen 80;
return 301 https://$host$request_uri;
}

server {
listen 443;
ssl_certificate /data/elk-conf/nginx-kibana.crt;
ssl_certificate_key /data/elk-conf/nginx-kibana.key;
ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
access_log /data/nginx/log/access_nginx-kibana.conf.log;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 600s;
proxy_read_timeout 600s;
proxy_send_timeout 600s;
proxy_next_upstream_timeout 600s;
# Fix the ???It appears that your reverse proxy set up is broken" error.
proxy_pass https://10.183.216.30:5601;
}
}

/etc/elasticsearch/shield/role_mapping.yml ::

power_user:

  • "cn=TheGroup,OU=TheOU,OU=Security Groups,OU=AnotherOU,DC=mydomain,DC=com"
24

ES 2.2
Kibana 4.4
CentOS 7.1

25

This is what is causing the esusers realm to fail. If you have a /etc/sysconfig/elasticsearch file, then it most likely defines the CONF_DIR as /etc/elasticsearch so this is what the esusers CLI tool thinks is the configuration directory but your elasticsearch instance is actually using /data/elk-conf. At runtime Shield does not find the users or users_roles files.

To fix this:

  1. Copy/move the directory /etc/elasticsearch/shield to /data/elk-conf/shield. This should result in file paths like /data/elk-conf/shield/users and /data/elk-conf/shield/roles.yml
  2. Update the /etc/sysconfig/elasticsearch file to point to the proper CONF_DIR. Alternatively, you can always pass the option -Des.path.conf=/data/elk-conf when using the esusers tool. For example:
    bin/shield/esusers useradd michael -r admin -Des.path.conf=/data/elk-conf
26

I tried that, but this happened ::

ERROR: Unrecognized option: -Des.path.conf=/data/elk-conf

Also, inside of the elasticsearch container, I do not have an /etc/sysconfig, on the host VM I do, but there is no elasticsearch file

27

My apologies, that option was for a different tool. Just verified that this works:

bin/shield/esusers useradd michael -r admin --path.conf=/data/elk-conf

Before using this command make sure /data/elk-conf/shield exists and is writeable by the user who is running the esusers command.

28

I was able to get in after I copied the folder...I suppose this --path.conf flag will need to be added for any esusers created, since the folder needed to be copied. Well, I guess it wouldn't be a big deal now since we can authenticate via AD.

Hooray to being able to get to logs using my AD account!

29

When you generate a self-signed certificate, and configure it via the following way ::

shield.ssl.keystore.path: /etc/elasticsearch/self-signed.jks
shield.ssl.keystore.password: $password
shield.ssl.hostname_verification: false
shield.transport.ssl: true
shield.http.ssl: true

Is this encrypting the initial authentication of the esuser before Active Directory authentication is attempted? So to have total encryption we would need to do this + configure encryption for Active Directory?