0% found this document useful (0 votes)
31 views14 pages

OpenLdap Documentation1

This document provides instructions for setting up an OpenLDAP installation with mirror mode replication between provider and consumer servers. The key steps include: 1. Installing LDAP servers and configuring TLS/SSL for encryption. 2. Configuring the provider servers in mirror mode for replication. 3. Configuring the consumer servers to replicate from the providers. 4. The infrastructure diagram shows two provider servers replicating to two consumer servers with load balancing for high availability.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
31 views14 pages

OpenLdap Documentation1

This document provides instructions for setting up an OpenLDAP installation with mirror mode replication between provider and consumer servers. The key steps include: 1. Installing LDAP servers and configuring TLS/SSL for encryption. 2. Configuring the provider servers in mirror mode for replication. 3. Configuring the consumer servers to replicate from the providers. 4. The infrastructure diagram shows two provider servers replicating to two consumer servers with load balancing for high availability.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

OpenLDAP Installation with Mirrir Mode Scenario

Resources:

https://openldap.com/doc/admin26/replication.html#Mirror%20mode

https://ubuntu.com/server/docs/service-ldap

https://ubuntu.com/server/docs/service-ldap-with-tls

https://ubuntu.com/server/docs/service-ldap-replication

https://www-jianshu-com.translate.goog/p/34dc6412de30?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp

Main Steps

1. Install LDAP Servers


2. Configure TLS/SSL
3. Configure Mirror Mode for provider servers
4. Configure Replication for consumer servers

Agreement

 Ldap01 = One of the name of the providers hostname for example (p901-
openldap-s-17 , p901-openldap-s-18)
 Ldap02 = One of the name of the consumer hostname for example (p901-
openldap-s-21 , p901-openldap-s-22)
Infrastructure

 The diagram is shown OpenLDAP Site

 The configured architecture for PE


Users with read/write access

OpenLDAP Consumer 01
OpenLDAP Provider 01 IP : 172.16.191.21
IP : 172.16.191.17 Port: 389
Port: 389

HA Proxy
Mirror Mode Replication

NLB
172.16.191.30
Ldaps://Auth.pe
Ports: 389, 399

NLB
Ldaps://Auth.pe

OpenLDAP Provider 02
IP : 172.16.191.18
OpenLDAP Consumer 02
Port: 389
IP : 172.16.191.22 Users with read access
Port : 389
LDAP Installation

The installation of slapd will create a working configuration with a top level entry, and an
administrator’s DN. In particular, it will create a database instance that you can use to store your
data. However, the suffix (or base DN) of this instance will be determined from the domain name
of the host. If you want something different, you can change it right after the installation when
you still don’t have any useful data.
Note

This guide will use a database suffix of dc=auth,dc=pe.

Proceed with the install of the server and the main command line utilities:

sudo apt install slapd ldap-utils


If you want to change your DIT suffix, now would be a good time, because changing it discards
your existing one. To change the suffix, run the following command:

sudo dpkg-reconfigure slapd


To switch your DIT suffix to dc=auth,dc=pe, for auth, so you can follow this guide more closely,
answer auth.pe when asked about the DNS domain name.

Throughout this guide we will issue many commands with the LDAP utilities. To save some typing,
we can configure the OpenLDAP libraries with certain defaults in /etc/ldap/ldap.conf:

BASE dc=auth,dc=pe
URI ldap://ldap01.auth.pe

The Default DIT

The packaging of slapd is designed to be configured within the service itself by dedicating a
separate DIT for that purpose. This allows one to dynamically configure slapd without the need to
restart the service or edit config files. This configuration database consists of a collection of text-
based LDIF files located under /etc/ldap/slapd.d, but these should never be edited directly. This
way of working is known by several names: the slapd-config method, the RTC method (Real Time
Configuration), or the cn=config method. You can still use the traditional flat-file method
(slapd.conf) but it’s not going to be covered in this guide.

Right after installation, you will get two databases, or suffixes: one for your data, based on your
host’s domain (dc=auth,dc=pe), and one for your configuration, with its root at cn=config. To
change the data on each we need different credentials and access methods:

 dc=auth,dc=pe: the administrative user for this suffix is cn=admin,dc=auth,dc=pe and its
password is the one selected during the installation of the slapd package
 cn=config: the configuration slapd itself is stored under this suffix. Changes to it can be
made by the special DN gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth.
This is how the local system’s root user (uid=0/gid=0) is seen by the directory when using
SASL EXTERNAL authentication through the ldapi:/// transport via the /run/slapd/ldapi unix
socket. Essentially what this means is that only the local root user can update
the cn=config database.
 This is what the slapd-config DIT looks like via the LDAP protocol (listing only the dns):
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
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}mdb,cn=config
Explanation of entries:

