2.0: Configuring LDAP

From SambaWiki
Revision as of 13:34, 25 January 2007 by Asender (talk | contribs)

1.0: Configuring Samba

2.0: Configuring LDAP

3.0: Initialization LDAP Database

4.0: User Management

5.0: Heartbeat HA Configuration

6.0: DRBD

7.0: BIND DNS



Table of Contents

1.1 smb.conf PDC

1.2 smb.conf BDC

1.3 /etc/hosts

1.4 Samba Security


underline text, or write it in small caps.


It is necessary to use LDAP as our backend to Samba which provides replication to the Backup Domain Controllers.

There are two methods for providing replication, using openldap’s “slurpd” to provide Master / Slave operation, the database is pushed to slaves which is defined in slapd.conf on the master LDAP server; here is an example of the original way defined in 2.1: slapd.conf Master.

replica     host=192.168.0.3:389
            suffix="dc=differentialdesign,dc=org"
            binddn="cn=syncuser,dc=differentialdesign,dc=org"
            bindmethod=simple credentials=SyncUser

To bind to the database the slave replicas will need to use “syncusers’s” password defined above as “credentials=SyncUser“. Initially you will need to manually populate the slave database as defined in section 3.4 Database Replication.

The main restriction with using this original design is the ldap database needs to be restarted on both the master and the slave when adding additional replicas.

LDAP Replication Configuration

Master

Slave(s)

A master LDAP database that is replicated real time to the backup domain controller.

A slave LDAP database that provides load balance authentication, and can be used as a failover if the master becomes unavailable.


LDAP Replication Configuration

Provider

Consumers(s)


A provider LDAP database that has the most updated version of the database.

A consumer requests an update at a set interval, and provides load balancing.

The ulternative is to use syncrepl which is included in the ldap daemon. This means we no longer need to run slurpd daemon which is to replicate the database.

There are 2 main types of syncrepl operation: “refeshOnly” operation where the consumer requests an update from the provider at set time interval defined as “interval=00:00:10:00” which would pull the provider every 10 minutes. The more desirable way is to use delta-syncrepl; this provides a mode known as “refrshAndPersist” which provides a consistent connection. Instead of using a time interval to poll the provider we have the parameter “retry="30 10 300 +" which means it will retry 10 times every 30 seconds, then every 300 seconds “+” indicates indefinite number of retries.


If you are using Syncrepl with version 2.2 Openldap delta-syncrepl is known to be very buggy, so you are better sticking with standard syncrepl refreshOnly mode.

Additionally the ldap daemon does not need to be restarted on the provider; the consumer will request it by polling the provider at a set interval.