Unable to login via LDAP if user password contains special chars

Elastic Stack Elasticsearch
1

I'm experimenting with Elasticsearch and X-Pack, I'm using X-Pack in trial mode with no license, installed via RPM.

I've installed a 2-node cluster on Oracle Linux 7.x, using Oracle jdk1.8.0_121 (
localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: it
X11 Layout: it,us
X11 Variant: ,
).

I installed X-Pack plugin for elastichsearch and Kybana, then I configured a realm to authenticate against our Active Directory (no SSL, Windows 2012 R2) and it works fine, I'm able to login in Elastiscsearch and Kybana with roles that I mapped.

Then I configured a realm to authenticate against an LDAP infrastructure (389console) and I was never able to login, authentication ever fails. I've done a lot of checks without observe any error so I tried changing the LDAP user's password with a simpler one without any special chars and, magically, authentication via LDAP starts working like a charm.
Then I restored previous password and authentication fails again. The only not-alphanum chars in the password were an "@" and a "-"
The same password for a user authenticated via AD works with no issue, seems to be an issue only when using LDAP realms.

So... I think if there was a bug in the parser for LDAP realms there would be many reports about instead I found nothing.
What am I doing wrong?

2

Can you share the ldap settings you configured in the elasticsearch.yml file?

3

Sure.

xpack:
  security:
    authc:
      realms:
        ldap1:
          type: ldap
          order: 20
          enabled: true
          url: ldap://ldap01vm.domain.local:389, ldap://ldap02vm.domain.local:389
          bind_dn: "uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot"
          bind_password: password
          user_search:
            base_dn: "ou=People,o=domain,c=it"
            attribute: uid
          group_search:
            base_dn: "ou=Groups,o=domain,c=it"
          unmapped_groups_as_roles: false
4

Is it this password that has the special character? If so try using single quotes instead of double quotes around the password in the yaml file.

5

No, it hasn't.
Bindings to LDAP is fine, If I change my user password to remove the "@" in it, authentication works fine.

Authentication fails only if user's password contain special chars (to tell the true, I haven't tried other special chars, the testing password contains only one "@" and a "-" and the other which instead succeed only letters).
But the same password with "@" and "-", against an AD realm, succeed.
Tested with two different user, with similar password.

I tried from kybana but also sending a request via CURL from command line, with the same results.

6

Hmm ok. Can you update the log level:

PUT /_cluster/settings
{"transient":{"logger.org.elasticsearch.xpack.security.authc": "TRACE"}}

Then try to authenticate as the user with special characters in the password and provide the log output?

7

Successful (even if with a "$" in the password):

[2017-03-07T19:02:50,557][DEBUG][o.e.x.s.a.l.LdapRealm    ] [elaprod01] cached user's password changed. authenticated user [fracassetti.monitor], with roles [[superuser]]
[2017-03-07T19:02:50,620][DEBUG][o.e.x.s.a.l.LdapRealm    ] [elaprod01] authenticated user [fracassetti.monitor], with roles [[superuser]]
[2017-03-07T19:02:50,620][DEBUG][o.e.x.s.a.l.LdapRealm    ] [elaprod01] authenticated user [fracassetti.monitor], with roles [[superuser]]

With an @ in the password:

