OpenLDAP Replication with LDAP sync
Posted by admin on 24 May 2009 | Tagged as: Centos 5.x, IT Stuff, Linux, authentication, ldap, openldap
First some background stuff - this work was all done on Centos 5.3 i386 using openldap 2.3. You need a basic working OpenLDAP configuration such as in my notes Configuring OpenLDAP. The other thing you need to be aware of when setting up LDAP sync with the Centos 5.x distro is that, like RedHat, the syncprov module is statically linked with slapd which means that the notes that refer to using the moduleload functionality with syncprov.la do not apply to Centos. LDAP sync replication is essentially a “pull” replication model which is different from the deprecated slurpd’s “push” replication.
These notes relate to a simple ldap sync setup with 1 provider and 1 consumer. In LDAP sync jargon a “provider” is the source of updates and a “consumer” is the openldap which is to be updated. There are various models for ldap sync, in this version which is the simplest all the data for all records are copied when there is a change but there are more sophisticated models which only copy the changes. This can be useful if you have a large directory.
The provider has only 2 configuration directives for setting checkpoints on the contextCSN and configuring the session log. Because ldap sync search is subject to access control you must ensure proper acl privileges are set for the replicated content.
In the provider’s slapd.conf add:
index entryCSN,entryUUID eq,pres
then add:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
limits dn.exact="cn=syncuser,dc=mydomain,dc=com" size=unlimited time=unlimited
The limits entry is a good idea to help keep the consumer in sync during a large modification.
I also added a syncuser to my directory with an ldif like:
dn: cn=syncuser,dc=mydomain,dc=com
uid: syncuser
cn: syncuser
sn: syncuser
objectClass: inetLocalMailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: e1NTSEF9NERla1JTSWwxa0tDU0FHRU5SUVZudVh4L1VyamJ1dFQ=
shadowLastChange: 14387
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 501
homeDirectory: /home/syncuser
gecos: syncuser
On the consumer add in slapd.conf:
index entryCSN,entryUUID eq,pres
and then:
syncrepl rid=101
provider=ldap://ldap.mydomain.com:389
type=refreshOnly
interval=00:01:00:00
searchbase="dc=mydomain,dc=com"
filter="(objectclass=*)"
attrs="*,+"
scope=sub
schemachecking=off
bindmethod=simple
binddn="cn=syncuser,dc=mydomain,dc=com"
credentials=secret
where:
rid=101 is the id for this query; it must be unique across all consumers
provider=xx is the server this consumer will query
type=refreshOnly means that after the initial sync the sync query will rerun at the time specified by interval
interval=00:01:00:00 means the sync query will reschedule after 1 hour
searchbase=xx the start at the root of the tree
filter="(objectclass=*)" look for everything
scope=sub search recursively
attrs="*,+" copy all attributes which is the default setting so there is no need to specify this
schemachecking=off the provider should already be doing this
binddn=xx is the user on the provider who the consumer will use for its queries
bindmethod=simple use plaintext passwords
credentials=secret the syncuser password
There are other options, instead of type=refreshOnly you could have type=refreshAndPersist which means that after the initial query the sync will stay open and any other changes will be transferred immediately. If you change your type setting you may want to remove the interval setting and add retry="60 +" which means that if network connectivity is lost between the consumer and the provider, the consumer will try every 60 seconds indefinitely to re-establish a network connection with the provider.
Now restart slapd on the provider and then on the consumer.
