OpenLDAP MirrorMode Replication & MDB Backend in CentOS 7

In this tutorial, We will show MirrorMode replication between 2 CentOS 7 servers who’s backend is mdb. We will also setup mdb backend for our OpenLDAP storage.

OPENLDAP

OpenLDAP is a free, open-source implementation of the Lightweight Directory Access Protocol (LDAP) developed by the OpenLDAP Project. LDAP is known as Lightweight Directory Access Protocol which is generally used for Client Authentication to establish a session for running operations like search, read, write etc. LDAP Server are widely used in the Organizations to store the User name and password in a Centralized Server against which User can authenticate to further use the Applications and Services present on the Network. It is mainly based on X.500 directory services architecture. Over the time it is modified and upgraded to the lightweight version to improve the lookup up response time, hence it is called Lightweight Directory Access Protocol.

Components
OpenLDAP has three main components:

• slapd – stand-alone LDAP daemon and associated modules and tools
• libraries implementing the LDAP protocol and ASN.1 Basic Encoding Rules (BER)
• client software: ldapsearch, ldapadd, ldapdelete, and others

What is LDIF
A LDIF(LDAP Interchange Format) file is Known as a standard text file which can be used for configuring and storing information in LDAP directory. This file is usually used for the addition or modification of data inside the LDAP Directory Server based on Schema rules accepted by the Directory.

What is an Attribute
An attribute is like a variable which holds the value. It can be different types based on the different values it holds just like the variable in Programming Paradigms where it could be of type int, char, float, double etc.

Backends
Historically the OpenLDAP server (slapd, the Standalone LDAP Daemon) architecture was split between a frontend which handles network access and protocol processing, and a backend which deals strictly with data storage.

Available backends
Data storage backends – these actually store data.

• back-bdb: the first transactional backend for OpenLDAP, built on Berkeley DB
• back-hdb: a variant of back-bdb that is fully hierarchical and supports subtree renames
• back-ldif: built on plain text LDIF files
• back-mdb: a transactional backend built on OpenLDAP’s Lightning Memory-Mapped Database (LMDB)
• back-ndb: a transactional backend built on MySQL’s NDB cluster engine.

Overlays

Overall concept
Ordinarily an LDAP request is received by the frontend, decoded, and then passed to a backend for processing. When the backend completes a request, it returns a result to the frontend, which then sends the result to the LDAP client. An overlay is a piece of code that can be inserted between the frontend and the backend. It is thus able to intercept requests and trigger other actions on them before the backend receives them, and it can also likewise act on the backend’s results before they reach the frontend. Overlays have complete access to the slapd internal APIs, and so can invoke anything the frontend or other backends could perform. Multiple overlays can be used at once, forming a stack of modules between the frontend and the backend.
E.g syncprov: Syncrepl Provider, implements the master side of a replication agreement.

cn=config Overview

Historically OpenLDAP has been statically configured, that is, to make a change to the configuration the slapd.conf file was modified and slapd stopped and started. In the case of larger users this could take a considerable period of time and had become increasingly unacceptable as an operational method. OpenLDAP version 2.3 introduced an optional new feature whereby configuration may be performed at run-time using a DIT entry called cn=config. The feature is known by a varied and confusing number of terms including on-line configuration (OLC) (our favorite), zero down-time configuration, cn=config and slapd.d configuration. First, a number of points:

1. The feature is (at version 2.4) still optional which means that slapd.conf, while formally deprecated, continues to work though many *nix distributions have made it the default installation configuration.

2. OpenLDAP has a history of being quite brutal about withdrawing support of older capabilities. This means that migration to on-line configuration (OLC, cn=config) should be contemplated as soon as practical. Better to do it when you don’t need the new release than to be forced to take a new release because of a critical bug AND have to migrate to the new configration regime.

3. on-line configuration (OLC) uses a configuration DIT (with a hardcoded suffix of cn=config) to control the operational configuration. Conceptually by modifying entries in this DIT (using an LDAP Browser or LDIF files) immediate changes to slapd’s operational behaviour are triggered without having to restart slapd as you would after making changes to slapd.conf.

OLC (cn=config) Layout

The OLC (cn=config) DIT is laid out as shown below:

NOTES:

