Name and Version

bitnami/openldap2.6

What architecture are you using?

amd64

What steps will reproduce the bug?

This is more of a question rather than a bug/issue, I don't know whether this is a right section to ask this. but here it goes... I am trying to set up Openldap sync replication between two bitnami openldap containers.

I tried to set up ldap provider server using environment variables specified in following section https://github.com/bitnami/containers/tree/main/bitnami/openldap#sync-provider

However I didn't find any provision to set up LDAP consumer, As there was no provision to set up ldap consumer, I went through Official OpenLDAP docs to configure ldap consumer server manually following is the link of docs https://openldap.org/doc/admin26/replication.html

The docs has mentioned to specify following configuration in ldap server to make it LDAP client

18.3.1.3. Set up the consumer slapd The syncrepl directive is specified in the database section of slapd.conf(5) for the consumer context. The syncrepl engine is backend independent and the directive can be defined with any database type.

       database mdb
       maxsize 1073741824
       suffix dc=Example,dc=com
       rootdn dc=Example,dc=com
       directory /var/ldap/db
       index objectclass,entryCSN,entryUUID eq

       syncrepl rid=123
               provider=ldap://provider.example.com:389
               type=refreshOnly
               interval=01:00:00:00
               searchbase="dc=example,dc=com"
               filter="(objectClass=organizationalPerson)"
               scope=sub
               attrs="cn,sn,ou,telephoneNumber,title,l"
               schemachecking=off
               bindmethod=simple
               binddn="cn=syncuser,dc=example,dc=com"
               credentials=secret

However, I don't see any slapd.conf in the container image following is the command I have used to find slapd.conf

$ find / -name slapd.conf
find: '/etc/ssl/private': Permission denied
find: '/var/cache/ldconfig': Permission denied
find: '/proc/tty/driver': Permission denied
find: '/root': Permission denied
$ sudo find / -name slapd.conf
bash: sudo: command not found

What do you see instead?

Actually I didn't find any steps/document to setup OpenLDAP replication and also not able to find slapd.conf
I see most of the configurations are added using .ldif files but I am not able to find how to set up consumer ldap server using .ldif files in official OpenLDAP documents.

Sep 23 '24 12:09 rohan-97

Did you check the different configuration options provided via env. vars? See https://github.com/bitnami/containers/tree/main/bitnami/openldap#configuration

Sep 24 '24 06:09 carrodher

Hi @carrodher ,

I went through all the environment variables, but I didn't find any relevant environment variable,

There is one configuration LDAP_ENABLE_SYNCPROV however it is used to set up producer ldap server, However in order to make replication work, consumer ldap server is also required which requires adding following configuration in slapd.conf

        database mdb
        maxsize 1073741824
        suffix dc=Example,dc=com
        rootdn dc=Example,dc=com
        directory /var/ldap/db
        index objectclass,entryCSN,entryUUID eq

        syncrepl rid=123
                provider=ldap://provider.example.com:389
                type=refreshOnly
                interval=01:00:00:00
                searchbase="dc=example,dc=com"
                filter="(objectClass=organizationalPerson)"
                scope=sub
                attrs="cn,sn,ou,telephoneNumber,title,l"
                schemachecking=off
                bindmethod=simple
                binddn="cn=syncuser,dc=example,dc=com"
                credentials=secret

However I am not able to find slapd.conf in the container image.

Is there any environment variable through which we can add custom LDAP configurations in slapd.conf?

Sep 24 '24 08:09 rohan-97

I encountered the same issue. As far as I understand, slapd.conf is a deprecated configuration file, and it seems that the configuration should be done through an LDIF file. However, I am not sure how to set it up in this image either.

Sep 26 '24 11:09 cfxccn

I have configured mirrormode using the ldif+ldapadd command. First, I prepared an LDIF file:

dn: cn=config
changeType: modify
add: olcServerID
olcServerID: 101

dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=100
  provider=ldap://openldap-0:389
  bindmethod=simple
  binddn="cn=admin,dc=example,dc=org"
  credentials=xxxxx
  searchbase="dc=example,dc=org"
  scope=sub
  schemachecking=on
  type=refreshAndPersist
  retry="30 5 300 3"
  interval=00:00:05:00
-
add: olcMirrorMode
olcMirrorMode: TRUE

According to the rules, I modified the rid, olcServerID, and provider to generate a second LDIF file. Then, I executed [ ldapadd -Q -Y EXTERNAL -H "ldapi:///" -f xxx.ldif ]on each of the two servers.

Sep 27 '24 01:09 cfxccn

Hi @cfxccn , Thanks a lot for the reply!,

I'll try out these configurations :)

Sep 27 '24 12:09 rohan-97

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Oct 17 '24 01:10 github-actions[bot]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Nov 03 '24 01:11 github-actions[bot]

