HOWTO : OpenLDAP 2.4 Replication on CentOS 6.2

We continue our OpenLDAP 2.4 on CentOS 6.2 with a description on how to setup  between two OpenLDAP 2.4 servers. This happens to be the final bullet point in our list of goals :

1. Install OpenLDAP 2.4.
2. Configure Transport Layer Security (TLS).
3. Manage users and groups in OpenLDAP.
4. Configure pam_ldap to authenticate users via OpenLDAP.
5. Use OpenLDAP as sudo's configuration repository.
6. Use OpenLDAP as automount map repository for autofs.
7. Use OpenLDAP as NFS netgroup repository again for autofs.
8. Use OpenLDAP as the Kerberos principal repository.
9. Setup OpenLDAP backup and recovery.
10. Setup OpenLDAP replication.

Of course the first thing to do in order to be able to replication our DIT is to have another CentOS machine. So go ahead and install it on a seperate computer. We will continue with our example two machines : alice and bob. Alice is the current OpenLDAP server while bob was the client. At the end of this document, bob will be the second OpenLDAP server. Which in OpenLDAP syncrepl parlance, we have these entities :

• provider : alice.company.com (a.k.a. master server)
• consumer : bob.company.com (a.k.a. replica server)

Another important thing to do is to read the OpenLDAP replication chapter in the administrator's guide. The following exerpt is of particular interest :

Syncrepl supports both pull-based and push-based synchronization. In its basic refreshOnly synchronization mode, the provider uses pull-based synchronization where the consumer servers need not be tracked and no history information is maintained. The information required for the provider to process periodic polling requests is contained in the synchronization cookie of the request itself. To optimize the pull-based synchronization, syncrepl utilizes the present phase of the LDAP Sync protocol as well as its delete phase, instead of falling back on frequent full reloads. To further optimize the pull-based synchronization, the provider can maintain a per-scope session log as a history store. In its refreshAndPersist mode of synchronization, the provider uses a push-based synchronization. The provider keeps track of the consumer servers that have requested a persistent search and sends them necessary updates as the provider replication content gets modified.

Replication is handeled by an OpenLDAP overlay. Check the slapo-syncprov(5) man page for the provider overlay information. With that in mind, we will setup a refreshAndPersist replication using the delta-syncrepl replication scheme. Note that, as the official documentation says :

As you can see, you can let your imagination go wild using Syncrepl and slapd-ldap(8) tailoring your replication to fit your specific network topology.

Provider Configuration

Setting up delta-syncrepl requires configuration changes on both the master (i.e. provider) and replica (i.e. consumer) servers. We will start by configuring the provider machine (i.e. alice.company.com) and then continue to the consumer machine (i.e. bob.company.com).

So, connect to the provider server.

ssh alice.company.com

On this machine, we need to setup several things :

1. A cn=module configuration.
2. An accesslog database to store the accesslog data (i.e. cn=accesslog)
3. A syncprov overlay over the accesslog database.
4. Two overlays over our primary database (i.e. dc=company,dc=com)
5. A new user object to authenticate and fetch the data.
6. Limits and ACLs to the new object.

Let's configure those items one at a time.

Provider Module Configuration

To configure a module on the provider, we first need to check if we have one? Since we have a Kerberos realm and SASL GSSAPI authentication setup, let's use this to simplify our queries. Note that you can always use the cn=admin,dc=company,dc=com RootDN to perform all the tasks in this blog post, but the queries are longer to write.

kinit -p drobilla/admin@COMPANY.COM
ldapsearch -ZLLLb cn=config olcModulePath

The above query did not return the olcModulePath object. So we need to create it. But what is our module path? The cn=module documentation shows us that module names end in « .la ». With that info, a simple rpm query will show us where they're stored on the filesystem.

rpm -ql openldap-servers | grep '\.la$'

/usr/lib/openldap/accesslog.la

/usr/lib/openldap/auditlog.la

/usr/lib/openldap/collect.la

/usr/lib/openldap/constraint.la

/usr/lib/openldap/dds.la

/usr/lib/openldap/deref.la