1. The cn=config (root) is based on the olcGlobal objectClass and contains the global attributes affecting the operation of slapd. It contains global configuration settings.
2. The cn=module{Z},cn=config is based on the olcModuleList objectClass and contains a list of all dynamically loaded objects and their paths.
3. The cn=schema,cn=config entry uses the olcSchemaConfig objectclass and contains all the objects used by the cn=config system.
4. The cn={Z}xxx,cn=schema,cn=config child entry uses the olcSchemaConfig objectclass and contains all the objects (attributes and objectclasses) defined by the specific schema. The value {Z} is a numeric count starting from 0 and xxxx is the name of the schema. Thus, if the first included schema is core.schema then this value would be {0}core.
5. The olcDatabase={Z}xxx,cn=config entry (5) uses the olcDatabaseConfig objectclass (which contains all the general attributes defined for a database) plus a database type specific objectclass. The value {Z} is a numeric count starting from 0 and xxxx is the database type name.
6. The olcOverlay={Z}xxx,olcDatabase={Z}xxx,cn=config entry (6) uses the olcOverlayConfig objectclass all the general attributes defined for an overlay plus a overlay specific objectclass.

To create the OLC (cn=config) DIT you can EITHER create a series of LDIF files that describe the configuration and apply them using slapadd or ldapadd.

OPENLDAP Setup

prerequisites

1. The servers must be able to lookup each others
2. Install and configure NTP on both servers

We will replicate LDAP between 2 servers. so first edit /etc/hosts file of both servers to add entry of each other.

vim /etc/hosts
172.16.0.98 ldap1.bidhankhatri.com.np srv-01
172.16.0.99 ldap2.bidhankhatri.com.np srv-02

Sync Time

Sync Time between both servers.

yum install chrony
systemctl start chronyd
systemctl enable chronyd

[root@srv-01 ~]# timedatectl
      Local time: Thu 2021-04-22 17:01:30 +0545
  Universal time: Thu 2021-04-22 11:16:30 UTC
        RTC time: Thu 2021-04-22 10:02:06
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: n/a

Install openldap package

Download openldap packages on both servers.

yum install openldap-servers openldap-clients
systemctl start slapd
systemctl enable slapd

Required LDAP Server attributes

OpenLDAP servers configuration files are found in /etc/openldap/slapd.d/. To start with the configuration of LDAP, we would need to update the variables "olcSuffix" and "olcRootDN".

olcSuffix – Database Suffix, it is the domain name for which the LDAP server provides the information. In simple words, it should be changed to your domain name.
olcRootDN – Root Distinguished Name (DN) entry for the user who has the unrestricted access to perform all administration activities on LDAP, like a root user.
olcRootPW – LDAP admin password for the above RootDN.

The above entries need to be updated in /etc/openldap/slapd.d/cn=config/olcDatabase={x}XXX.ldif file. Manually edit of LDAP configuration is not recommended as you will lose changes whenever you run ldapmodify command.

Backends

Backends do the actual work of storing or retrieving data in response to LDAP requests. The hdb backend to slapd is a backend for a normal slapd database. It uses the Oracle Berkeley DB (BDB) package to store data. It makes extensive use of indexing and caching to speed data access. hdb is a variant of the original bdb backend which was first written for use with BDB. hdb uses a hierarchical database layout which supports subtree renames. It is otherwise identical to the bdb behavior, and all the same configuration options apply.

mdb backend
It is the recommended primary backend for a normal slapd database. It uses OpenLDAP’s own Lightning Memory-Mapped Database (LMDB) library to store data and is intended to replace the Berkeley DB backends. It supports indexing like the BDB backends, but it uses no caching and requires no tuning to deliver maximum search performance. In addition to the usual parameters that a minimal configuration requires, the mdb backend requires a maximum size to be set. This should be the largest that the database is ever anticipated to grow (in bytes).

Why mdb?

• Performance: mdb is better in performance than hdb. It is at least 2 times faster loading the data than hdb.
• Databae size: mdb is 2.11 times smaller than the hdb database.
• write performance: mdb is 51 times faster than hdb.

In CentOS 7, If you install the openldap-servers package, you have already three databases and the default database back-end is not mdb but the deprecated hdb.
To verify execute below command.

ldapsearch -Y EXTERNAL -Q -H ldapi:/// -LLL -o ldif-wrap=no -b cn=config '(objectClass=olcDatabaseConfig)' ''
dn: olcDatabase={-1}frontend,cn=configs
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}monitor,cn=config
dn: olcDatabase={2}hdb,cn=config

Therefore, we will be using mdb as our openldap backend in our CentOS 7 servers.

