Fixes #172. LDAP_BASE_DN env was not used for the actual LDAP base

[christian-scheible]

When environmentvariables have been set like this:
LDAP_BASE_DN="o=some org,c=com"
LDAP_DOMAIN="some-org.com"

The base dn of the generated LDAP is dc=some-org,dc=com instead of o=some org,c=com

This commit fixes that.

It might be better to move the change to a file different from 02-security.ldif or maybe renaming it as this might be confusing otherwise.

[christian-scheible]

Actually this is not the only thing that needs to be done in order to enable Base DN in X.500 format.

1. The Base DN entry has to be created by adding it to /container/service/slapd/assets/config/bootstrap/ldif/custom
   The file would look like:

dn: o=some org,c=com
objectclass: organization
objectclass: extensibleObject
o: some org
c: com

[BertrandGouny]

Hello,
not sure to understand what this attempt to fix, is the 2nd comment about the same thing ?

[christian-scheible]

Hi,

yes the 2nd comment is about the same thing.

1. The changes to 02-security.ldif are necessary to set olcSuffix and olcRootDN to the proper values (this makes it possible to login as cn=admin,ou=administratoren,o=some org,c=com)
2. The changes to startup.sh makes it possible to use the same user cn=admin,ou=administratoren,o=some org,c=com which contains a space to apply changes to LDAP using LDIF Files
3. The comment explains that it is still needed to add the root entry to the LDAP directory (o=some org,c=com) because otherwise the user will be able to login but there is no Base-DN entry in the directory

I might be possible to solve number 3 using a script by adding the Base-DN entry using the information from the LDAP_BASE_DN environment variable.

Easier would be to explain in the documentation that users have to add an LDIF file as explained in the comment if they want to choose a LDAP_BASE_DN that is not derived from the LDAP_DOMAIN.

[j-maas]

This is related to #307. There I have discovered that slapd apparently initializes the database based on the domain. So if there is a way to change slapd's behavior, I think that would be an even cleaner fix for the issue.

[anthony-o]

I have the feeling that https://serverfault.com/a/469400/93281 is more or less related to this problem, am I wrong?

[anthony-o]

For example, in order for me to take my parameter LDAP_BASE_DN=ou=myou,o=gouv,c=fr into account, using the following compose-file:

version: '2'
services:
  my-ldap:
    image: osixia/openldap:1.2.4
    volumes:
      - ./ldap/custom:/container/service/slapd/assets/config/bootstrap/ldif/custom:ro
    command: --loglevel trace --copy-service
    environment:
      - LDAP_ORGANISATION=gouv
      - LDAP_DOMAIN=gouv.fr
      - LDAP_BASE_DN=ou=myou,o=gouv,c=fr
      #- LDAP_LOG_LEVEL=32 # http://www.openldap.org/doc/admin24/slapdconf2.html#olcLogLevel:%20%3Clevel%3E
    ports:
      - 8389:389
      - 8636:636

I must write those 2 files into ./ldap/custom folder:

• 01-olcRootDN.ldif

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: ou=myou,o=gouv,c=fr
-
replace: olcRootDN
olcRootDN: cn=admin,ou=myou,o=gouv,c=fr

• 02-createRootDN.ldif

dn: ou=myou,o=gouv,c=fr
changetype: add
objectClass: organizationalUnit
ou: myou

[ricejamesh]

So what's the outcome?