/usr/lib/openldap/dyngroup.la

/usr/lib/openldap/dynlist.la

/usr/lib/openldap/memberof.la

/usr/lib/openldap/pcache.la

/usr/lib/openldap/ppolicy.la

/usr/lib/openldap/refint.la

/usr/lib/openldap/retcode.la

/usr/lib/openldap/rwm.la

/usr/lib/openldap/seqmod.la

/usr/lib/openldap/smbk5pwd.la

/usr/lib/openldap/sssvlv.la

/usr/lib/openldap/syncprov.la

/usr/lib/openldap/translucent.la

/usr/lib/openldap/unique.la

/usr/lib/openldap/valsort.la

Ok, so we know our olcModulePath is /usr/lib/openldap. We also know that we have quite a bunch of different modules available. Let's write another LDIF file to set the olcModulePath, but also which modules we want to load. Since we need both the accesslog and the syncprov overlays, we might as well load them right?!

vi ~/ldap/module.ldif

Load this new configuration.

ldapmodify -aZf ~/ldap/module.ldif

Check to see if it's installed? Then what's in it?

ldapsearch -ZLLLb cn=config dn | grep module

ldapsearch -ZLLLb cn=module{0},cn=config

dn: cn=module{0},cn=config

objectClass: olcModuleList

cn: module{0}

olcModulePath: /usr/lib/openldap

olcModuleLoad: {0}accesslog.la

olcModuleLoad: {1}syncprov.la

Good. We can proceed to the next provider objective.

Provider Accesslog Database

Now that we have the accesslog overlay module loaded, we must create a database in which to store the accesslog data. We of course do this with another LDIF file.

vi ~/ldap/accesslog.ldif 

As we can see, this database uses a new directory that must be created first. We also need to drop a DB_CONFIG file in there and fix permissions.

sudo mkdir -p /var/lib/ldap/accesslog
sudo cp `rpm -ql openldap-servers | grep DB_CONFIG` /var/lib/ldap/accesslog/DB_CONFIG
sudo chown -R ldap:ldap /var/lib/ldap

Alright, we can now create the new accesslog database. Note that we're using the hdb instead of the bdb for this database. There's no real reason, choose whichever you prefer.

ldapmodify -aZf ~/ldap/accesslog.ldif

We should now have a new database. Let's see if that's true?

ldapsearch -ZLLLb cn=config dn | grep hdb
dn: olcDatabase={3}hdb,cn=config

What does it contain?

ldapsearch -ZLLLb olcDatabase={3}hdb,cn=config
dn: olcDatabase={3}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {3}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=company,dc=com
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart

Great! Let's continue with our next objective.

Provider Syncprov Overlay Over the Accesslog Database

Our next objective is to setup a syncprov overlay on the new accesslog database. Create this LDIF file :

vi ~/ldap/overlay.accesslog.ldif 

And add the new setup to our OpenLDAP server.

ldapmodify -aZf ~/ldap/overlay.accesslog.ldif 

We should now have a new dn: in our olcDatabase={3}hdb,cn=config database.

ldapsearch -ZLLLb olcDatabase={3}hdb,cn=config

dn: olcDatabase={3}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {3}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=company,dc=com
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart

dn: olcOverlay={0}syncprov,olcDatabase={3}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE

Sure enough, it's there. We can now continue with our setup.

Provider Overlays On Primary Database

Do do this objective, we must of course write another LDIF file in which we will a) setup new indexes to our primary database, b) add the syncprov overlay and c) add the accesslog overlay.

vi ~/ldap/overlay.primary.ldif

We then add this new LDIF into our system.

ldapmodify -aZf ~/ldap/overlay.primary.ldif 

Which then gives us two new overlays on the primary database.

ldapsearch -ZLLLb olcDatabase={1}bdb,cn=config dn
dn: olcDatabase={1}bdb,cn=config
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config

And sure enough, we do have the two new overlays.

Provider Replication User

We need a user for the replication. That user will be used to authenticate the replication server and read the data. Period. Once again, we need an LDIF file.

vi ~/ldap/replication.ldif 

