# Kibana default basic auth **URL:** \ **Category:** Kibana\ **Created:** [May 17, 2017, 5:56am UTC](https://discuss.elastic.co/t/kibana-default-basic-auth/86045 "2017-05-17T05:56:22Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![Brandon\_Kobel](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/brandon_kobel/32/14829_2.png) [@Brandon\_Kobel](https://discuss.elastic.co/u/Brandon_Kobel)\ **Post date:** [May 17, 2017, 2:36pm UTC](https://discuss.elastic.co/t/kibana-default-basic-auth/86045/2 "2017-05-17T14:36:40Z")
@ccrecana this behavior has been changed in 5.2.0, as this wasn't an intentional behavior. There are a few options to do what you're looking for, but first it might help to explain a bit of the background/details of Kibana/Elasticsearch auth. The way that authentication/authorization works with Elasticsearch via Kibana is two-fold. There is an internal user that Kibana uses to setup the initial .kibana index, the reporting queue, and various administrative features which is controlled by setting `elasticsearch.username` and `elasticsearch.password` in the kibana.yml. However, when the user accesses Kibana they are then forced to authenticate, and this information is "proxied" to Elasticsearch. If you were to install and enable X-Pack Security in Kibana, they'd be prompted with the Login screen at this point and allowed to login. In Kibana 5.1.2, Kibana erroneously passed the username/password on every request if you used a `elasticsearch.url` like "[https://user:passwd@my-elasticsearch-server:9200](https://user:passwd@my-elasticsearch-server:9200)", which broke this intended behavior. If you wish to emulate this behavior, the closest way to do so is with Option 2 listed below; however, there are some drawbacks to this approach and generally we recommend Option 1. ##Option 1 - Reverse Proxy w/ Basic Auth Header You can configure Kibana to be behind a reverse proxy that always sets the Baic Auth Headers to a hard-coded user. This way when the user accesses Kibana via the reverse proxy URL, they will get the hard-coded user; however, if you wanted to login as another user you could access Kibana directly and login this way. The following discuss reply illustrates how to do so using NGINX: [Auto-authenticating to iframe-embedded Kibana dashboard](https://discuss.elastic.co/t/auto-authenticating-to-iframe-embedded-kibana-dashboard/46091/4) . This same thing can be accomplished via Apache/HAProxy/etc. This option works with and without X-Pack Security installed/enabled in Kibana, and provides the ability to access Kibana as an alternate user. However, it does require you to setup/manage a reverse proxy. ##Option 2 - Kibana customHeaders This solution is very similar to Option 1. Using the `elasticsearch.customHeaders` setting in the kibana.yml you can pass the same Basic Auth headers to Elasticsearch on every request. However, you'll have to disable X-Pack Security in Kibana for this option to work. This solution doesn't require a reverse proxy; however, you will be forced to use Kibana as the same user, and disable X-Pack Security. ##Option 3 - Elasticsearch Anonymous Access Elasticsearch allows you to configure a default user/role(s) when an anonymous user tries to access Elasticsearch itself. How to do so is discussed [here](https://www.elastic.co/guide/en/x-pack/current/anonymous-access.html). It's possible to essentially set the default user for Kibana using this feature; however, it'll apply to all Elasticsearch access so caution should be taken on which roles/privileges you give this user. This will also require you to disable X-Pack Security in Kibana for this to work. --- _[View the full topic](https://discuss.elastic.co/t/kibana-default-basic-auth/86045)._