o cn=config: global settings


o cn=module{0},cn=config: a dynamically loaded module
o cn=schema,cn=config: contains hard-coded system-level schema
o cn={0}core,cn=schema,cn=config: the hard-coded core schema
o cn={1}cosine,cn=schema,cn=config: the cosine schema
o cn={2}nis,cn=schema,cn=config: the nis schema
o cn={3}inetorgperson,cn=schema,cn=config: the inetorgperson schema
o olcDatabase={-1}frontend,cn=config: frontend database, default settings for other
databases
o olcDatabase={0}config,cn=config: slapd configuration database (cn=config)
o olcDatabase={1}mdb,cn=config: your database instance (dc=auth,dc=pe)
 This is what the dc=auth,dc=pe DIT looks like:

$ ldapsearch -x -LLL -H ldap:/// -b dc=auth,dc=pe dn

dn: dc=auth,dc=pe

dn: cn=admin,dc=auth,dc=pe
Explanation of entries:

o dc=auth,dc=pe: base of the DIT


o cn=admin,dc=auth,dc=pe: administrator (rootDN) for this DIT (set up during
package install)

Notice how we used two different authentication mechanisms:

 -x: this is called a simple bind, and is essentially a plain text authentication. Since
no binddn was provided (via -D), this became an anonymous bind. Without -x, the default
is to use a SASL bind.
 -Y EXTERNAL: this is using a SASL bind (no -x was provided), and further specifying
the EXTERNAL type. Together with -H ldapi:///, this uses a local unix socket connection
In both cases we only got the results that the server ACLs allowed us to see, based on who we
are. A very handy tool to verify the authentication is ldapwhoami:

$ ldapwhoami -x
anonymous

$ ldapwhoami -x -D cn=admin,dc=auth,dc=pe -W
Enter LDAP Password:
dn:cn=admin,dc=auth,dc=pe
When you use simple bind (-x) and specify a binddn with -D as your authentication dn, the server
will look for a userPassword attribute in that entry, and use that to verify the credentials. In this
particular case above, we used the database rootDN entry, i.e., the actual administrator, and that
is a special case whose password is set in the configuration when the package is installed.

Here are the SASL EXTERNAL auths:

$ ldapwhoami -Y EXTERNAL -H ldapi:/// -Q


dn:gidNumber=1000+uidNumber=1000,cn=peercred,cn=external,cn=auth

$ sudo ldapwhoami -Y EXTERNAL -H ldapi:/// -Q


dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

When using SASL EXTERNAL via the ldapi:/// transport, the binddn becomes a combination of
the uid and gid of the connecting user, followed by the suffix cn=peercred,cn=external,cn=auth.
The server ACLs know about this, and grant the local root user complete write access
to cn=config via the SASL mechanism.
LDAP & TLS

When authenticating to an OpenLDAP server it is best to do so using an encrypted session. This


can be accomplished using Transport Layer Security (TLS).

Here, we will be our own Certificate Authority and then create and sign our LDAP server certificate
as that CA. This guide will use the certtool utility to complete these tasks. For simplicity, this is
being done on the OpenLDAP server itself, but your real internal CA should be elsewhere.

Install the gnutls-bin and ssl-cert packages:

sudo apt install gnutls-bin ssl-cert


Create a private key for the Certificate Authority:

sudo certtool --generate-privkey --bits 4096 --outfile /etc/ssl/private/mycakey.pem


Create the template/file /etc/ssl/ca.info to define the CA:

cn = PartsEurope Company
ca
cert_signing_key
expiration_days = 3650
Create the self-signed CA certificate:

sudo certtool --generate-self-signed \


--load-privkey /etc/ssl/private/mycakey.pem \
--template /etc/ssl/ca.info \
--outfile /usr/local/share/ca-certificates/mycacert.crt

Run update-ca-certificates to add the new CA certificate to the list of trusted CAs. Note the one
added CA:

$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
This also creates a /etc/ssl/certs/mycacert.pem symlink pointing to the real file
in /usr/local/share/ca-certificates.

Make a private key for the server:

sudo certtool --generate-privkey \


--bits 2048 \
--outfile /etc/ldap/ldap01_slapd_key.pem

Create the /etc/ssl/ldap01.info info file containing:

organization = PartsEurope Company


cn = ldap01.auth.pe
tls_www_server
encryption_key
signing_key
expiration_days = 3650