Apply this LDIF file.

ldapmodify -aZf ~/ldap/replication.ldif 

This user needs a real password. Make sure to record this password and keep it safe.

ldappasswd -xZ -S cn=replication,dc=company,dc=com

Note that in this example our replication user is named just « replication ». If you plan on having more than one replicated server, then ideally choose a unique name for each of the replicated server. This way you can audit which machine replicates and when. You can also decide which part of the DIT gets replicated to which machine. But that's another story.

Provider Limits and ACLs to the Replication User

We now need to give access via ACLs and some limits to the new user. Let's do it in two steps starting with the limits (or lack of actually :)

vi ~/ldap/limits.ldif

Then apply this LDIF.

ldapmodify -Zf ~/ldap/limits.ldif

Next step is to give read access to the replication user. Before we do this, it's usually a good idea to double-check our current ACL list.

ldapsearch -LLLb cn=config olcAccess

We can now create another LDIF file to update our ACLs. The idea here is to have the same sets of ACLs on both the provider and the consumer. Except that on the consumer, we don't need any ACLs with regards to the replication user (i.e. the one defined in olcSyncRepl:).

vi ~/ldap/consumer.acl.ldif

Enable the ACL changes.

ldapmodify -f ~/ldap/consumer.acl.ldif

Check the ACL listing.

ldapsearch -Zb olcDatabase={1}bdb,cn=config olcAccess

Test to see if we can access our entire DIT with the replication DN?

ldapsearch -xZWD cn=replication,dc=company,dc=com -H ldap://alice.company.com

This is of course crucial. Do not continue with this blog post until you can access the entire DIT with the replication DN. Once it works, we need to setup our consumer OpenLDAP machine.

Consumer Configuration

Consumer OpenLDAP Installation

Install another CentOS 6 machine and connect to it.

ssh bob.company.com

