OpenLdap Documentation1
OpenLdap Documentation1
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
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
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
Proceed with the install of the server and the main command line utilities:
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 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:
dn: dc=auth,dc=pe
dn: cn=admin,dc=auth,dc=pe
Explanation of entries:
-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.
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
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.
cn = PartsEurope Company
ca
cert_signing_key
expiration_days = 3650
Create the self-signed CA certificate:
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.
The above certificate is good for 10 year, and it’s valid only for the ldap01.auth.pe hostname.
Adjust accordingly.
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:
Test StartTLS:
$ 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:
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:
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:
Test StartTLS:
$ 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:
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
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:
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:
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
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