LDAP_BASE_DN ignored when it contains o=/ou=

[dmlary]

When using a LDAP_BASE_DN that contains o= and ou= fields, the container ignores them and just creates a basedn using the LDAP_DOMAIN.

This is similar to #380, and I've tried the fix merged into v1.4.0 by #382, but that doesn't resolve the problem, just gets me passed the error preventing the creation.

docker compose:

services:
  openldap:
    image: osixia/openldap:release-1.4.0-dev
    environment:
      LDAP_ORGANISATION: 'Team, Org, in Company'
      LDAP_DOMAIN: company.org
      LDAP_BASE_DN: ou=team,o=org,dc=company,dc=org

ldapsearch output:

$docker exec openldap ldapsearch -x -b "" -s base namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#

#
dn:
namingContexts: dc=company,dc=org

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

[obourdon]

@dmlary one "solution" (see further down why I surrounded this with quotes) you might want to try is by using the following parameter instead:

LDAP_DOMAIN: team.org.company.org

However, there is another side effect in the startup script which substitue all x=y values by dc=y
therefore the docker exec openldap slapcat will issue the following contents (if everything else remains unchanged)

$ docker exec ldap slapcat
dn: dc=team,dc=org,dc=company,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: Team, Org, in Company
dc: team
structuralObjectClass: organization
entryUUID: 9eddf11e-23f7-103a-8fc3-395f682933a7
creatorsName: cn=admin,dc=team,dc=org,dc=company,dc=org
createTimestamp: 20200506151135Z
entryCSN: 20200506151135.345720Z#000000#000#000000
modifiersName: cn=admin,dc=team,dc=org,dc=company,dc=org
modifyTimestamp: 20200506151135Z

dn: cn=admin,dc=team,dc=org,dc=company,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9ZUdHQVRQVktFTFppQkVXRFI5bjZRRlB3ZGp1WjZmbzQ=
structuralObjectClass: organizationalRole
entryUUID: 9ede6c48-23f7-103a-8fc4-395f682933a7
creatorsName: cn=admin,dc=team,dc=org,dc=company,dc=org
createTimestamp: 20200506151135Z
entryCSN: 20200506151135.348900Z#000000#000#000000
modifiersName: cn=admin,dc=team,dc=org,dc=company,dc=org
modifyTimestamp: 20200506151135Z

However, I am still not intimately convinced about what 'intrication' there should be between the 2 parameters .... and this is why I had created this issue: LDAP_DOMAIN & LDAP_BASE_DN informations request & brainstorming

[obourdon]

Not sure it is related by I also found this Pull Request which might also have an impact

[TcaManager]

Still no solution about this?

[obourdon]

@TcaManager what is your nominal case please ? Did you look at the informations provided above which sometimes help solving some of the problems?

[TcaManager]

Hi, we have all our schemas based on ou=xxx,o=gouv,c=fr and all our domain xxx.gouv.fr so if I try to fix domain, I get a dc=xxx,dc=gouv,dc=fr Base Dn and If I try oly to fix Base Dn I get example.com Domain and no start. If I do both, only the domain is used. What should I do? I read all the cases in that page, none fixed both tose elements.

[TcaManager]

I'm using osixia:openldap/latest btw