Make sure that ntpd(8) is running and that both alice and bob's clocks are synchronized. All of your servers' clocks must be tightly synchronized using either NTP(See http://www.ntp.org/ for info on NTP), an atomic clock or some other reliable time reference.

ntpq -p

Then connect to bob.company.com and install a few packages.

sudo yum -y install openldap-servers cyrus-sasl-gssapi pam_krb5 krb5-server-ldap

Configure an empty OpenLDAP server. I've already covered how to do this in a previous blog post, but we now need to change this a little. So we can't really follow the other post. Let's do it all over again then. So the first thing we must do is upgrade the sudo package to have the latest sudo schema. I've explained how to achieve this goal in another blog post. But I'll show here just what we need which starts by installing the latest (as of this writing) sudo package from the sudo website. Note that if your machine is 32 bit, then the package would be sudo-1.8.4-5.el6.i386.rpm.

wget http://www.sudo.ws/sudo/dist/packages/Centos/6/sudo-1.8.4-5.el6.x86_64.rpm

Upgrade sudo.

sudo rpm -U ./sudo-1.8.4-5.el6.x86_64.rpm

This sudo package comes with an OpenLDAP schema. Get the path to the file. Keep note of this path as we will include it in our slapd configuration file.

rpm -ql sudo | grep -i openldap

/usr/share/doc/sudo-1.8.5-1.el6/schema.OpenLDAP

We now need to create the config file. It needs the RootDN password, so record the output of the slappasswd(8C) command

slappasswd
New password: 
Re-enter new password: 
{SSHA}JGjPUbxyCn7wa/pt8YM5rzK7s/hUGncW

Plug the above output into the file below. To understand the syncrepl syntax, refer to the official syncrepl documentation.

mkdir ~/ldap
vi ~/ldap/slapd.conf.consumer

Create the configuration.

sudo slapcat -f ~/ldap/slapd.conf.consumer -F /tmp -n 0

Remove the old configuration.

sudo rm -rf /etc/openldap/slapd.d/*

Install the new one.

sudo cp -rp /tmp/cn\=config* /etc/openldap/slapd.d

sudo chown -R ldap:ldap /etc/openldap/slapd.d

Check to see if the new configuration is ok?

sudo slaptest -uF /etc/openldap/slapd.d

config file testing succeeded

Install the DB_CONFIG file.

egrep -vi '^$|^#' `rpm -ql openldap-servers | grep DB_CONFIG` > /tmp/DB_CONFIG

sudo mv /tmp/DB_CONFIG /var/lib/ldap/DB_CONFIG

sudo chown -R ldap:ldap /var/lib/ldap

Prepare the log system.

sudo vi /etc/rsyslog.conf

Touch the new log file.

sudo touch /var/log/slapd.log

Make sure the log file doesn't grow to humongous proportions.

sudo vi /etc/logrotate.d/slapd

Restart the rsyslog daemon so that it knows about the changes.

sudo /etc/init.d/rsyslog restart

Edit the slapd(8) system configuration file.

sudo vi /etc/sysconfig/ldap

Start the slapd(8) daemon.

sudo /etc/init.d/slapd start

Make sure the daemon starts when the server boots.

sudo chkconfig slapd on

Configure a system-wide LDAP client configuration. This is to simplifiy our life and reduce typing later on. Don't worry about the TLS configurations for now. We will configure them later, but it doesn't hurt to have them in the file at the moment. Don't forget that in this blog post, the OpenLDAP server's FQDN is bob.company.com and not alice.company.com as we used to. This is important because here we don't want to query nor modify the provider (i.e. alice.company.com), but only the consumer (i.e. bob.company.com).

sudo vi /etc/openldap/ldap.conf

Check if our admin user can connect? Double check the logs to make sure you're not binding to the provider!

ldapwhoami -WD cn=admin,dc=company,dc=com

Enter LDAP Password:

dn:cn=admin,dc=company,dc=com

Consumer TLS Configuration

Ok, let's configure TLS for the consumer. I'll still use a Windows CA for this post.

openssl req -newkey rsa:2048 -keyout `hostname`.key -nodes -out `hostname`.req -subj /CN=bob.company.com/O=Company/C=CA/ST=QC/L=Montreal

Upload the .req file to the CA machine sign it.

C:\> certreq -submit -attrib "CertificateTemplate:WebServer" -config "caserver.company.com\Company CA" bob.company.com.req bob.company.com.pem

Upload the .pem file to our consumer OpenLDAP server then place both the .pem and .key files into the proper location with the appropriate permissions.

sudo mv bob.company.com.pem bob.company.com.key /etc/pki/tls/certs
sudo chown ldap:ldap /etc/pki/tls/certs/bob.company.com.*
sudo chmod 600 /etc/pki/tls/certs/bob.company.com.key

Grab a copy of the CA's certificate from our provider server.

scp alice.company.com:/etc/pki/tls/certs/companyCA.crt /tmp
sudo mv /tmp/companyCA.crt /etc/pki/tls/certs
sudo chown root:root /etc/pki/tls/certs/companyCA.crt

Configure TLS in our consumer OpenLDAP server.

vi ~/ldap/tls.consumer.ldif

Add the TLS configuration to the cn=config base.

ldapmodify -WD cn=admin,dc=company,dc=com -H ldapi:/// -f ~/ldap/tls.consumer.ldif

Check if our configuration has been installed?

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep olcTLS

Check to see if we can connect with TLS (i.e. the « -Z » switch).

ldapwhoami -xZWD cn=admin,dc=company,dc=com -H ldap://bob.company.com

Revist the LDAP client configuration file to enable the TLS configs.

sudo vi /etc/openldap/ldap.conf

Modify the consumer cn=config and database configurations.

vi ~/ldap/consumer.ldif

Apply the changes.

ldapmodify -WD cn=admin,dc=company,dc=com -H ldapi:/// -f ~/ldap/consumer.ldif 

Check the configuration changes to both the cn=config and the primary database.

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}bdb))"

Consumer SASL GSSAPI Configuration

Enable SASL GSSAPI authentication.

vi ~/ldap/consumer.gssapi.ldif

Add the modification to the server.

ldapmodify -xZWD cn=admin,dc=company,dc=com -H ldap://bob.company.com -f ~/ldap/consumer.gssapi.ldif

Change the system-wide OpenLDAP daemin configuration to add a Kerberos keytab.

sudo vi /etc/sysconfig/ldap

Create the OpenLDAP kerberos keytab, the the host's principal key and the autofsclient key while we're in the kadmin dialogue. IMPORTANT : notice how we place the host/ and autofsclient/ principals in the /etc/krb5.keytab while the ldap/ principal gets stored in /etc/openldap/krb5.keytab.

sudo kadmin -p drobilla/admin@COMPANY.COM
kadmin:   addprinc -randkey ldap/bob.company.com@COMPANY.COM
kadmin:   ktadd -k /etc/openldap/krb5.keytab ldap/bob.company.com@COMPANY.COM

kadmin:   addprinc -randkey host/bob.company.com@COMPANY.COM
kadmin:   ktadd -k /etc/krb5.keytab host/bob.company.com@COMPANY.COM

kadmin:   addprinc -randkey autofsclient/bob.company.com@COMPANY.COM

kadmin:   ktadd -k /etc/krb5.keytab autofsclient/bob.company.com@COMPANY.COM
kadmin:   exit

Fix permissions on the new Kerberos keytab. The goal here is to let the ldap group be able to read the ldap/ principal stored in the keytab.

sudo chown root:ldap /etc/openldap/krb5.keytab 

sudo chmod 640 /etc/openldap/krb5.keytab

Restart the slapd(8) daemon.

sudo /etc/init.d/slapd restart

Test the SASL GSSAPI authentication.

kdestroy
kinit -p drobilla/admin@COMPANY.COM
ldapwhoami

Consumer DIT Initial Load

One last step before we start the replication is to load the DIT from our provider into our consumer. It's not required, but if your DIT is large, this will save quite a lot of time. Do to this, follow these steps :

Connect to the provider.

ssh alice.company.com

Create a new LDIF file with the entire DIT of the provider.

sudo slapcat | tee -a /tmp/provider.slapcat.ldif

Transfer the LDIF file over to the consumer.

scp /tmp/provider.slapcat.ldif bob.company.com:/tmp

Remove the temporary file. After all, it's the entire DIT that's in there in clear text...

sudo rm /tmp/provider.slapcat.ldif

Connect to the consumer.

ssh bob.company.com

Stop slapd.

sudo /etc/init.d/slapd stop

Destroy the database, but save the DB_CONFIG file.

sudo cp /var/lib/ldap/DB_CONFIG /tmp
sudo rm -rf /var/lib/ldap
sudo mkdir /var/lib/ldap
sudo mv /tmp/DB_CONFIG /var/lib/ldap

Load the provider LDIF file into the consumer's database. Notice the « -w » switch to slapadd(8C) which will write syncrepl context information. Once all entries are added, the contextCSN will be updated with the greatest CSN in the database. That's pretty handy in our case :)

sudo slapadd -l /tmp/provider.slapcat.ldif -w

Again, remove the temporary file. After all, it's the entire DIT that's in there in clear text...

sudo rm /tmp/provider.slapcat.ldif

Start the consumer daemon.

sudo /etc/init.d/slapd start

Check to see if the entire DIT is now on the consumer machine?

ldapsearch -xZWD cn=admin,dc=company,dc=com -b dc=company,dc=com -H ldap://bob.company.com

Check to see if the SASL GSSAPI user has the proper ACLs to this DIT on the consumer?

kinit -p drobilla/admin@COMPANY.COM
ldapsearch -ZLLLb dc=company,dc=com -H ldap://bob.company.com

Replication Test

We now have a TLS and SASL GSSAPI enabled OpenLDAP server bob.company.com configured as the consumer of our provider alice.company.com machine. Let's see if it works? Do test this, connect to the provider and change something. In this example, we will change our test.user's shell.

Connect to the provider server.

ssh alice.company.com

Check the current value for loginShell.
ldapsearch -LLLZb cn=test.user,ou=users,dc=company,dc=com loginShell

loginShell: /bin/bash

Change the loginShell value to /bin/sh.

ldapmodify <<-EOF

dn: cn=test.user,ou=users,dc=company,dc=com

changetype: modify

replace: loginShell

loginShell: /bin/sh

EOF

Keep an eye on the slapd.log file. You should now see these lines on the consumer :

slapd[6620]: do_syncrep2: rid=000 cookie=rid=000,csn=20120608192235.282075Z#000000#000#000000
slapd[6620]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
slapd[6620]: syncrepl_entry: rid=000 be_search (0)
slapd[6620]: syncrepl_entry: rid=000 cn=test.user,ou=users,dc=company,dc=com
slapd[6620]: slap_queue_csn: queing 0xa1601040 20120608192235.282075Z#000000#000#000000
slapd[6620]: slap_graduate_commit_csn: removing 0xa16050c8 20120608192235.282075Z#000000#000#000000
slapd[6620]: syncrepl_entry: rid=000 be_modify cn=test.user,ou=users,dc=company,dc=com (0)
slapd[6620]: slap_queue_csn: queing 0xa1601040 20120608192235.282075Z#000000#000#000000
slapd[6620]: slap_graduate_commit_csn: removing 0xa1604a48 20120608192235.282075Z#000000#000#000000

And if you query the consumer, you should see that the loginShell has indeed replicated to the consumer.

ssh bob.company.com

ldapsearch -LLLZb cn=test.user,ou=users,dc=company,dc=com loginShell
loginShell: /bin/sh

Success! :)

Consumer Kerberos Slave Setup

The whole point of replicating our DIT is to have two copies of it should the provider fails. But our DIT also supports our Kerberos infrastructure. We must thus make sure that our consumer can also act as a Kerberos slave should our provier -and Kerberos master- fails.

To enable the consumer machine to become a Kerberos slave, we must of course install the required packages and we already did that (see above). We must then send several provider's Kerberos files over to our consumer. Those files are the Kerberos private key and the Kerberos stash keyfile.

ssh alice.company.com

sudo scp /var/kerberos/krb5kdc/.k5.COMPANY.COM drobilla@bob.company.com:/tmp

sudo scp /etc/krb5.d/stash.keyfile drobilla@kong.caprion.com:/tmp

Now connect to the consumer and move the files to their proper locations and fix permissions.

ssh bob.company.com

sudo mv /tmp/.k5.COMPANY.COM /var/kerberos/krb5kdc

sudo mkdir /etc/krb5.d

sudo mv /tmp/stash.keyfile /etc/krb5.d

sudo chown -R root:root /var/kerberos/krb5kdc /etc/krb5.d

Make sure to edit the Kerberos ACL file on the consumer. This file contains a single line.

sudo vi /var/kerberos/krb5kdc/kadm5.acl

*/admin@COMPANY.COM *

Edit the consumer's Kerberos kdc.conf file.

sudo vi /var/kerberos/krb5kdc/kdc.conf

Grab a copy of the krb5.conf file on the provider machine.

scp alice.company.com:/etc/krb5.conf /tmp

sudo mv /tmp/krb5.conf /etc

sudo chown root:root /etc/krb5.conf

Modify the database to include several new indexes which will help the Kerberos LDAP lookups. While we're at it, let's also add several other required indexes :)