The above certificate is good for 10 year, and it’s valid only for the ldap01.auth.pe hostname.
Adjust accordingly.

Create the server’s certificate:

sudo certtool --generate-certificate \


--load-privkey /etc/ldap/ldap01_slapd_key.pem \
--load-ca-certificate /etc/ssl/certs/mycacert.pem \
--load-ca-privkey /etc/ssl/private/mycakey.pem \
--template /etc/ssl/ldap01.info \
--outfile /etc/ldap/ldap01_slapd_cert.pem
Adjust permissions and ownership:

sudo chgrp openldap /etc/ldap/ldap01_slapd_key.pem


sudo chmod 0640 /etc/ldap/ldap01_slapd_key.pem
Your server is now ready to accept the new TLS configuration.

Create the file certinfo.ldif with the following contents (adjust paths and filenames accordingly):

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/mycacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ldap01_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ldap01_slapd_key.pem
Use the ldapmodify command to tell slapd about our TLS work via the slapd-config database:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif


If you need access to LDAPS (LDAP over SSL), then you need to edit /etc/default/slapd and
include ldaps:/// in SLAPD_SERVICES like below:

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

And restart slapd with:

sudo systemctl restart slapd

Test StartTLS:

$ ldapwhoami -x -ZZ -H ldap://ldap01.auth.pe


anonymous
Test LDAPS:

$ ldapwhoami -x -H ldaps://ldap01.auth.pe
anonymous
Certificate for an OpenLDAP replica

To generate a certificate pair for an OpenLDAP replica (consumer), create a holding directory
(which will be used for the eventual transfer) and:

mkdir ldap02-ssl
cd ldap02-ssl
certtool --generate-privkey --bits 2048 --outfile ldap02_slapd_key.pem

Create an info file, ldap02.info, for the Consumer server, adjusting its values accordingly:

organization = PartsEurope Company


cn = ldap02.auth.pe
tls_www_server
encryption_key
signing_key
expiration_days = 3650
Create the Consumer’s certificate:

sudo certtool --generate-certificate \


--load-privkey ldap02_slapd_key.pem \
--load-ca-certificate /etc/ssl/certs/mycacert.pem \
--load-ca-privkey /etc/ssl/private/mycakey.pem \
--template ldap02.info \
--outfile ldap02_slapd_cert.pem

Get a copy of the CA certificate:

cp /etc/ssl/certs/mycacert.pem .

We’re done. Now transfer the ldap02-ssl directory to the Consumer. Here we use scp (adjust
accordingly):

cd ..
scp -r ldap02-ssl user@consumer:

On the Consumer side, install the certificate files you just transferred:

sudo cp ldap02_slapd_cert.pem ldap02_slapd_key.pem /etc/ldap


sudo chgrp openldap /etc/ldap/ldap02_slapd_key.pem
sudo chmod 0640 /etc/ldap/ldap02_slapd_key.pem
sudo cp mycacert.pem /usr/local/share/ca-certificates/mycacert.crt
sudo update-ca-certificates
Create the file certinfo.ldif with the following contents (adjust accordingly regarding paths and
filenames, if needed):

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/mycacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ldap02_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ldap02_slapd_key.pem
Configure the slapd-config database:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif


Like before, if you want to enable LDAPS, edit /etc/default/slapd and
add ldaps:/// to SLAPD_SERVICES, and then restart slapd.

Test StartTLS:

$ ldapwhoami -x -ZZ -H ldap://ldap02.auth.pe


anonymous
Test LDAPS:

$ ldapwhoami -x -H ldaps://ldap02.auth.pe
anonymous

Note: In our environment we need to have wildcard certificate, So we decided to generate just
one wildcard certificate for all servers.(*.auth.pe)
Configure Mirror Mode for provider servers
Add syncprov module
Syncprov is the synchronization module of openldap, executed on both servers:
The second node installs the syncprov module
The addition is complete without reporting an error.
The content of the mod_syncprov.ldif file is as follows:
Execute on both servers:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f mod_syncprov.ldif


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

Among them, the content of syncprov.ldif is as follows:


$ ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov.ldif
dn:olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
objectClass:olcOverlayConfig
objectClass:olcSyncProvConfig
olcOverlay:syncprov
olcSpCheckpoint:100 10
olcSpSessionLog:100

Configuration of LDAP master node


Execute on host1:

