Kibana LDAP 401

Hi all,

I am receiving 401 Unauthorized errors when trying to log in via the kibana UI with LDAP credentials.

I have spun up a Elasticsearch cluster on Azure's AKS using the official helm charts and images, and have configured elasticsearch to properly authenticate requests against our LDAP service (meaning my requests get authorized using my LDAP credentials). I have assigned roles to myself and others to facilitate this, as per the guides. Here is the relevant ES configs regarding my LDAP:

      xpack.security.authc.realms:
        ldap:
          ldap1:
            order: 0
            url: "ldap://gwipa.geekweek.network"
            user_dn_templates:
              - 'uid={0},cn=users,cn=accounts,dc=geekweek,dc=network'

As far as I can tell, ES is happy as a clam with my configs!

I have also spun up a kibana instance using the official helm charts and images. I am NOT able to log in with my LDAP credentials. I receive a 401 response.

Here are my configs that end up in the kibana.conf:

    xpack.security.authc.providers:
      basic.ldap1:
        order: 0
        enabled: true

Here is the response the UI receives:

{"statusCode":401,"error":"Unauthorized","message":"[security_exception] unable to authenticate user [ian.gabriel] for REST request [/_security/_authenticate], with { header={ WWW-Authenticate={ 0=\"Bearer realm=\\\"security\\\"\" & 1=\"ApiKey\" & 2=\"Basic realm=\\\"security\\\" charset=\\\"UTF-8\\\"\" } } }"}

I am able to succesfully log into kibana using the elastic user. My

I followed some of the conversation from this issue: Unable to login to Kibana by using LDAP user who is having a superuser role and tried to add my kibana user to various roles, which did not seem to help. I also enabled the TRACE debugging mentioned there, and hunted through my logs. The logs seem to say that Kibana tries the other auth realms that ES has configured file and native, and doesn't see the ldap1 realm I have configured. I am not sure why that would be. Here are those logs (truncated to just the message field):

"Found authentication credentials [org.elasticsearch.xpack.core.security.authc.support.UsernamePasswordToken] for principal [ian.gabriel] in request [rest request uri [/_security/_authenticate]]"
"Checking token of type [org.elasticsearch.xpack.core.security.authc.support.UsernamePasswordToken] against [3] realm(s)"
"Trying to authenticate [ian.gabriel] using realm [reserved/reserved] with token [org.elasticsearch.xpack.core.security.authc.support.UsernamePasswordToken] "
"Authentication of [ian.gabriel] using realm [reserved/reserved] with token [UsernamePasswordToken] was [AuthenticationResult{status=CONTINUE, user=null, message=null, exception=null}]"
"Found existing authentication [Authentication[User[username=_xpack_security,roles=[superuser],fullName=null,email=null,metadata={}],type=INTERNAL,by={Realm[__attach.__attach] on Node[tim-es-data-0]}]] in request [transport request action [indices:data/read/get[s]]]"
"Trying to authenticate [ian.gabriel] using realm [file/file1] with token [org.elasticsearch.xpack.core.security.authc.support.UsernamePasswordToken] "
"Authentication of [ian.gabriel] using realm [file/file1] with token [UsernamePasswordToken] was [AuthenticationResult{status=CONTINUE, user=null, message=null, exception=null}]"
"Trying to authenticate [ian.gabriel] using realm [native/native1] with token [org.elasticsearch.xpack.core.security.authc.support.UsernamePasswordToken] "
"Found existing authentication [Authentication[User[username=_xpack_security,roles=[superuser],fullName=null,email=null,metadata={}],type=INTERNAL,by={Realm[__attach.__attach] on Node[tim-es-data-0]}]] in request [transport request action [indices:data/read/get]]"
"Authentication of [ian.gabriel] using realm [native/native1] with token [UsernamePasswordToken] was [AuthenticationResult{status=CONTINUE, user=null, message=null, exception=null}]"
"Failed to authenticate request [rest request uri [/_security/_authenticate]]"

When logged into the kibana instance as the elastic user, i do see a weird error message regarding Realms:

This confuses me, as I /feel/ like i have my LDAP realm enabled in elasticsearch, as I am able to log in? I have added my kibana user to the superuser role while debjugging, and have left it in there for now.

I am fairly certain I have made a small configuration mistake somewhere along the line, am looking for pointers to get me there!

Thanks again for your assistance.

1 Like

It's going to be easier to debug this from the Elasticsearch side rather than Kibana.

For authentication with a username and password (regardless of what realm type is used to check those credentials) Kibana doesn't do very much except pass the credentials to Elasticsearch.

At the very least you want to check the Elasticsearch logs for information, but you may also find it easier to debug this using curl instead of going through Kibana.

As first guess regarding the cause, what sort of licence are you using? LDAP is a paid feature, and requires at least a gold license.

1 Like

Thanks for your reply, I appreciate you taking the time!

It turns out that after following your recommendation to debug from the ES side, I have discovered that I inconsistently have applied my LDAP configuration to my ES nodes.

I have a 17 node cluster, with two nodes as ingest nodes. My Kubernetes Load balancer definition for external HTTP traffic only selects these ingest pods as destination nodes for the traffic. These ingest nodes were also the only nodes I had applied my XPACK LDAP configs to. All my other nodes, master and data, were not aware of the LDAP realm.

Kibana, on the other hand, used an kubernetes internal service definition, which selects all of the nodes. While debugging, data nodes without the ldap realm configured were selected to authenticate against, which aligns with the above elasticsearch logs not displaying the ldap realm.

For future readers, make sure to apply your security configurations to all of your node types :slight_smile:

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.