I'll try out these configurations :)

@rohan-97 Does this method work? please.

Nov 06 '24 18:11 SidneySun

Hi @SidneySun ,

I tried above configurations, they didn't worked. I felt I might be doing some misconfiguration.

Major issue is that the documents shows configuration corresponding to slapd.conf,

Hence I created two debian system and installed openldap in both of them. and configure producer-consumer replication

Following is the configuration on both the debian system,

producer debian slapd.conf

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/inetorgperson.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

loglevel        any

# Load dynamic backend modules:
modulepath      /usr/lib/ldap
moduleload      back_mdb.la
moduleload      syncprov.la
# moduleload    back_ldap.la

# Sample security restrictions
#       Require integrity protection (prevent hijacking)
#       Require 112-bit (3DES or better) encryption for updates
#       Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#       by self write
#       by users read
#       by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# config database definitions
#######################################################################
database config
# Uncomment the rootpw line to allow binding as the cn=config
# rootdn so that temporary modifications to the configuration can be made
# while slapd is running. They will not persist across a restart.
# rootpw secret

#######################################################################
# MDB database definitions
#######################################################################

database        mdb
maxsize         1073741824
suffix          "dc=stack,dc=com"
rootdn          "cn=Manager,dc=stack,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory       /opt/ldap/db
# Indices to maintain
index   objectClass     eq
index   cn              eq,sub,pres,approx
index   uid             eq,sub,pres
index   sn              eq,sub,approx
index   member          eq
index   entryCSN,entryUUID eq
access to * by * manage

overlay syncprov
syncprov-checkpoint 50 10
syncprov-sessionlog 100

#######################################################################
# monitor database definitions
#######################################################################
database monitor

consumer debian slapd.conf

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/inetorgperson.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

loglevel        any

# Load dynamic backend modules:
modulepath      /usr/lib/ldap
moduleload      back_mdb.la
moduleload      syncprov.la
# moduleload    back_ldap.la

# Sample security restrictions
#       Require integrity protection (prevent hijacking)
#       Require 112-bit (3DES or better) encryption for updates
#       Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#       by self write
#       by users read
#       by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# config database definitions
#######################################################################
database config
# Uncomment the rootpw line to allow binding as the cn=config
# rootdn so that temporary modifications to the configuration can be made
# while slapd is running. They will not persist across a restart.
# rootpw secret

#######################################################################
# MDB database definitions
#######################################################################

database        mdb
maxsize         1073741824
suffix          "dc=stack,dc=com"
rootdn          "cn=Manager,dc=stack,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw          secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory       /opt/ldap/db
# Indices to maintain
index   objectClass     eq
index   cn              eq,sub,pres,approx
index   uid             eq,sub,pres
index   sn              eq,sub,approx
index   member          eq
index   entryCSN,entryUUID eq
access to * by * manage

syncrepl rid=001
  provider=ldap://10.31.1.75
  type=refreshOnly
  interval=00:00:05:00
  searchbase="dc=stack,dc=com"
  binddn="uid=syncrepl,ou=system,dc=stack,dc=com"
  credentials=secret

updateref ldap://10.31.1.75

#######################################################################
# monitor database definitions
#######################################################################
database monitor

The replication worked.

After that I wanted to generate ldif configuration files from above machines hence I executed following command

slaptest -f /etc/ldap/slapd.conf -F /tmp/slapd.d/

then I found following ldif configuration file generated inside /tmp/slapd.d directory

cat ./cn=config/olcDatabase={1}mdb.ldif
.
.
.
olcSyncUseSubentry: FALSE
olcSyncrepl: rid=001 provider=ldap://10.31.1.75 bindmethod=simple timeout=0 ne
 twork-timeout=0 binddn="uid=syncrepl,ou=system,dc=stack,dc=com" credentials="
 secret" keepalive=0:0:0 tcp-user-timeout=0 starttls=no filter="(objectclass=*
 )" searchbase="dc=stack,dc=com" scope=sub schemachecking=off type=refreshOnly
  interval=00:00:05:00 retry=undefined
olcUpdateRef: ldap://10.31.1.75
.
.
.

so I switched back to Bitnami OpenLDAP containers, and executed following LDIF file on consumer Bitnami LDAP pod

dn: cn=config
changeType: modify
add: olcServerID
olcServerID: 001

dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncrepl: rid=001
        provider=ldap://ldap-server-service.pty-service-dispatcher.svc.cluster.local:1389
        bindmethod=simple
        timeout=0
        network-timeout=0
		binddn="cn=superuser,dc=example,dc=com"
		credentials="admin123"
        keepalive=0:0:0
        tcp-user-timeout=0
        starttls=no
        filter="(objectclass=*)"
        searchbase="dc=example,dc=com"
        scope=sub
        schemachecking=off
        type=refreshOnly
        interval=00:00:05:00
        retry=undefined
