OpenID connect fails with TOO MANY REDIRECTS


Opensearch dashboard connect with openid fails with Too many redirects.

URL added in Azure : http://localhost:5601/auth/openid/login
base_redirect_url : http://localhost:5601
I have not added any internal users. Kindly let me know if there are any changes needed.

The internal users you are referring to, is that users for basic auth? (i.e. internal users in security plugin)

Did you get this working with just basic auth and then add openid?

Yes. I have added the basic auth but not the internal users. Should I add the internal users to get it working?

#securityConfigSecret: “”
config.yml: |-
description: “Authenticate via HTTP Basic against internal users database”
http_enabled: true
transport_enabled: true
order: 1
type: basic
challenge: false
type: internal
http_enabled: true
transport_enabled: true
order: 0
type: openid
challenge: false
subject_key: preferred_name
roles_key: roles
type: noop

  # internal_users.yml: |-
  # roles.yml: |-
  # roles_mapping.yml: |-
  # action_groups.yml: |-
  # tenants.yml: |-

Can you provide copy of the opensearchDashboards.yml config? What is it using to authenticate with opensearch? Is it not username and password? Which would need to be present in internal users db


    verificationMode: none
  username: "kibanaserver"
  password: "kibanaserver"

@Vikash This user needs to be present in the internal users to authenticate successfully

Does it impact even the openid authentiation? I am able to authenticate successfully from AD.

Or is the internal user authentication is mandatory for authentication even if I use openid?

The config in Dashboards file is trying to authenticate OSDashboards with opensearch and this is needed to create connection between the two. The actual users are totally separate and will authenticate via openid.

Are you able to login using kibanaserver/kibanaserver? If yes, it would mean that the user is indeed present in internal db, and is perhaps created by default.

The best way to check is to retrieve full config from the security index by connecting to one of the nodes and running below:

./ -icl -nhnv -cacert /usr/share/opensearch/config/root-ca.pem -cert /usr/share/opensearch/config/kirk.pem -key /usr/share/opensearch/config/kirk-key.pem -r

The extracted files are saved with timestamp appended to the name. View the content of internal_users_…yaml file and check if the kibanaserver user is present

cat internal_users_2021-Nov-29_11-50-59.yml

type: “internalusers”
config_version: 2
hash: “$2a$12$VcCDgh2NDk07JGN0rjGbM.Ad41qVR/YFJcgHp0UGns5JDymv…TOG”
reserved: true

  • “admin”
    description: “Demo admin user”
    hash: “$2a$12$4AcgAt3xwOWadA5s5blL6ev39OXDNhmOesEoo33eZtrq2N0YrU3H.”
    reserved: true
    description: “Demo OpenSearch Dashboards user”

Seems like the user is already present when i ran the command in opensearch. Do i still need to add them in internal users.yml?

No, there is no need to add since it’s already there.

I have just uploaded docker-compose directory to github, I would recommend to clone and just run docker-compose up

It’s pointing to test Azure, username and password are in the README.

If it works for you, point it to your Azure and repeat the test. If it works, you know it’s your OS config which is causing it and you will find all the config in the repo, if it doesn’t work for you, the issue is from Azure side, and I can upload screenshots of my setup, although it might not be the best set up, It’s just how I’ve got it to work.

I am using HELM to deploy opensearch and os_dashboard. Highly appreciate if you have any examples on the same. Also kindly upload the screenshots as well. Let me test the config and get back to you

I don’t have any examples of HELM, however it’s the very same setup except the configs are provided via values.yaml file. I’d recommend trying the docker-compose method to eliminate the potential issues of misconfiguration either from Azure or OS side. Once that’s working it should be pretty straight forward to get it working using HELM.

What is the redirect URL added in Azure AD?

Just uploaded to github,

it’s http://localhost:5601/auth/openid/login

The issue you are having might be related to the size of the cookie as mentioned here

Do we have to run any script after updating the opensearch_dashboard.yml file from inside the container?

OSDashboards needs to be restarted for changes in opensearch_dashboard.yml file to take effect.

Is the Azure AD redirect still available for testing?