Installare i pacchetti Debian

• slapd
• ldap-utils

Viene chiesta la password di amministratore LDAP, potrà essere diversa da quella dell'amministratore master?

• LDAP Sync Replication
• Secure LDAP replication

Nella sezione globale di /etc/ldap/slapd.conf si aggiunge il caricamento del modulo syncprov (i moduli sono in /usr/lib/ldap/):

moduleload syncprov

Nella sezione relativa al database da esportare si dichiara l'uso dell'overlay syncprov:

database        hdb
overlay         syncprov

/etc/ldap/slapd.conf

Si deve aggiungere la dichiarazione del rootdn e il necessario per la replica

rootdn "cn=admin,dc=rigacci,dc=org"

syncrepl rid=001
    provider=ldaps://ldap.rigacci.org/
    tls_reqcert=allow
    type=refreshAndPersist
    retry="60 +"
    searchbase="dc=rigacci,dc=org"
    filter="(objectClass=*)"
    scope=sub
    attrs="*"
    schemachecking=off
    bindmethod=simple
    binddn="cn=admin,dc=rigacci,dc=org"
    credentials=SuperSecret

Tutte le ACL configurate sul master devono essere riportate anche nella configurazione dello slave (se si vuole utilizzare la stessa politica di accesso).

Volendo essere paranoici, l'accesso al master LDAP potrebbe avvenire con credenziali diverse da quelle di admin, basta creare l'account e dare le giuste credenziali sul master.

Se lo slave viene interrogato dai suoi client via ldaps, è necessario generare un certificato ed utilizzarlo:

TLSCertificateFile     /etc/ldap/tls/slaveldap.rigacci.org.pem
TLSCertificateKeyFile  /etc/ldap/tls/slaveldap.rigacci.org.pem

/etc/ldap/ldap.conf

Per accettare certificati autofirmati dal server (ed eventualmente dei mismatch tra hostname e resolv DNS):

TLS_REQCERT     never

Durante la replica lo slave si rivolge al master in qualità di client, se è necessario possedere un certificato (nel caso in cui il master accetti solo client certificati) è necessario ottenere il certificato firmato dalla CA e il certificato della CA stessa. Per utilizzarli è necessario configurare /etc/ldap/ldap.conf e assicurarsi che durante la replica siano impostate le variabili di ambiente LDAPTLS_CERT e LDAPTLS_KEY

Verificare che lo slave possa accedere al master via ldaps, che le credenziali siano giuste, ecc.:

ldapsearch -v -x -H "ldaps://ldap.rigacci.org/" -D "cn=admin,dc=rigacci,dc=org" -W \
    -b "dc=rigacci,dc=org"

Errore di replica, nel log dello slave si legge:

slapd[2857]: do_syncrep2: rid=123 got search entry without Sync State control
slapd[2857]: do_syncrepl: rid=123 retrying

sul master si trova un errore corrispondente:

slapd[2260]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1

soluzione: sul master manca la direttiva globale moduleload syncprov e la dichiarazione per il database overlay syncprov.

Altro errore, sullo slave si legge:

slapd[3068]: syncrepl_message_to_entry: rid=123 mods check 
    (objectClass: value #4 invalid per syntax)

in questo caso sullo slave manca il samba.schema (fornito come esempio dal pacchetto samba-doc) necessario ad accettare il database:

include         /etc/ldap/schema/samba.schema

Sul server slave si legge il seguente errore:

slapd[3448]: /etc/ldap/slapd.conf: line 84: rootDN must be defined before syncrepl may be used

il problema è chiaro: sullo slave è indispensabile definire il rootdn.