-
add: olcUpdateRef
olcUpdateRef: ldap://ldap-server-service.pty-service-dispatcher.svc.cluster.local:1389

and enabled following environment variable flags on producer bitnami LDAP pod

LDAP_ENABLE_SYNCPROV: "yes"

On Consumer LDAP pod syncreplication got configured, I see following output while adding entry in consumer LDAP container.

I have no name!@ldap-server-secondary-58cb699bc9-pvprb:/$ ldapadd -H 'ldapi:///' -D "cn=superuser,dc=example,dc=com" -w "admin123" -f /bitnami/openldap/t
est.ldif
adding new entry "cn=badmin,ou=people,dc=example,dc=com"
ldap_add: Referral (10)
        referrals:
                ldap://ldap-server-service.pty-service-dispatcher.svc.cluster.local:1389/cn=badmin,ou=people,dc=example,dc=com

However

I don't see replication happening from producer bitnami container to consumer bitnami container.

I enabled debug loglevel on both the pods using following flag LDAP_LOGLEVEL=any

It seems like consumer is getting configured properly but producer container is not getting configured properly even after setting LDAP_ENABLE_SYNCPROV=yes

Am I doing anything wrong while setting up producer ldap container?

Following are the environment variables in producer ldap container

I have no name!@ldap-server-secondary-58cb699bc9-pvprb:/$ env
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=ldap-server-secondary-58cb699bc9-pvprb
SECONDARY_LDAP_SERVER_SERVICE_PORT=tcp://10.152.183.28:1389
SECONDARY_LDAP_SERVER_SERVICE_SERVICE_PORT=1389
LDAP_URI=ldap://secondary-ldap-server-service.pty-service-dispatcher.svc.cluster.local
LDAP_ENABLE_TLS=no
SECONDARY_LDAP_SERVER_SERVICE_PORT_1389_TCP_PORT=1389
proxyBindPassword=
PWD=/
OS_FLAVOUR=debian-11
LDAP_READONLY_USER_PASSWORD=xxxxxxxxxx

SECONDARY_LDAP_SERVER_SERVICE_SERVICE_HOST=10.152.183.28
SECONDARY_LDAP_SERVER_SERVICE_PORT_1389_TCP_ADDR=10.152.183.28
HOME=/
KUBERNETES_PORT_443_TCP=tcp://10.152.183.1:443
SECONDARY_LDAP_SERVER_SERVICE_PORT_1389_TCP_PROTO=tcp
SECONDARY_LDAP_SERVER_SERVICE_PORT_1389_TCP=tcp://10.152.183.28:1389
BITNAMI_DEBUG=true
LDAP_BINDDN=cn=superuser,dc=example,dc=com
SECONDARY_LDAP_SERVER_SERVICE_SERVICE_PORT_LDAP=1389
LDAP_SKIP_DEFAULT_TREE=yes
LDAP_ENABLE_SYNCPROV=yes
TERM=xterm
LDAP_ROOT=dc=example,dc=com
USER_DESCRIPTION_MAX_LEN=100
SHLVL=1
KUBERNETES_PORT_443_TCP_PROTO=tcp
USER_NAME_MAX_LEN=100
BITNAMI_APP_NAME=openldap
KUBERNETES_PORT_443_TCP_ADDR=10.152.183.1
APP_VERSION=2.5.13
LDAP_LOGLEVEL=any
KUBERNETES_SERVICE_HOST=10.152.183.1
USER_FIRST_AND_LAST_NAME_MAX_LEN=100
KUBERNETES_PORT=tcp://10.152.183.1:443
KUBERNETES_PORT_443_TCP_PORT=443
LDAP_EXTRA_SCHEMAS=cosine,general-acl,pty-permissions,pty-roles,ppolicy,nis,inetorgperson,rohan
OS_NAME=linux
PATH=/opt/bitnami/openldap/bin:/opt/bitnami/openldap/sbin:/opt/bitnami/common/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LDAP_ADMIN_PASSWORD=admin123
LDAP_ADMIN_USERNAME=superuser
OS_ARCH=amd64
_=/usr/bin/env

Nov 14 '24 08:11 rohan-97

Attaching debug logs from producer and consumer containers.

producer.log consumer.log

It looks like the environment flag LDAP_ENABLE_SYNCPROV: "yes" is not able to enable syncprov on producer ldap container.

Nov 14 '24 08:11 rohan-97

I am having the same issues. I have tried various options as per online documentation and detailed in this issue but still it is not working for me. Has anyone got a working setup? If so, how was this achieved?

Nov 20 '24 11:11 cpowell-gresham

Hi All

After lot of debugging I was able to fix the replication