The Berkeley Database backend retrieves most of its configuration and tuning options from the DB_CONFIG file. Copy the sample database configuration file to LDAP data directory /var/lib/ldap and update the file permissions.

[root@srv-01 ~]# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
[root@srv-01 ~]# chown ldap: /var/lib/ldap/*

Generate LDAP Admin Password

Setup LDAP Admin Password. Execute below command and type new password for ldap admin. slappasswd command will generate an encrypted hash of entered password which you need to use in LDAP configuration file. So make a note of this and keep it aside.

slappasswd

New password:
Re-enter new password:
{SSHA}cdScDk18A5c5odB+kwRgqDizzNEE5sMB

Configure the Mdb Database

You need to configure a database before adding entries. The OpenLDAP developers recommend using the MDB back end. By default, MDB limits the size of the database to 10MB. You can change this by adding the olcDbMaxSize attribute; specify the max size in bytes. If it reaches the maximum, you will not be able to add new entries. For this reason, monitor the size of your database directory and be generous with the limit you set. A good rule of thumb is 3MB per 1000 entires. create a db.ldif file and copy the hashed output which was generated before and place here in olcRootPW attribute.

Now, create your database by creating the following LDIF file and loading it.

vim db.ldif

dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=bidhankhatri,dc=com,dc=np
olcRootDN: cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np
olcRootPW: {SSHA}cdScDk18A5c5odB+kwRgqDizzNEE5sMB
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
olcLastMod: TRUE
olcDbEnvFlags: nometasync
olcDbEnvFlags: writemap
olcDbMaxSize: 9048576000

Add the database.

[root@srv-01 prod]# ldapadd -Y EXTERNAL -H ldapi:/// -f db.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase=mdb,cn=config"

-Y : Specify the SASL mechanism to be used for authentication. If it’s not specified, the program will choose the best mechanism the server knows.
-H : Specify URI(s) referring to the ldap server(s) only the protocol/host/port fields are allowed.
-f : Read the entry modification information from file instead of from standard input.

Import basic Schemas

