0

I have set up an openldap (osixia/openldap:1.4.0) container in k8s and it runs smoothly. However, when my app wants to connect to it using the default admin/admin creds, it fails.

Data: I have this in my manifest file:

  env:
    - name: LDAP_ADMIN_PASSWORD
      value: "admin"

I have mounted an ldif file (under /container/service/slapd/assets/config/bootstrap/ldif/custom) as well. It contains this :

dn: uid=admin,ou=people,dc=example,dc=org
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Ben Alex
sn: Alex
uid: admin
userPassword: admin

I can see this in the ldap container log:

5f86c067 conn=1006 fd=12 ACCEPT from IP=192.168.37.92:59420 (IP=0.0.0.0:389) 5f86c067 conn=1006 op=0 BIND dn="uid=admin,ou=people,dc=example,dc=org" method=128 5f86c067 conn=1006 op=0 RESULT tag=97 err=49 text= 5f86c067 conn=1006 fd=12 closed (connection lost)

Any idea what is wrong?

Gábor Varga
  • 1
  • 2
  • try use [debug loglevel option](https://github.com/osixia/docker-openldap#debug), please provide reproducible example with used commands – Mark Oct 14 '20 at 12:03
  • Already using debug level when starting the container: args: [ "--copy-service", "--loglevel", "debug" ] and I logged in to the container and ran this ldapsearch command: ldapsearch -h localhost -p 389 -x -D "uid=admin,ou=people,dc=example,dc=org" -b "dc=example,dc=org" -w admin ldap_bind: Invalid credentials (49) – Gábor Varga Oct 14 '20 at 12:41
  • Since then it turned out that only the admin user defined in the ldif file has problems. If I change the request like this (different domain) then it is okay: ldapsearch -h localhost -p 389 -x -D "cn=admin,dc=example,dc=org" -b "DC=example,DC=org" -w admin – Gábor Varga Oct 14 '20 at 13:02
  • You mentioned about mounting ldif file into ..ldif/custom - How did you install osixia/openldap? It's an official helm repo or custom deployment? – Mark Oct 15 '20 at 13:44
  • Custom deployment. As a workaround, I have loaded the ldif file manually after the openldap container has been started and ldapsearch works now. I have seen some problems during the openldap startup in the log, but it's not worth to investigate it any more. The openldap config (with the custom ldif data in it) is now saved on an AWS EFS drive so if the pod crashes, the new container will work smoothly using the saved data. Case closed. – Gábor Varga Oct 19 '20 at 08:49

0 Answers0