Shield Authentication Error

security

(piyush) #1

Hi,
I am using esuser realm and getting auth error, i guess it's not taking esuser as basic realm. Can you suggest what should i try?

Create User:
/shield/esusers useradd --admin roles admin

Error:
{"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [admin] for REST request [/]","header":{"WWW-Authenticate":"Basic realm="shield""}}],"type":"security_exception","reason":"unable to authenticate user [admin] for REST request [/]","header":{"WWW-Authenticate":"Basic realm="shield""}},"status":401}

Configuration:

shield:
authc:
realms:
esusers1:
type: esusers
order: 0

Regards...


(Jay Modi) #2

The command is wrong. Where did you find that? Try:

/bin/shield/esusers useradd admin -r admin

(piyush) #3

UPsss, Friday effect may be. I did esusers list and typed the command myself. Didn't check for options. I recreated the user, it's working now.
Apologies for that, should have checked the documentation first.


(David F.) #4

Great!!!


(Nicolas Seyvet) #5

Hi,

See https://github.com/docker-library/elasticsearch/issues/79. I seem to be having the same problem, ie the config dir is not /etc/elasticsearch, Is this a shield bug?

If the /etc/elasticsearch/shield content is moved to /usr/share/elasticsearch/config/shield then I get:

./esusers admin -r admin[2016-03-30 14:09:35,740][DEBUG][indices.memory ] [datastorage] recalculating shard indexing buffer, total is [98.9mb] with [2] active shards, each shard set to indexing=[49.4mb], translog=[64kb]

ERROR: The configuration directory [/etc/elasticsearch/shield] does not exist. The esusers tool expects Shield configuration files in that location.
The plugin may not have been installed with the correct configuration path. If [/usr/share/elasticsearch/config/shield] exists, please copy the shield directory to [/etc/elasticsearch]

In any case, either it is in one /etc/elasticsearch or /usr/share/elasticsearch I can not login


(Nicolas Seyvet) #6

The exact same steps work fine with exact same version of ES/shield when running locally ie not within the container. Then I can authenticate.

But not when it is built via a Dockerfile and ran within the container.

I must be doing something wrong... Does adding a user changes some files (access issues on FS)?


(Nicolas Seyvet) #7

Does shield filter on the IP? Within the container it starts as 172.17.0.2. The external IP is different obviously. could that prevent authentication?


(Nicolas Seyvet) #8

Still facing issue...

User is successfully created, /etc/elasticsearch/shield/users is modified:
cat /etc/elasticsearch/shield/users
lmcnise:$2a$10$OhPJkrrlu4RlV4F7/sAUOeFRxEIEcjRUbDoS/C31Y7ITeWZ.74K52

But:

[2016-03-31 12:05:22,862][DEBUG][shield.authc.esnative ] [datastorage] user not found in cache, proceeding with normal authentication
[2016-03-31 12:05:22,868][DEBUG][shield.authc.esusers ] [datastorage] user not found in cache, proceeding with normal authentication
[2016-03-31 12:05:22,878][DEBUG][rest.suppressed ] / Params: {}
ElasticsearchSecurityException[unable to authenticate user [lmcnise] for REST request [/]]
at org.elasticsearch.shield.support.Exceptions.authenticationError(Exceptions.java:39)
at org.elasticsearch.shield.authc.DefaultAuthenticationFailureHandler.unsuccessfulAuthentication(DefaultAuthenticationFailureHandler.java:35)
at org.elasticsearch.shield.authc.InternalAuthenticationService.authenticate(InternalAuthenticationService.java:119)
at org.elasticsearch.shield.rest.ShieldRestFilter.process(ShieldRestFilter.java:73)
at org.elasticsearch.rest.RestController$ControllerFilterChain.continueProcessing(RestController.java:263)
at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:176)
at org.elasticsearch.http.HttpServer.internalDispatchRequest(HttpServer.java:128)
at org.elasticsearch.http.HttpServer$Dispatcher.dispatchRequest(HttpServer.java:86)
at org.elasticsearch.http.netty.NettyHttpServerTransport.dispatchRequest(NettyHttpServerTransport.java:449)

Can not login.

Any ideas?


Shield not respecting CONF_DIR
(Nicolas Seyvet) #9

There is something fishy about shield and its setup. I can reproduce the problem in a VM using vagrant.

The config directory for shield message is IMO a bug.

For example, with user vagrant:

"[vagrant@node-01 shield]$ ./esusers list
ERROR: The configuration directory [/etc/elasticsearch/shield] does not exist. The esusers tool expects Shield configuration files in that location.
The plugin may not have been installed with the correct configuration path. If [/usr/share/elasticsearch/config/shield] exists, please copy the shield directory to [/etc/elasticsearch]

The same operation works fine with user root:

[root@node-01 shield]# ./esusers list
elastic : admin
lmcnise : admin

And in short, despite having two users, I can not login.

Here are the options passed to ES:

/usr/share/elasticsearch/bin/elasticsearch -Dnetwork.host=0.0.0.0 -Dcluster.name=lmcnise -Dzen.minimum_master_nodes=1 -Dmarvel.agent.enabled=true

And the elasticsearch.yml file:

#cluster:

name: dcp-rta

discovery:
zen:
#minimum_master_nodes: 2
# For local test set quorum to 1
#minimum_master_nodes: 1
ping:
multicast:
enabled: false
timeout: 10
index:
number_of_replicas: 1
number_of_shards: 1
refresh_interval: 15s
indices.fielddata.cache:
expire: 6h
node:
data: true
master: true
name: datastorage
path:
data:
- /usr/share/elasticsearch/data/datastorage
persistent:

SSDs

indices.store.throttle.max_bytes_per_sec: 50mb
script:
inline: on
indexed: on

Please help.


(Nicolas Seyvet) #10

Adding -Des.default.path.conf=/etc/elasticsearch, then:

/usr/share/elasticsearch/bin/elasticsearch -Dnetwork.host=0.0.0.0 -Dcluster.name=lmcnise -Dzen.minimum_master_nodes=1 -Dmarvel.agent.enabled=true -Des.default.path.conf=/etc/elasticsearch

And I can authenticate.

So basically, shield expects the elasticsearch config to be in the same location as where the plugin installs it which defaults to /etc/elasticsearch on linux. I dont think there is a way to tell "plugin" where to install itself or is there?

We can use /etc/elasticsearch as our installation config dir but there is a dependency there that is real bad.


(Jay Modi) #11

Hi Nicolas,

We do try to figure out the correct configuration directory in the esusers tool. It seems as though there may be some issues with the logic there.

For the docker instance, does /etc/sysconfig/elasticsearch exist? If so this is why shield is trying to write into /etc/elasticsearch since the default install for a RPM puts the sysconfig file there and that is the default config directory for a RPM installation of elasticsearch.

In your vagrant instance, how did you install elasticsearch?

-Jay


(Nicolas Seyvet) #12

I used the exact same approach as in the Dockerfile i.e. the yum repo solution. The main reason of trying with vagrant was a fear that the problem might be network related (binding restricted to a specific IP/interface).


(system) #13