$ ldapadd -Y EXTERNAL -H ldapi:/// -f ldap01.ldif -W

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=001
provider=ldap://p901-openldap-s-18.auth.pe:389
bindmethod=simple
binddn="cn=admin,dc=auth,dc=pe"
credentials=password
searchbase="dc=auth,dc=pe"
filter="(objectClass=*)"
scope=sub
schemachecking=off
attrs="*,+"
type=refreshAndPersist
retry="5 5 300 +"
interval=00:00:01:00
-
add: olcMirrorMode
olcMirrorMode: TRUE
-
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcDbIndex
olcDbIndex: entryCSN eq

Execute on host2:
$ ldapadd -Y EXTERNAL -H ldapi:/// -f ldap02.ldif -W

dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 2

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=001
provider=ldap://p901-openldap-s-17.auth.pe:389
bindmethod=simple
binddn="cn=admin,dc=auth,dc=pe"
credentials=password
searchbase="dc=auth,dc=pe"
filter="(objectClass=*)"
scope=sub
schemachecking=off
attrs="*,+"
type=refreshAndPersist
retry="5 5 300 +"
interval=00:00:01:00
-
add: olcMirrorMode
olcMirrorMode: TRUE
-
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcDbIndex
olcDbIndex: entryCSN eq
Configure Replication for consumer servers
The LDAP service becomes increasingly important as more networked systems begin to depend on
it. In such an environment, it is standard practice to build redundancy (high availability) into LDAP
to prevent havoc should the LDAP server become unresponsive. This is done through LDAP
replication.

Replication is achieved via the Syncrepl engine. This allows changes to be synchronized using
a Consumer - Provider model. A detailed description this replication mechanism can be found in
the OpenLDAP Administrator’s Guide and in its defining RFC 4533.

Important

You must have TLS enabled already. Please consult the LDAP with TLS guide

Provider Configuration - replication user

Both replication strategies will need a replication user and updates to the ACLs and limits regarding
this user.

To create the replication user, save the following contents to a file called replicator.ldif:

dn: cn=replicator,dc=auth,dc=pe
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: replicator
description: Replication user
userPassword: {CRYPT}x
Then add it with ldapadd:

$ ldapadd -x -ZZ -D cn=admin,dc=auth,dc=pe -W -f replicator.ldif


Enter LDAP Password:
adding new entry "cn=replicator,dc=auth,dc=pe"
Now set a password for it with ldappasswd:

$ ldappasswd -x -ZZ -D cn=admin,dc=auth,dc=pe -W -S cn=replicator,dc=auth,dc=pe


New password:
Re-enter new password:
Enter LDAP Password:
The next step is to give this replication user the correct privileges:

 read access to the content that we want replicated


 no search limits on this content
For that we need to update the ACLs on the provider. Since ordering matters, first check what
the existing ACLs look like on the dc=auth,dc=pe tree:

$ sudo ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b cn=config '(olcSuffix=dc=auth,dc=pe)'


olcAccess
dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
What we need is to insert a new rule before the first one, and also adjust the limits for the
replicator user. Prepare the replicator-acl-limits.ldif file with this content:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to *
by dn.exact="cn=replicator,dc=auth,dc=pe" read
by * break
-
add: olcLimits
olcLimits: dn.exact="cn=replicator,dc=auth,dc=pe"
time.soft=unlimited time.hard=unlimited
size.soft=unlimited size.hard=unlimited
And add it to the server:

$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f replicator-acl-limits.ldif


modifying entry "olcDatabase={1}mdb,cn=config"
Provider Configuration - standard replication

The remaining configuration for the provider using standard replication is to add
the syncprov overlay on top of the dc=auth,dc=pe database.o

Create a file called provider_simple_sync.ldif with this content:

# Add indexes to the frontend db.


dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
-
add: olcDbIndex
olcDbIndex: entryUUID eq

#Load the syncprov module.


dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

# syncrepl Provider for primary db


dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionLog: 100
Add the new content:

sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f provider_simple_sync.ldif


The Provider is now configured.
Consumer Configuration - standard replication

Install the software by going through Installation. Make sure schemas and the database suffix are
the same, and enable TLS.

Create an LDIF file with the following contents and name it consumer_simple_sync.ldif:

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcSyncrepl
olcSyncrepl: rid=0
provider=ldap://ldap01.auth.pe
bindmethod=simple
binddn="cn=replicator,dc=auth,dc=pe" credentials=<secret>
searchbase="dc=auth,dc=pe"
schemachecking=on
type=refreshAndPersist retry="60 +"
starttls=critical tls_reqcert=demand
-
add: olcUpdateRef
olcUpdateRef: ldap://ldap01.auth.pe

Add the new configuration:

sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f consumer_simple_sync.ldif


You’re done. The dc=auth,dc=pe tree should now be synchronizing.

You might also like