I was facing following 2 errors while setting up replication

While running standalone consumer container, It was crashing so I added inital schema of basedn "dc=stack,dc=com" which caused issues during replication when producer container was up and running
I had mounted volume to /bitnami/openldap to have persistent storage for LDAP DB, however it also persisted configurations which caused issues when I created new container images with different configurations for debugging.

Now as I was able to perform proper producer-consumer replication I would like to document the steps which I performed so that any novice user like me who will be using bitnami openldap in future would be able to set up SyncReplication successfully

I would like to contribute to the documentation with detailed steps for setting up LDAP Synchronization @SidneySun @carrodher is there any reference document or PR which I can refer to document the steps?

Nov 21 '24 10:11 rohan-97

@rohan-97 that is great news. Are you able to put your current documented steps within the comments section? I would be more than happy to sense check the steps.

Nov 21 '24 10:11 cpowell-gresham

OpenLDAP Sync Replication

Here we are implementing Producer-Consumer Sync replication of Bitnami based OpenLDAP servers Details of documentation of sync replication can be found here

Details of bitnami openldap container repository can be found here

We are setting up two debian linux machines which has docker installed and will set up sync-replication between them

Setup Producer Node

Install docker on the system

Following page can be refered to set up docker on debian

Prepare bitnami openldap container image with some database

create following file as database.ldif

root@producer-ip-10-31-1-84:~# cat /root/producer/database.ldif
dn: dc=stack,dc=com
description: stack.com, your trusted non-existent corporation.
dc: stack
o: stack.com
objectClass: top
objectClass: dcObject
objectClass: organization

# Subtree for users
dn: ou=Users,dc=stack,dc=com
ou: Users
description: stack.com Users
objectClass: organizationalUnit

# Subtree for groups
dn: ou=Groups,dc=stack,dc=com
ou: Groups
description: stack.com Groups
objectClass: organizationalUnit

# Subtree for system accounts
dn: ou=System,dc=stack,dc=com
ou: System
description: Special accounts used by software applications
objectClass: organizationalUnit

# Barbara Jensen
dn: uid=barbara,ou=Users,dc=stack,dc=com
ou: Users
uid: Barbara
sn: Jensen
cn: Barbara Jensen
givenName: Barbara
displayName: Barbara Jensen
mail: [email protected]
userPassword: barbara@1234
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# Matt Butcher
dn: uid=matt,ou=Users,dc=stack,dc=com
ou: Users
# Name info:
uid: Matt
cn: Matt Butcher
sn: Butcher
givenName: Matt
givenName: Matthew
displayName: Matt Butcher
# Work Info:
title: Systems Integrator
description: Systems Integration and IT for Example.Com
employeeType: Employee
departmentNumber: 001
employeeNumber: 001-08-98
mail: [email protected]
mail: [email protected]
roomNumber: 301
telephoneNumber: +1 555 555 4321
mobile: +1 555 555 6789
st: Illinois
l: Chicago
street: 1234 Cicero Ave.
# Home Info:
homePhone: +1 555 555 9876
homePostalAddress: 1234 home street $ Chicago, IL $ 60699-1234
# Misc:
userPassword: matt@1234
preferredLanguage: en-us,en-gb
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# LDAP Admin Group:
dn: cn=LDAP Admins,ou=Groups,dc=stack,dc=com
cn: LDAP Admins
ou: Groups
description: Users who are LDAP administrators
uniqueMember: uid=barbara,dc=stack,dc=com
uniqueMember: uid=matt,dc=stack,dc=com
uniqueMember: uid=syncrepl,ou=System,dc=stack,dc=com
objectClass: groupOfUniqueNames

# Special Account for Authentication:
dn: uid=authenticate,ou=System,dc=stack,dc=com
uid: authenticate
ou: System
description: Special account for authenticating users
userPassword: secret
objectClass: account
objectClass: simpleSecurityObject

# Special Account for Authentication:
dn: uid=syncrepl,ou=System,dc=stack,dc=com
uid: syncrepl
ou: System
description: Special account for syncrepl
userPassword: secret
objectClass: account
objectClass: simpleSecurityObject

Create another docker image to load above database schema

cat /root/producer/Dockerfile
FROM bitnami/openldap:2.6.8

COPY database.ldif /ldifs/

Then execute following command to build conatainer image

root@consumer-ip-10-31-1-244:~/consumer# cat /root/consumer/Dockerfile
FROM bitnami/openldap:2.5.13-debian-11-r26

COPY ./syncrepl.ldif /opt/bitnami/openldap/etc/schema/

Spin up LDAP container

Below command spins up LDAP container using our cutom image and maps port 1389 to host machine so that LDAP can be accessed from current node and outside environment as well

