Atlantic Linux Blog

LDAP Replication on Debian 4.0 (etch) with syncrepl

We’re making increasing use of LDAP in our office infrastructure. I spoke about a simple Samba PDC configuration last year. The Samba team recommend using LDAP as your Samba password backend if you require all of the account capabilities supported by Samba or if you have a large userbase. We initially started using the LDAP backend to give us access to all of these account capabilities including per-user profile capabilities (for setting various user policies).

Since migrating to LDAP, I have planned to move us to a more redundant architecture courtesy of our LDAP server’s replication feature. We’re using the OpenLDAP LDAP server. There are a variety of open source and commercial LDAP servers out there – OpenLDAP is the main open source one. We’ve found it works well for small and medium sized business, there have been some question marks raised over it’s performance for larger environments but we haven’t run into any problems yet.

Our master LDAP server has been running for some time now and provides a backend for our Samba PDC as well as a login server for our Linux desktops and a backend for various internal tools including our bugzilla system, our subversion server and so on. If you have anything more than a very simple network infrastructure, it makes sense to move to a unified authentication system built around LDAP – it drastically simplifies access management to your various systems (particularly when staff are starting with or departing from your organisation).

OpenLDAP originally used a push model for replication where the LDAP master server pushed it’s data periodically to the LDAP slave server using a module called slurpd. Newer versions of OpenLDAP have introduced a pull model for replication using a module called syncrepl. We’re using Debian 4.0 on our production systems and it comes with OpenLDAP 2.3 which supports both models. According to the OpenLDAP 2.4 replication documentation, from 2.4 onwards slurpd support has been removed. With this in mind, we opted to go with the syncrepl approach to LDAP replication with a view to future-proofing our environment.

Our master LDAP server configuration is as follows (largely similar to the standard configuration supplied by Debian). The main changes from the standard OpenLDAP configuration are for Samba (including the schema line and access protection for some of the Samba data highlighted in blue).

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel sync
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
checkpoint 512 30

database bdb
suffix “dc=example,dc=com”
directory “/var/lib/ldap”
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500

index objectClass eq
lastmod on

access to attrs=userPassword,shadowLastChange,gecos,sambaNTPassword,sambaLMPassword
by dn=”cn=admin,dc=example,dc=com” write
by anonymous auth
by self write
by * none

access to dn.base=”” by * read

access to *
by dn=”cn=admin,dc=example,dc=com” write
by * read

password-hash {MD5}

To convert this LDAP master to a provider (the OpenLDAP term for the server which provides data to a syncrepl consumer or slave server) we add the highlighted lines to our config as follows,

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel sync
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
checkpoint 512 30

database bdb
suffix “dc=example,dc=com”
directory “/var/lib/ldap”
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500

index objectClass eq
lastmod on

access to attrs=userPassword,shadowLastChange,gecos,sambaNTPassword,sambaLMPassword
by dn=”cn=admin,dc=example,dc=com” write

by dn=”uid=replicant,ou=Users,dc=example,dc=com” read

by anonymous auth
by self write
by * none

access to dn.base=”” by * read

access to *
by dn=”cn=admin,dc=example,dc=com” write
by * read

password-hash {MD5}

rootdn “cn=admin,dc=example,dc=com”
moduleload syncprov
index entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 200

There are a number of changes here

access to attrs=userPassword,shadowLastChange,gecos,sambaNTPassword,sambaLMPassword
…
by dn=”uid=replicant,ou=Users,dc=example,dc=com” read
…

We have added a new user to our LDAP database uid=replicant,ou=Users,dc=example,dc=com and are granting them read access to the various password fields that most LDAP users won’t have access to but which we allow to be read for the purposes of copying to our consumer or slave server. You can add the above user using any of the standard LDAP management tools – we used the IDEALX samba tools as follows,

smbldap-useradd replicant -P

We then configured the syncprov overlay which is responsible for tracking changes to the LDAP database and marking them such that the slave server can identify them and copy them. The module takes various arguments for the number and frequency of checkpoints. Note that we’re also adding some indexes for the fields used by this module to optimise reading of this data during replication operations.

rootdn “cn=admin,dc=example,dc=com”
moduleload syncprov
index entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 200

Thats about it on the master / provider. You should restart the server after applying these changes.

On the slave server, we took our original master server configuration (the first one above) and added the following section to enable replication

syncrepl rid=1
provider=ldap://master.example.com:389
type=refreshAndPersist
searchbase=”dc=example,dc=com”
filter=”(objectClass=*)”
scope=sub
schemachecking=off
bindmethod=simple
binddn=”uid=replicant,ou=Users,dc=example,dc=com”
credentials=ReplicantPassword

The consumer / slave is configured to connect to the master / provider master.example.com on port 389. The filter and searchbase ensure that all data with a base of dc=example,dc=com will be replicated. The consumer connects to the provider using the specified user uid=replicant,ou=Users,dc=example,dc=com and password ReplicantPassword which we’ve already given full read access on the LDAP master.

After making these changes on the slave, you can restart the slave OpenLDAP server. Note that we have loglevel sync on both servers which results in detailed logging of sync operations to /var/log/syslog. You should see details of the sync operations occurring. After a short period, you should be able to retrieve the same details from your consumer / slave server using the ldapsearch tool or similar e.g.

ldapsearch -H ldap://master.example.com/ -xLLL -b ‘dc=example,dc=com’ -D “uid=replicant,ou=Users,dc=example,dc=com” -wReplicantPassword uid=anExampleUid

and

ldapsearch -H ldap://slave.example.com/ -xLLL -b ‘dc=example,dc=com’ -D “uid=replicant,ou=Users,dc=example,dc=com” -wReplicantPassword uid=anExampleUid

should provide exactly the same results (except for the entryUUID and modifyTimestamp fields) on both servers. In particular, you should also be seeing the userPassword and gecos fields on both the master and the slave. If you aren’t, you may have omitted the access grant to your replication account.

Once you have this running, all that remains is to modify any services using LDAP to reference both your master and slave LDAP servers.

For samba:

passdb backend = ldapsam:”ldap://master ldap://slave”

For pam_ldap

uri ldap://master/ ldap://slave/

and so on.

Finally, when you’ve verified that all these settings have been applied and you’re configuration is working, trying shutting down your master LDAP server and verifying that your systems still allow authentication and that your Samba server continues to allow users access.

Well done, you’ve just increased the redundancy of your IT infrastructure. In my next posting, we’ll look at setting up a Samba Backup Domain Controller (BDC) for even more redundancy.

4 Comments to LDAP Replication on Debian 4.0 (etch) with syncrepl