Ldap resultCode=89 Simple bind operations are not allowed to contain a bind DN without a password

Elastic Orchestration Elastic Cloud Enterprise (ECE)
1

Hi there,

I am trying to add an ldap Connection to the ECE Cluster. But it always throws a warning.

[2019-09-10T14:31:26,948][WARN ][org.elasticsearch.xpack.security.authc.AuthenticationService] [instance-0000000048] Authentication to realm xxx-ldap-xxx failed - authenticate failed (Caused by LDAPException(resultCode=89 (parameter error), diagnosticMessage='Simple bind operations are not allowed to contain a bind DN without a password.', ldapSDKVersion=4.0.8, revision=28812))

September 10th 2019, 15:55:54.217[2019-09-10T14:55:54,040][WARN ][org.elasticsearch.xpack.security.authc.support.DnRoleMapper] [instance-0000000046] Role mapping file [/app/config/role_mapping.yml] for realm [xxx-ldap-xxx] does not exist. Role mapping will be skipped.

I am using ECE 2.3.1.

anonymized data:
Bind DN and password:
CN=user,OU=group,OU=group,DC=example,DC=com

Base DN for Users:
DC=example,DC=com
Scope: Sub-tree
Filter: (sAMAccountName={0})

Base DN for Groups:
OU=group,OU=group,DC=example,DC=com
Scope: Sub-tree

Role Mapping platform admin:
CN=groupname,OU=group,OU=group,DC=example,DC=com

ldapsearch -x -D "CN=user,OU=group,OU=group,DC=example,DC=com "\
           -W -H ldap://ldap.example.com -b "DC=example,DC=com"\
           -s sub '(sAMAccountName=myuser)'

This command is working fine from the cmd. But the Cloud UI does not want our configuration.

Did I miss something?

Thanks in advance

2

I dont know why but it is working after I restartet the security deployment itself.

Before that I have rebootet the whole host system and that did not work.

Could there be a bug that by saving the configuration of ldap the security cluster will be recreated and all data will be transfered. Maybe the new settings won´t be set until a Restart of the nodes.

Sounds wrong to me but I have no other Explanation.

3

Hi Malte. Are you adding LDAP to your own cluster, or to log in to ECE itself (using Authentication Providers)? If you mean the latter, I believe this might be due to a bug in the way our ECE keystore management implementation works. Under the hood the LDAP Authentication Providers UI stores passwords in the Keystore via the ECE "metadata" and the rest of the configuration in a regular ECE plan, which causes a potential race condition. We are aware of the issue and looking to have it fixed, hopefully for 2.4 but if not then some time after.

1 Like
4

Yes it is in ECE itself.

For now a simple restart of the security cluster is working.

Thanks
Malte

5

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