docker run -d -p 1389:1389 -e BITNAMI_DEBUG="true"       -e LDAP_ADMIN_USERNAME="superuser"  -e LDAP_BINDDN="uid=syncrepl,ou=system,dc=stack,dc=com"       -e LDAP_ENABLE_SYNCPROV="yes"   -e LDAP_ENABLE_TLS="no"      -e LDAP_LOGLEVEL="any"  -e LDAP_ROOT="dc=stack,dc=com"     -e LDAP_SKIP_DEFAULT_TREE="yes"     -e LDAP_SYNCPROV_CHECKPPOINT="50 5"     -e LDAP_URI="ldap://localhost"       -e USER_DESCRIPTION_MAX_LEN="100" -e LDAP_ADMIN_PASSWORD="admin123"  -e LDAP_READONLY_USER_PASSWORD="admin123"   -e USER_FIRST_AND_LAST_NAME_MAX_LEN="100"       -e USER_NAME_MAX_LEN="100"  -it customldap:latest

and use docker ps command to verify whether LDAP container is running properly or not

root@producer-ip-10-31-1-84:~/producer# docker ps
CONTAINER ID   IMAGE               COMMAND                  CREATED         STATUS         PORTS                                                 NAMES
15f48ecc7566   customldap:latest   "/opt/bitnami/script…"   4 minutes ago   Up 4 minutes   0.0.0.0:1389->1389/tcp, :::1389->1389/tcp, 1636/tcp   strange_elgamal

Producer LDAP verification

You can verify whether Producer LDAP is up and running

ldapsearch -H ldap://localhost:1389 -b "dc=stack,dc=com" -D "uid=syncrepl,ou=system,dc=stack,dc=com" -w secret

And following should be the output

root@producer-ip-10-31-1-84:~/producer# ldapsearch -H ldap://localhost:1389 -b "dc=stack,dc=com" -D "uid=syncrepl,ou=system,dc=stack,dc=com" -w secret
# extended LDIF
#
# LDAPv3
# base <dc=stack,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# stack.com
dn: dc=stack,dc=com
description: stack.com, your trusted non-existent corporation.
dc: stack
o: stack.com
objectClass: top
objectClass: dcObject
objectClass: organization

# Users, stack.com
dn: ou=Users,dc=stack,dc=com
ou: Users
description: stack.com Users
objectClass: organizationalUnit

# Groups, stack.com
dn: ou=Groups,dc=stack,dc=com
ou: Groups
description: stack.com Groups
objectClass: organizationalUnit

# System, stack.com
dn: ou=System,dc=stack,dc=com
ou: System
description: Special accounts used by software applications
objectClass: organizationalUnit

# barbara, Users, stack.com
dn: uid=barbara,ou=Users,dc=stack,dc=com
ou: Users
uid: Barbara
sn: Jensen
cn: Barbara Jensen
givenName: Barbara
displayName: Barbara Jensen
mail: [email protected]
userPassword:: YmFyYmFyYUAxMjM0
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson                                                                                                                                                                                       
# matt, Users, stack.com
dn: uid=matt,ou=Users,dc=stack,dc=com
ou: Users
uid: Matt
cn: Matt Butcher
sn: Butcher
givenName: Matt
givenName: Matthew
displayName: Matt Butcher
title: Systems Integrator
description: Systems Integration and IT for Example.Com
employeeType: Employee
departmentNumber: 001
employeeNumber: 001-08-98
mail: [email protected]
mail: [email protected]
roomNumber: 301
telephoneNumber: +1 555 555 4321
mobile: +1 555 555 6789
st: Illinois
l: Chicago
street: 1234 Cicero Ave.
homePhone: +1 555 555 9876
homePostalAddress: 1234 home street $ Chicago, IL $ 60699-1234
userPassword:: bWF0dEAxMjM0
preferredLanguage: en-us,en-gb
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# LDAP Admins, Groups, stack.com
dn: cn=LDAP Admins,ou=Groups,dc=stack,dc=com
cn: LDAP Admins
ou: Groups
description: Users who are LDAP administrators
uniqueMember: uid=barbara,dc=stack,dc=com
uniqueMember: uid=matt,dc=stack,dc=com
uniqueMember: uid=syncrepl,ou=System,dc=stack,dc=com
objectClass: groupOfUniqueNames

# authenticate, System, stack.com
dn: uid=authenticate,ou=System,dc=stack,dc=com
uid: authenticate
ou: System
description: Special account for authenticating users
userPassword:: c2VjcmV0
objectClass: account
objectClass: simpleSecurityObject

# syncrepl, System, stack.com
dn: uid=syncrepl,ou=System,dc=stack,dc=com
uid: syncrepl
ou: System
description: Special account for syncrepl
userPassword:: c2VjcmV0
objectClass: account
objectClass: simpleSecurityObject

# search result
search: 2
result: 0 Success