[root@srv-01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
[root@srv-01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
[root@srv-01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif

check through slaptest command. output should be like below.

[root@srv-01 ~]# slaptest
config file testing succeeded

if you get hdb_db_open error then you can ignore that error for now as we are not using hdb backend. That error will go in next slaptest command.

DIT config tree

Since openldap version 2.3 (released in 2005), the actual configuration for OpenLDAP servers is managed within a special database (DIT), typically rooted at the cn=config entry. This configuration system is known as OpenLDAP online configuration, or OLC.
After the initial installation, the config tree will typically look something like this:

[root@srv-01 ~]# ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" '(objectClass=*)' dn -LLL
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}monitor,cn=config
dn: olcDatabase={2}hdb,cn=config
dn: olcDatabase={3}mdb,cn=config

• the cn=config root entry contains global settings.
• cn=schema,cn=config contains the built-in system schema definitions with user schema as child entries.
• the olcDatabase={-1}frontend,cn=config entry contains further global settings (but ones which might affect or be affected by dynamically loadable modules)
• the remaining olcDatabase={id}type,cn=config entries contain per-database settings.

Define Domain Configuration

Check Database Suffix: To check the database suffix, once the server is running, use ldapsearch to read the namingContexts attribute of the root DSE:

[root@srv-01 prod]# ldapsearch -x -LLL -s base -b "" namingContexts
dn:
namingContexts: dc=my-domain,dc=com
namingContexts: dc=bidhankhatri,dc=com,dc=np

verify ROOT DN Passwords

Verify the root DN password of each database you are replicating. The following command will output a list of databases, their root DNs, and if they have passwords.

[root@srv-01 prod]# slapcat -n 0 -a '(olcRootDN=*)' | egrep '^dn:|olcRootDN|olcRootPW'
dn: olcDatabase={2}hdb,cn=config
olcRootDN: cn=Manager,dc=my-domain,dc=com
dn: olcDatabase={3}mdb,cn=config
olcRootDN: cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np
olcRootPW:: e1NTSEF9Y2RTY0RrMThBNWM1b2RCK2t3UmdxRGl6ek5FRTVzTUI=

verify your database setup

[root@srv-01 prod]# ldapsearch -H ldapi:/// -Y EXTERNAL -b "olcDatabase={3}mdb,cn=config"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <olcDatabase={3}mdb,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# {3}mdb, config
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {3}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=bidhankhatri,dc=com,dc=np
olcLastMod: TRUE
olcRootDN: cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np
olcRootPW: {SSHA}cdScDk18A5c5odB+kwRgqDizzNEE5sMB
olcDbEnvFlags: nometasync
olcDbEnvFlags: writemap
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
olcDbMaxSize: 9048576000

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

As you can see, there is one DB configured: dn: olcDatabase={3}mdb,cn=config. In this database, you can see a domain database configured which has its data stored in /var/lib/ldap. You can also see the mdb backend database size which we defined earlier. It’s 8.5G capacity.

[root@srv-01 ~]# ll -h /var/lib/ldap/*mdb
-rw------- 1 ldap ldap 8.5G Apr 29 17:29 /var/lib/ldap/data.mdb

If you set your mdb database in default size which is 10MB limit and later when your mdb database gets full while adding new users you might get error like below.

mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)

that means your mdb database is full and now you have to increase your olcDbMaxSize value to add new users.
Step 1: Create ldif file(change_mdb_size.ldif) with below contents

dn: olcDatabase={3}mdb,cn=config
changetype: modify
replace: olcDbMaxSize
olcDbMaxSize: 900000

Note : olcDbMaxSize : size in bytes

Step 2: Import above ldif file to OpenLDAP

[root@srv-01 prod]# ldapmodify -Y EXTERNAL -H ldapi:/// -f change_mdb_size.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={3}mdb,cn=config"

That’s it.

Now again back to our ldap configuration.

Control monitor access

Make a changes to /etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif (Do not edit manually) file to restrict the monitor access only to ldap root (ldapadmin) user not to others.

vim monitor.ldif

dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" read by dn.base="cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np" read by * none

Once you have updated the file, send the configuration to the LDAP server.

[root@srv-01 ~]# ldapmodify -Y EXTERNAL  -H ldapi:/// -f monitor.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={1}monitor,cn=config"

Add entries to domain.

Generate basedomain.ldif file for your domain.

vim basedomain.ldif

dn: dc=bidhankhatri,dc=com,dc=np
dc: bidhankhatri
objectClass: top
objectClass: domain

dn: cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np
objectClass: organizationalRole
cn: ldapadmin
description: LDAP Manager

dn: ou=People,dc=bidhankhatri,dc=com,dc=np
objectClass: organizationalUnit
ou: People

dn: ou=Group,dc=bidhankhatri,dc=com,dc=np
objectClass: organizationalUnit
ou: Group

Build the directory structure. Place LDAP Root Password when promt you for the password.

[root@srv-01 ~]# ldapadd -x -W -D "cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np" -f basedomain.ldif
Enter LDAP Password: 
adding new entry "dc=bidhankhatri,dc=com,dc=np"

adding new entry "cn=ldapadmin ,dc=bidhankhatri,dc=com,dc=np"

adding new entry "ou=People,dc=bidhankhatri,dc=com,dc=np"

adding new entry "ou=Group,dc=bidhankhatri,dc=com,dc=np"

check what databases are configured on the system:

[root@srv-01 ~]# ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config" '(objectClass=*)' dn -LLL
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}monitor,cn=config
dn: olcDatabase={2}hdb,cn=config
dn: olcDatabase={3}mdb,cn=config

We have now configured openldap setup in server srv-01. Now do same steps in srv-02 server. After that we will start replication part.

Enable LDAP Logging
Configure Rsyslog to log LDAP events to log file /var/log/ldap.log.

echo "local4.* /var/log/ldap.log" >> /etc/rsyslog.conf
systemctl restart rsyslog

Replication - MirrorMode

Replication

Replicated directories are a fundamental requirement for delivering a resilient enterprise deployment. OpenLDAP has various configuration options for creating a replicated directory. OpenLDAP supports replication using Content Synchronization as specified in RFC 4533. This spec is hereafter referred to as “syncrepl”.

Replication alternatives:

1. Delta-syncrepl replication
2. N-Way Multi-Provider Replication
3. MirrorMode replication
4. Syncrepl Proxy Mode

Syncrepl has replaced slurpd in OpenLDAP for data replication.

MirrorMode Replication

MirrorMode is a hybrid configuration that provides all of the consistency guarantees of single-provider replication, while also providing the high availability of multi-provider. In MirrorMode two providers are set up to replicate from each other (as a multi-provider configuration), but an external frontend is employed to direct all writes to only one of the two servers. The second provider will only be used for writes if the first provider crashes, at which point the frontend will switch to directing all writes to the second provider. When a crashed provider is repaired and restarted it will automatically catch up to any changes on the running provider and resync.
You may find this page interesting.
https://www.openldap.org/doc/admin24/replication.html