vi ~/ldap/kerberos.indexes.ldif
ldapmodify -xZWD cn=admin,dc=company,dc=com -H ldap://bob.company.com -f ~/ldap/kerberos.indexes.ldif

Check to see if we have the new indexes in place?

ldapsearch -ZLLLb olcDatabase={1}bdb,cn=config olcDbIndex

Make sure the krb5kdc daemon is running when the machine boots. Note that we do not run the kadmin daemon on the slave KDC.

sudo chkconfig krb5kdc on

Start the krb5kdc daemon.

sudo /etc/init.d/krb5kdc start

Consumer Backup

Don't forget to backup the consumer now that it's working. See this blog post on how to do just that.

Check Replication Status

Sometimes the log files are not clear in order to determine if the replication is finished or not. To check this, simply query both the provider and the consumer servers for the contextSCN. If the values are the same, then replication is finished.

kinit -p drobilla/admin@COMPANY.COM

ldapsearch -LLLH ldap://alice.company.com -s base -b "dc=company,dc=com" 
dn: dc=company,dc=com
contextCSN: 20140207211614.110524Z#000000#000#000000

ldapsearch -LLLH ldap://bob.company.com -s base -b "dc=company,dc=com" 
dn: dc=company,dc=com
contextCSN: 20140207211614.110524Z#000000#000#000000