# numResponses: 10
# numEntries: 9

Setup Consumer Node

Install docker on the system

Following page can be refered to set up docker on debian

Setup Syncrepl ldif configuration

root@consumer-ip-10-31-1-244:~/consumer# cat /root/consumer/syncrepl.ldif
dn: cn=config
changeType: modify
add: olcServerID
olcServerID: 001

dn: olcDatabase={2}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncrepl: rid=001
        provider=ldap://10.31.1.84:1389
        bindmethod=simple
        timeout=0
        network-timeout=0
    binddn="uid=syncrepl,ou=System,dc=stack,dc=com"
    credentials="secret"
        keepalive=0:0:0
        tcp-user-timeout=0
        starttls=no
        filter="(objectclass=*)"
        searchbase="dc=stack,dc=com"
        scope=sub
        schemachecking=off
        type=refreshOnly
        interval=00:00:05:00
        retry=undefined
-
add: olcUpdateRef
olcUpdateRef: ldap://10.31.1.84:1389

Note: IP address of producer LDAP server node is 10.31.1.84
Please replace 10.31.1.84 with ip address of corresponding producer node

Prepare container image to include syncrepl ldif file

root@consumer-ip-10-31-1-244:~/consumer# cat /root/consumer/Dockerfile
FROM bitnami/openldap:2.5.13-debian-11-r26

COPY ./syncrepl.ldif /opt/bitnami/openldap/etc/schema/

Execute following command to build docker image

docker build -t consumerldap:latest .

Create container out of cutom container image

Execute following command to generate container image which loads our custom syncprov.ldif configuration and also maps port 1386 with host system so that ldap server is accessible from host machine and outside machines as well

docker run -d -p 1389:1389 -e BITNAMI_DEBUG="true"       -e LDAP_ADMIN_USERNAME="superuser"  -e LDAP_BINDDN="uid=syncrepl,ou=system,dc=stack,dc=com"    -e LDAP_ENABLE_TLS="no" -e LDAP_EXTRA_SCHEMAS="cosine,general-acl,ppolicy,nis,inetorgperson,syncrepl"      -e LDAP_LOGLEVEL="any"  -e LDAP_ROOT="dc=stack,dc=com"     -e LDAP_SKIP_DEFAULT_TREE="yes"     -e LDAP_URI="ldap://localhost"       -e USER_DESCRIPTION_MAX_LEN="100" -e LDAP_ADMIN_PASSWORD="admin123"  -e LDAP_READONLY_USER_PASSWORD="admin123"   -e USER_FIRST_AND_LAST_NAME_MAX_LEN="100"       -e USER_NAME_MAX_LEN="100"  -it consumerldap:latest

Consumer LDAP verification

You can verify whether Consumer LDAP is synchronized with producer using following below command

ldapsearch -H ldap://localhost:1389 -b "dc=stack,dc=com" -D "uid=syncrepl,ou=system,dc=stack,dc=com" -w secret

You should get following output

root@consumer-ip-10-31-1-244:~# ldapsearch -H ldap://localhost:1389 -b "dc=stack,dc=com" -D "uid=syncrepl,ou=system,dc=stack,dc=com" -w secret
# extended LDIF
#
# LDAPv3
# base <dc=stack,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# stack.com
dn: dc=stack,dc=com
description: stack.com, your trusted non-existent corporation.
dc: stack
o: stack.com
objectClass: top
objectClass: dcObject
objectClass: organization

# Users, stack.com
dn: ou=Users,dc=stack,dc=com
ou: Users
description: stack.com Users
objectClass: organizationalUnit

# Groups, stack.com
dn: ou=Groups,dc=stack,dc=com
ou: Groups
description: stack.com Groups
objectClass: organizationalUnit

# System, stack.com
dn: ou=System,dc=stack,dc=com
ou: System
description: Special accounts used by software applications
objectClass: organizationalUnit

# barbara, Users, stack.com
dn: uid=barbara,ou=Users,dc=stack,dc=com
ou: Users
uid: Barbara
sn: Jensen
cn: Barbara Jensen
givenName: Barbara
displayName: Barbara Jensen
mail: [email protected]
userPassword:: YmFyYmFyYUAxMjM0
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# matt, Users, stack.com
dn: uid=matt,ou=Users,dc=stack,dc=com
ou: Users
uid: Matt
cn: Matt Butcher
sn: Butcher
givenName: Matt
givenName: Matthew
displayName: Matt Butcher
title: Systems Integrator
description: Systems Integration and IT for Example.Com
employeeType: Employee
departmentNumber: 001
employeeNumber: 001-08-98
mail: [email protected]
mail: [email protected]
roomNumber: 301
telephoneNumber: +1 555 555 4321
mobile: +1 555 555 6789
st: Illinois
l: Chicago
street: 1234 Cicero Ave.
homePhone: +1 555 555 9876
homePostalAddress: 1234 home street $ Chicago, IL $ 60699-1234
userPassword:: bWF0dEAxMjM0
preferredLanguage: en-us,en-gb
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# LDAP Admins, Groups, stack.com
dn: cn=LDAP Admins,ou=Groups,dc=stack,dc=com
cn: LDAP Admins
ou: Groups
description: Users who are LDAP administrators
uniqueMember: uid=barbara,dc=stack,dc=com
uniqueMember: uid=matt,dc=stack,dc=com
uniqueMember: uid=syncrepl,ou=System,dc=stack,dc=com
objectClass: groupOfUniqueNames