[2017-03-07T19:04:07,181][DEBUG][o.e.x.s.a.l.LdapRealm    ] [elaprod01] user not found in cache, proceeding with normal authentication
[2017-03-07T19:04:07,184][TRACE][o.e.x.s.a.l.s.LdapUtils  ] LDAP Search SearchRequest(baseDN='ou=People,o=domain,c=it', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(uid=fracassetti.monitor)', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=4, entriesReturned=1, referencesReturned=0) ([SearchResultEntry(dn='uid=fracassetti.monitor,ou=People,o=domain,c=it', messageID=4, attributes={}, controls={})])

So, the issue is related to the "@" in the password, and not to specials chars in general...

8

I've done a quick test with Elasticsearch+X-Pack 5.2.2 with OpenLDAP, and I was able to login using a password with @ in it.

So the next step is to try and see what is special about your environment.
I'll aim to run up a 389DS environment for testing, but it may be some time before I can do that.

Can you tell us which version of Elasticsearch you're running? It looks like it's not the latest one - if you were on 5.2.2 there would be another log message when the authentication fails.

Is it possible for you to upgrade to 5.2.2? I can't think of anything in that version that would fix this problem, but it will give us more details in the logs.

Also, when you are doing this testing, how are you logging in? Is it via Kibana or via curl?
For testing purposes, we'd like to eliminate as many variables as possible, so the simplest test is:

curl -u YOUR_USER_ID  "YOUR_ELASTICSEARCH_URL"

e.g. curl -u tim "http://localhost:9200/"

Thanks.

9

We were running version 5.2.1, installed via RPM on Oracle Linux.
The issue exists both via kibana or via curl

Just updated to 5.2.2:

With the @ in the password:

# curl -u fracassetti.monitor "http://localhost:9200/"
Enter host password for user 'fracassetti.monitor':
{"error":{"root_cause":[{"type":"security_exception","reason":"unable to authenticate user [fracassetti.monitor] for REST request [/]","header":{"WWW-Authenticate":"Basic realm=\"security\" charset=\"UTF-8\""}}],"type":"security_exception","reason":"unable to authenticate user [fracassetti.monitor] for REST request [/]","header":{"WWW-Authenticate":"Basic realm=\"security\" charset=\"UTF-8\""}},"status":401}

Without the @ in the password:

# curl -u fracassetti.monitor "http://localhost:9200/"
Enter host password for user 'fracassetti.monitor':
{
  "name" : "elaprod01",
  "cluster_name" : "elaprod-sole-log",
  "cluster_uuid" : "IT_Xc_LRTSWQKPZv9pfjqg",
  "version" : {
    "number" : "5.2.2",
    "build_hash" : "f9d9b74",
    "build_date" : "2017-02-24T17:26:45.835Z",
    "build_snapshot" : false,
    "lucene_version" : "6.4.1"
  },
  "tagline" : "You Know, for Search"
}
10

Can you also provide the details from elasticsearch.log for that attempt. It should say something like:

[INFO ][o.e.x.s.a.l.LdapRealm    ] [elasprod01] authenticate failed for user [fracassetti.monitor]:  << REASON >>

If you have DEBUG turned on, it will probably have a stack trace as well.

Thanks.

12

Successful:

> [2017-03-08T12:28:48,242][DEBUG][o.e.x.s.a.l.LdapRealm ] [elaprod01] authenticated user [fracassetti.monitor], with roles [[superuser]]

Failed:

[2017-03-08T12:29:23,786][TRACE][o.e.x.s.a.l.s.LdapUtils  ] LDAP Search SearchRequest(baseDN='ou=People,o=cup2000,c=it', scope=SUB, deref=NEVER, sizeLimit=0, timeLimit=5, filter='(uid=fracassetti.monitor)', attrs={1.1}) => SearchResult(resultCode=0 (success), messageID=2, entriesReturned=1, referencesReturned=0) ([SearchResultEntry(dn='uid=fracassetti.monitor,ou=People,o=domain,c=it', messageID=2, attributes={}, controls={})])
[2017-03-08T12:29:28,797][INFO ][o.e.x.s.a.l.LdapRealm    ] [elaprod01] authenticate failed for user [fracassetti.monitor]: invalid credentials
13

The account I used for test LDAP authentication is a currently-working account which I use every day to access to a mailbox, so when autenticating vs other systems, LDAP auth with the @ in the password works fine.

The issue appears only when elasticsearch (via kibana or CURL) tries to authenticate vs this ldap. The same password, used for authenticate a different user vs an AD realm, works fine.

And what if I try con configure an LDAP realm against our AD DC? May be useful?

14

Done.
Is surely an issue limited to our LDAP servers: configuring an LDAP realm against our DCs works fine even with "@" in the password.

I have no idea about the issue but, in the end, should not be an issue of elasticsearch/x-pack.

15

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