As we can see, both contextSCN values are the same, so we're good.

Client Configuration

Now that we have two OpenLDAP servers, we need to configure the client machines to use them both. So perform these configuration changes to all your LDAP client machines :

ssh client.company.com

Change the sudoers LDAP configuration file.

sudo vi /etc/ldap.conf

Change the system LDAP configuration file.

sudo vi /etc/openldap/ldap.conf

Change the client's nslcd configuration file.

sudo vi /etc/nslcd.conf

Change the pam_ldap configuration file.

sudo vi /etc/pam_ldap.conf

Change the Kerberos configuation file.

sudo vi /etc/krb5.conf

As you can see, this requires quite a few changes. So you should probably script these changes. I usually setup an admin server that runs Apache with configuration files on it. Clients can thus simply wget them. Easy. Or you can use Puppet. Even better!

With the new client configuration, try shutting down the LDAP and Kerberos services on alice.company.com and see if the clients can still work by using bob.company.com.

Troubleshooting

olcLogLevel

If you're not sure about the syncrepl engine, then enable logging for this.

ldapmodify -Z <<-EOF
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats sync
EOF

You can do this on both the consumer and the provider.

syncrepl_message_to_entry

If you get this type of error :

syncrepl_message_to_entry: rid=000 mods check (objectClass: value #1 invalid per syntax)

It means that you're missing a schema in on the consumer server. Of course the rid=000 can be different on your server. It's the replication ID configured in the olcSyncrepl: config of the consumer server. Compare the schemas on both machines and fix the consumer so that it has exactly the same schemas as the provider. So, the first thing you must do is check the schemas on the provider :

ssh alice.company.com

ldapsearch -ZLLLb cn=schema,cn=config dn

Then connect to the consumer and check the schemas there :

ssh bob.company.com

ldapsearch -ZLLLb cn=schema,cn=config dn

If the consumer is missing some schemas present on the provider, then add those missing schemas to the consumer and try the replication again.

Missing DB_CONFIG, but it's there?

Your logs show these error messages when you start slapd :

slapd[7722]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap/accesslog: (14).#012Expect poor performance for suffix "cn=accesslog".
slapd[7722]: slapd starting
slapd[7722]: <= bdb_equality_candidates: (objectClass) not indexed
slapd[7722]: <= bdb_inequality_candidates: (reqStart) not indexed

But when you look into the /var/lib/ldap/accesslog directory, there is a DB_CONFIG file and the permissions are good.

What's the problem?

Well, it's simply that the HDB has the wrong « objectClass: olcDdbConfig ». It should be « objectClass: olcHdbConfig ». Notice the small, but very critical, difference?

That's it! 

That means we finished our initial goals :

1. Install OpenLDAP 2.4.
2. Configure Transport Layer Security (TLS).
3. Manage users and groups in OpenLDAP.
4. Configure pam_ldap to authenticate users via OpenLDAP.
5. Use OpenLDAP as sudo's configuration repository.
6. Use OpenLDAP as automount map repository for autofs.
7. Use OpenLDAP as NFS netgroup repository again for autofs.
8. Use OpenLDAP as the Kerberos principal repository.
9. Setup OpenLDAP backup and recovery.
10. Setup OpenLDAP replication.

The next set of goals are coming. I want to enable Referential Integrity in the LDAP DIT (i.e. when you delete a user it is also deleted from the various groups he's part of). I'm also interested in pulling information, such as users, passwords and grous from Active Directory servers and thus remove Samba.

HTH, Let me know if I made a mistake as this post was not easy to put together.

DA+

References

• Delta-syncrepl Provider configuration
• OpenLDAP consumer on Debian squeeze