# authenticate, System, stack.com
dn: uid=authenticate,ou=System,dc=stack,dc=com
uid: authenticate
ou: System
description: Special account for authenticating users
userPassword:: c2VjcmV0
objectClass: account
objectClass: simpleSecurityObject

# syncrepl, System, stack.com
dn: uid=syncrepl,ou=System,dc=stack,dc=com
uid: syncrepl
ou: System
description: Special account for syncrepl
userPassword:: c2VjcmV0
objectClass: account
objectClass: simpleSecurityObject

# search result
search: 2
result: 0 Success

# numResponses: 10
# numEntries: 9

Verifying LDAP replication

Trying to perform write opearation on Consumer LDAP

Add below file on consumer server

root@consumer-ip-10-31-1-244:~/consumer# cat /root/consumer/custom.ldif
# batman, Users, stack.com
dn: uid=batman,ou=Users,dc=stack,dc=com
ou: Users
uid: Batman
sn: Wayne
cn: Batman Wayne
givenName: Batman
displayName: Batman Wayne
mail: [email protected]
userPassword:: YmFyYmFyYUAxMjM0
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

Execute following command to apply ldif file to database

ldapadd -H 'ldap://localhost:1389' -D "cn=superuser,dc=stack,dc=com" -w "admin123" -f /root/consumer/custom.ldif

You should get following output

root@consumer-ip-10-31-1-244:~# ldapadd -H 'ldap://localhost:1389' -D "cn=superuser,dc=stack,dc=com" -w "admin123" -f /root/consumer/custom.ldif
adding new entry "uid=batman,ou=Users,dc=stack,dc=com"
ldap_add: Referral (10)
        referrals:
                ldap://10.31.1.84:1389/uid=batman,ou=Users,dc=stack,dc=com

This denotes that consumer LDAP is read only and we cannot perform write operation on consumer LDAP

Trying to perform write opearation on Producer LDAP

Add below file on producer server

root@producer-ip-10-31-1-84:~/producer# cat /root/producer/custom.ldif
# batman, Users, stack.com
dn: uid=batman,ou=Users,dc=stack,dc=com
ou: Users
uid: Batman
sn: Wayne
cn: Batman Wayne
givenName: Batman
displayName: Batman Wayne
mail: [email protected]
userPassword:: YmFyYmFyYUAxMjM0
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

Execute following command to apply ldif file to database

ldapadd -H 'ldap://localhost:1389' -D "cn=superuser,dc=stack,dc=com" -w "admin123" -f /root/producer/custom.ldif

You should get following output

root@producer-ip-10-31-1-84:~/producer# ldapadd -H 'ldap://localhost:1389' -D "cn=superuser,dc=stack,dc=com" -w "admin123" -f /root/producer/custom.ldif
adding new entry "uid=batman,ou=Users,dc=stack,dc=com"

This denotes that we can perform write operations on producer LDAP

After changes done in producer LDAP, the changes should be reflected on consumer LDAP as well after some time.

Following is the output on executing ldapsearch on consumer server

root@consumer-ip-10-31-1-244:~/consumer# ldapsearch -H ldap://localhost:1389 -b "dc=stack,dc=com" -D "uid=syncrepl,ou=system,dc=stack,dc=com" -w secret
# extended LDIF
#
# LDAPv3
# base <dc=stack,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# stack.com
dn: dc=stack,dc=com
description: stack.com, your trusted non-existent corporation.
dc: stack
o: stack.com
objectClass: top
objectClass: dcObject
objectClass: organization

# Users, stack.com
dn: ou=Users,dc=stack,dc=com
ou: Users
description: stack.com Users
objectClass: organizationalUnit

# Groups, stack.com
dn: ou=Groups,dc=stack,dc=com
ou: Groups
description: stack.com Groups
objectClass: organizationalUnit

# System, stack.com
dn: ou=System,dc=stack,dc=com
ou: System
description: Special accounts used by software applications
objectClass: organizationalUnit

