Authentication finally failed

Security
1

Versions (relevant - OpenSearch/Dashboard/Server OS/Browser):
2.11.0.0

Describe the issue:
curl -k -u admin:admin https://localhost:9200/_opendistro/_security/authinfo?pretty working as intended but if I try to get the results in a browser (firefox/chrome) it gives me a message Authentication is finally failed.

Tried:
https://localhost:9200/_opendistro/_security/authinfo?pretty
https://admin:admin@localhost:9200/_opendistro/_security/authinfo?pretty

It’s for the master/data nodes, not for dashboards.

Any suggestions?

2

Hi @bhornyak

Would it be accurate to say that you are interested in connecting additional nodes to your cluster? Please correct me if I’m mistaken.

3

@Eugene7, no. I already have a couple of nodes running. I want to provide health status to certain users without curl/dashboard access an maybe some selenium automation.

4

Hi @bhornyak,

The provided link does not work with OpenSearch 2.11: https://localhost:9200/_opendistro/_security/authinfo?pretty

Please use the following link instead:
https://localhost:9200/_plugins/_security/authinfo?pretty

5

Hello @Eugene7,

nope, it’s not that… both of them should be working and both of them are working with curl or GET.

So I got the expected results for
GET /_opendistro/_security/authinfo?pretty
GET /_plugins/_security/authinfo?pretty

I got the expected result for
curl -k -u admin:admin https://localhost:9200/_opendistro/_security/authinfo?pretty
curl -k -u admin:admin https://localhost:9200/_plugins/_security/authinfo?pretty

But if I try to hit them via the browser, it’s “Authentication finally failed”.

I can use any query, it doesn’t matter.

6

Hi @bhornyak

Where is the browser located? Does you run OpenSearch locally? Did you try using FQDN instead of localhost ?

7

@Eugene7
browser location is the same location where I run the curl command (my local machine)
no, I run it in a kubernetes cluster behind a vpn and I port forward it locally
FQDN: hmm… I don’t really know how to portforward fqdn if it’s even possible :wink: But localhost should work.

8

I’m getting this in the auditlog after a failed try. Nothing for a successful curl command. (Maybe another index?)

I’m getting the same if I try with a wrong password with curl.

{
  "_index": "security-auditlog-2024.01.15",
  "_id": "meTNDY0BSYxssjVft4Ti",
  "_version": 1,
  "_score": null,
  "_source": {
    "audit_cluster_name": "logging-opensearch",
    "audit_rest_request_params": {
      "pretty": ""
    },
    "audit_node_name": "logging-opensearch-master-2",
    "audit_rest_request_method": "GET",
    "audit_category": "FAILED_LOGIN",
    "audit_request_origin": "REST",
    "audit_node_id": "_Ip_ceueRZu1LtSjFBUuHA",
    "audit_request_layer": "REST",
    "audit_rest_request_path": "/_plugins/_security/authinfo",
    "@timestamp": "2024-01-15T15:46:42.273+00:00",
    "audit_request_effective_user_is_admin": false,
    "audit_format_version": 4,
    "audit_request_remote_address": "127.0.0.1",
    "audit_node_host_address": "100.64.2.147",
    "audit_rest_request_headers": {
      "Cookie": [
        "security_authentication=****"
      ],
      "Accept": [
        "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8"
      ],
      "Connection": [
        "keep-alive"
      ],
      "User-Agent": [
        "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0"
      ],
      "Sec-Fetch-Dest": [
        "document"
      ],
      "Sec-Fetch-Site": [
        "none"
      ],
      "Host": [
        "localhost:9203"
      ],
      "Accept-Encoding": [
        "gzip, deflate, br"
      ],
      "Sec-Fetch-Mode": [
        "navigate"
      ],
      "Upgrade-Insecure-Requests": [
        "1"
      ],
      "Sec-Fetch-User": [
        "?1"
      ],
      "Accept-Language": [
        "en-US,en;q=0.5"
      ]
    },
    "audit_node_host_name": "100.64.2.147"
  },
  "fields": {
    "@timestamp": [
      "2024-01-15T15:46:42.273Z"
    ]
  },
  "sort": [
    1705333602273
  ]
}
9

@bhornyak Did you execute the curl command inside the pod?
Do you use loadbalancer or NodePort with OpenSearch service?

Could you share the output of the below?

kubectl get svc

How exactly did you deploy the Kubernetes cluster and OpenSearch? Did you use some kind of virtual box? What is the OS on your machine?

10

Hi @pablo

So, opensearch is installed on a remote locataion behind a vpn tunnel.
The curl command was executed on my local machine (pod was portforwarded to localhost) and the http request was also executed on my local machine.
I’m using loadbalancer, yes, but I’m trying to address only the port forwarded pod. That won’t be the issue as I can reach the dashboard if I port forward it, or if I’m using the load balanced ip. And I just want to address a specific node, not load balance between them.
Opensearch was deployed via a helm chart, and my OS is Ubuntu 20.04 LTS but it shouldn’t matter.
The browser is
“User-Agent”: [
“Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0”
]

The issue is that if I pass the credentials via a browser (FF/Chrome were tested) that somehow fails… I suspect the payload is somehow different what opensearch is expecting.

11

I just found this:

Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:

“https://username:password@www.example.com/”

The use of these URLs is deprecated. In Chrome, the username:password@ part in URLs is removed from subresource URLs for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt “You are about to log in to the site www.example.com with the username username, but the website does not require authentication. This may be an attempt to trick you.” In case the site does require authentication, Firefox will still ask for user confirmation “You are about to log in to the site www.example.com with the username username.” before sending the credentials to the site. Note that Firefox sends the request without credentials in both cases before showing the prompt in order to determine whether the site requires

So the question reduced to how to send credentials with a browser or how to force opensearch to give me a login prompt (like elk does)

12

@bhornyak This might be related to the Kubernetes itself. I’m able to connect with the OpenSearch node through the browser when using a docker deployment.
I’ve tried the same in Kubernetes using NodePort, LoadBalancer, port forwarding and ingress. All gave me a blank screen.

What is your use case for browser access?

13

Hello @pablo,

Use case: currently I just want it to work. Later, there might be users without dashboard access, but need do see some stats. Of course there are a ton of workaround, like curl, or restapi client/extension, I was just curious why it doesn’t work.

When you connect via portforward, do you get a blank page, or a page says authentication finally failed? So does it actually try to connect but fails? Is there an entry for it in the security logs?

14

@bhornyak Yes, I get the blank screen with port forward and this error in OpenSearch logs.

[2024-01-22T16:15:37,521][WARN ][o.o.s.a.BackendRegistry  ] [opensearch-cluster-master-0] No 'Authorization' header, send 401 and 'WWW-Authenticate Basic'

I’ve got this working another way. I’ve used ModHeader plugin with Chrome browser.
I’ve added an Authorization header with Basic authentication and got a response from the server.

image
image921×315 11.4 KB

image
image1316×608 39.3 KB

15

Thanks @pablo,
I’ll mark it as a solution as this is the method I’ve used as well (restapi client), and found no other viable method.