Arguments for MirrorMode:

• Provides a high-availability (HA) solution for directory writes (replicas handle reads)
• As long as one provider is operational, writes can safely be accepted
• Provider nodes replicate from each other, so they are always up to date and can be ready to take over (hot standby)
• Syncrepl also allows the provider nodes to re-synchronize after any downtime

Arguments against MirrorMode:

• MirrorMode is not what is termed as a Multi-Provider solution. This is because writes have to go to just one of the mirror nodes at a time
• MirrorMode can be termed as Active-Active Hot-Standby, therefore an external server (slapd in proxy mode) or device (hardware load balancer) is needed to manage which provider is currently active.
• Backups are managed slightly differently. - If backing up the Berkeley database itself and periodically backing up the transaction log files, then the same member of the mirror pair needs to be used to collect logfiles until the next database backup is taken.

Enable syncprov module

We will enable the syncprov module first. Do it in both servers.

vim mod_syncprov.ldif

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib64/openldap
olcModuleLoad: syncprov.la

[root@srv-01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f mod_syncprov.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module,cn=config"

verify whether new module loaded or not.

[root@srv-01 ~]# slapcat -n 0 | grep olcModuleLoad
olcModuleLoad: {0}syncprov.la

Add syncprov overlay

The following LDIF will apply the overlay to the single mdb back end. Do it in both servers.

vim syncprov_overlay.ldif

dn: olcOverlay=syncprov,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpSessionLog: 100

Once you have created an LDIF for your overlays, add it to your configuration database with ldapadd

[root@srv-01 prod]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov_overlay.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcOverlay=syncprov,olcDatabase={3}mdb,cn=config"

Add Server IDs

Each cluster node needs a server ID. The server ID is an integer assigned to each node.The cn=config object needs an olcServerID attribute for each node.
We will define olcServerID 1 to srv-01 and olcServerID 2 to srv-02.

vim oclserverid.ldif

# create new
dn: cn=config
changetype: modify
replace: olcServerID
# specify uniq ID number on each server
olcServerID: 1

Execute above ldif file in srv-01 server.
Also, do same in srv-02 by replacing olcServerID to 2

[root@srv-01 ~]# ldapmodify -Y EXTERNAL -H ldapi:/// -f olcserverid.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

Configure The Databases For Replication

Now add the replication attributes to your database entries.

vim replication_config.ldif

dn: olcDatabase={3}mdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001
  provider=ldap://ldap02:389/
  bindmethod=simple
  binddn="cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np"
  credentials="helloworld123$"
  searchbase="dc=bidhankhatri,dc=com,dc=np"
  scope=sub
  schemachecking=on
  type=refreshAndPersist
  retry="30 5 300 3"
  interval=00:00:05:00
-
add: olcMirrorMode
olcMirrorMode: TRUE

In srv-02: just replace provider attributes of replication_config.ldif file to ldap://ldap01:389 and rid to 002

rid - Uniquely identifies the replication consumer.
provider - The URI of the server being replicated.The provider parameter specifies a scheme, a host and optionally a port where the provider slapd instance can be found. ***bindmethod*** - The bindmethod is simple or sasl, depending on whether simple password-based authentication or SASL authentication is to be used when connecting to the provider slapd` instance.
binddn - The DN the consumer uses to login to the provider. It gives the DN to bind as for the syncrepl searches to the provider slapd.
credentials - The password the bind DN should used to login to the provider.
searchbase - The part of the DIT that should be replicated. This is usually the olcSuffix of the back end being replicated.
Type - The method used to query the provider for changes. refreshAndPersist keeps a session open and waits for changes. refreshOnly periodically queries the master for changes.
retry - How long to wait before retrying when an error occurs. It has 4 fields, respectively:
1. The time in seconds between retries.
2. The retry count. I.e. how many times to retry at the first field’s interval.
3. The time in seconds between retries after the retry count has been reached.
4. The retry count at the second interval. The server will give up trying to replicate when this number is reached.
A + in a retry count field means to keep trying indefinitely. In the examples, the servers will try again every 5 seconds. If it has tried 5 times, it will try again every 300 seconds until it replicates without any errors. If an error occurs during replication, the consumer will attempt to reconnect according to the retry parameter which is a list of the and <# of retries> pairs.

olcMirrorMode - This is what enables the MirrorMode behavior. Without it, changes to the replicated directories will be refused.

Once you are satisfied with your replication configuration, apply the LDIF:

[root@srv-01 ~]# ldapmodify -Y EXTERNAL -H ldapi:/// -f replication_config.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
modifying entry "olcDatabase={3}mdb,cn=config"
adding new entry "olcOverlay=syncprov,olcDatabase={3}mdb,cn=config"

Now MirrorMode Replication configuration part has been completed in both servers.

In order to verify that the overlays are installed on your database, issue the following command after the above overlays provisioning on database in both servers. It will show the details.

[root@srv-01 ~]# ldapsearch -Y EXTERNAL -H ldapi:/// -b "olcDatabase={3}mdb,cn=config" '(objectClass=*)' -LLL
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {3}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=bidhankhatri,dc=com,dc=np
olcLastMod: TRUE
olcRootDN: cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np
olcRootPW: {SSHA}cdScDk18A5c5odB+kwRgqDizzNEE5sMB
olcDbEnvFlags: nometasync
olcDbEnvFlags: writemap
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
olcDbMaxSize: 9048576000
olcSyncrepl: {0}rid=001 provider=ldap://ldap02:389/ bindmethod=simple binddn="
 cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np" credentials="helloworld123$" searc
 hbase="dc=bidhankhatri,dc=com,dc=np" scope=sub schemachecking=on type=refresh
 AndPersist retry="30 5 300 3" interval=00:00:05:00
olcMirrorMode: TRUE

dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpSessionlog: 100

Now Test your replication by adding, changing, or removing an entry from a replicated database. Open port 389 between both servers as they need to communicate during replication process.

[root@srv-01 ~]# netstat -an | grep -i ":389"
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN
tcp        0      0 172.16.0.98:389       172.16.0.99:35610     ESTABLISHED
tcp        0      0 172.16.0.98:55660     172.16.0.99:389       ESTABLISHED
tcp6       0      0 :::389                  :::*                    LISTEN

Create LDAP USER

Create a user in one of the node. Newly created user should also be seen on another node.

vim users.ldif

# bidhan.khatri, users, bidhankhatri.com.np
dn: uid=bidhan.khatri,ou=people,dc=bidhankhatri,dc=com,dc=np
objectClass: inetOrgPerson
objectClass: top
uid: bidhan.khatri
ou: People
cn: Bidhan Khatri
sn: bidhan.khatri
mail: bidhan.khatri@bidhankhatri.com.np

[root@srv-01 ~]# ldapadd -x -W -D "cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np" -f users.ldif
Enter LDAP Password:
adding new entry "uid=bidhan.khatri,ou=people,dc=bidhankhatri,dc=com,dc=np"

change user password:

[root@srv-01 ~]# ldappasswd -s 1password23$ -W -D "cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np" -x "uid=bidhan.khatri,ou=People,dc=bidhankhatri,dc=com,dc=np"
Enter LDAP Password:

Where,
-s specify the password for the username
-x username for which the password is changed
-D Distinguished name to authenticate to the LDAP server.

verify user:

[root@srv-02 ~]# ldapsearch -x uid=bidhan.khatri -b dc=bidhankhatri,dc=com,dc=np
# extended LDIF
#
# LDAPv3
# base <dc=bidhankhatri,dc=com,dc=np> with scope subtree
# filter: uid=bidhan.khatri
# requesting: ALL
#

# bidhan.khatri, People, bidhankhatri.com.np
dn: uid=bidhan.khatri,ou=People,dc=bidhankhatri,dc=com,dc=np
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: Bidhan
sn: Khatri
uid: bidhan.khatri
uidNumber: 5000
gidNumber: 5000
homeDirectory: /home/bidhan.khatri
loginShell: /bin/sh
mail: bidhan.khatri@bidhankhatri.com.np

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

To delete particular user:

[root@srv-02 ~]# ldapdelete -W -D "cn=ldapadmin,dc=bidhankhatri,dc=com,dc=np" "uid=bidhan.khatri,ou=People,dc=bidhankhatri,dc=com,dc=np"
Enter LDAP Password:

[root@srv-01 ~]# ldapsearch -x uid=bidhan.khatri -b dc=bidhankhatri,dc=com,dc=np
# extended LDIF
#
# LDAPv3
# base <dc=bidhankhatri,dc=com,dc=np> with scope subtree
# filter: uid=bidhan.khatri
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1