# barbara, Users, stack.com
dn: uid=barbara,ou=Users,dc=stack,dc=com
ou: Users
uid: Barbara
sn: Jensen
cn: Barbara Jensen
givenName: Barbara
displayName: Barbara Jensen
mail: [email protected]
userPassword:: YmFyYmFyYUAxMjM0
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# matt, Users, stack.com
dn: uid=matt,ou=Users,dc=stack,dc=com
ou: Users
uid: Matt
cn: Matt Butcher
sn: Butcher
givenName: Matt
givenName: Matthew
displayName: Matt Butcher
title: Systems Integrator
description: Systems Integration and IT for Example.Com
employeeType: Employee
departmentNumber: 001
employeeNumber: 001-08-98
mail: [email protected]
mail: [email protected]
roomNumber: 301
telephoneNumber: +1 555 555 4321
mobile: +1 555 555 6789
st: Illinois
l: Chicago
street: 1234 Cicero Ave.
homePhone: +1 555 555 9876
homePostalAddress: 1234 home street $ Chicago, IL $ 60699-1234
userPassword:: bWF0dEAxMjM0
preferredLanguage: en-us,en-gb
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# LDAP Admins, Groups, stack.com
dn: cn=LDAP Admins,ou=Groups,dc=stack,dc=com
cn: LDAP Admins
ou: Groups
description: Users who are LDAP administrators
uniqueMember: uid=barbara,dc=stack,dc=com
uniqueMember: uid=matt,dc=stack,dc=com
uniqueMember: uid=syncrepl,ou=System,dc=stack,dc=com
objectClass: groupOfUniqueNames

# authenticate, System, stack.com
dn: uid=authenticate,ou=System,dc=stack,dc=com
uid: authenticate
ou: System
description: Special account for authenticating users
userPassword:: c2VjcmV0
objectClass: account
objectClass: simpleSecurityObject

# syncrepl, System, stack.com
dn: uid=syncrepl,ou=System,dc=stack,dc=com
uid: syncrepl
ou: System
description: Special account for syncrepl
userPassword:: c2VjcmV0
objectClass: account
objectClass: simpleSecurityObject

# batman, Users, stack.com
dn: uid=batman,ou=Users,dc=stack,dc=com
ou: Users
uid: Batman
sn: Wayne
cn: Batman Wayne
givenName: Batman
displayName: Batman Wayne
mail: [email protected]
userPassword:: YmFyYmFyYUAxMjM0
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

# search result
search: 2
result: 0 Success

# numResponses: 11
# numEntries: 10

I referred following blog for setting up producer-consumer ldap synchronization

Nov 21 '24 13:11 rohan-97

@SidneySun @carrodher I think we should treat this issue as a documentation bug and keep it open until above steps are properly documented

Do let me know if any PR needs to be raised to document above steps

Nov 21 '24 13:11 rohan-97

Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

Nov 26 '24 10:11 carrodher

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Dec 12 '24 01:12 github-actions[bot]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Dec 29 '24 01:12 github-actions[bot]

I think it has very problematic side: Each time you rotate credentials for consumer you have to rebuild image, it is not optimal. Is there any intention for bitnami team to give an option to mount slapd.d directory inside the container so bitnami container will start with pre-built configuration, as right now, i understand container creates configuration on the fly each time it starts. Correct ?

Dec 29 '24 16:12 nix-power

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Jan 15 '25 01:01 github-actions[bot]

已收到您的邮件。(自动回复)

Jan 15 '25 01:01 cfxccn

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Jan 31 '25 01:01 github-actions[bot]

已收到您的邮件。(自动回复)

Jan 31 '25 01:01 cfxccn

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Feb 16 '25 01:02 github-actions[bot]

已收到您的邮件。(自动回复)

Feb 16 '25 01:02 cfxccn

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Mar 04 '25 01:03 github-actions[bot]

已收到您的邮件。(自动回复)

Mar 04 '25 01:03 cfxccn

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Mar 20 '25 01:03 github-actions[bot]

已收到您的邮件。(自动回复)

Mar 20 '25 01:03 cfxccn

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

Apr 06 '25 01:04 github-actions[bot]

[bitnami/openldap] Steps for setting up consumer for syncrepl

Name and Version

What architecture are you using?

What steps will reproduce the bug?

What do you see instead?

producer debian slapd.conf

consumer debian slapd.conf

OpenLDAP Sync Replication

Setup Producer Node

Install docker on the system

Prepare bitnami openldap container image with some database

Create another docker image to load above database schema

Spin up LDAP container

Producer LDAP verification

Setup Consumer Node

Install docker on the system

Setup Syncrepl ldif configuration

Prepare container image to include syncrepl ldif file

Create container out of cutom container image

Consumer LDAP verification

Verifying LDAP replication

Trying to perform write opearation on Consumer LDAP

Trying to perform write opearation on Producer LDAP