Step 4 Replication

Full blown authentication system

  1. Installation and basic configuration of OpenLDAP and MITv5 Kerberos
  2. Linking OpenLDAP with MITv5 Kerberos
  3. Linking FreeRADIUS
  4. Replication
  5. Hardening your setup
  6. Configure your clients
  7. Varia

LDAP replication

On the provider, create the following scheme:

# Add indexes to the frontend db.
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
-
add: olcDbIndex
olcDbIndex: entryUUID eq
#Load the syncprov and accesslog modules.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
-
add: olcModuleLoad
olcModuleLoad: accesslog

# Accesslog database definitions
dn: olcDatabase={2}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=example,dc=com
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart

# Accesslog db syncprov.
dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE

# syncrepl Provider for primary db
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE

# accesslog overlay definitions for primary db
dn: olcOverlay=accesslog,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
olcAccessLogPurge: 07+00:00 01+00:00

Add the following lines to /etc/apparmor.d/local/usr.sbin.slapd:

/var/lib/ldap/accesslog/ r,
/var/lib/ldap/accesslog/** rwk,
sudo -u openldap mkdir /var/lib/ldap/accesslog
sudo -u openldap cp /var/lib/ldap/DB_CONFIG /var/lib/ldap/accesslog
sudo service apparmor reload
Load the new scheme and restart LDAP:
sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f provider_sync.ldif
sudo service slapd restart

On the consumer (in this case consumer.example.com), create the following scheme:

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcSyncRepl
olcSyncRepl: rid=0 provider=ldap://provider.example.com bindmethod=simple binddn="cn=admin,dc=example,dc=com" 
 credentials= searchbase="dc=example,dc=com" logbase="cn=accesslog" 
 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on 
 type=refreshAndPersist retry="60 +" syncdata=accesslog
-
add: olcUpdateRef
olcUpdateRef: ldap://provider.example.com

Add this scheme to LDAP:

sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f consumer_sync.ldif

Kerberos replication

To replicate (=propagate) Kerberos, first add a host principal for both hosts on the master (provider.example.com):

kadmin.local 
addprinc host/consumer.example.com
addprinc host/example.com

Next (still in kadmin), add the host key of the master to the default keytab, and the host of the slave to /tmp/krb5.keytab:
inadmissible

ktadd host/provider.example.com
ktadd -k /tmp/krb5.keytab host/consumer.example.com

Copy (via scp) the keytab and configuration files to the slave:

/tmp/krb5.keytab
/etc/krb5kdc/kadm5.acl 
/etc/krb5kdc/kdc.conf
/etc/krb5kdc/stash
/etc/krb5.conf

On the slave (consumer.example.com), install the necessary kerberos packages:

apt-get install krb5-kdc krb5-admin-server

If you didn’t get it right the first time and you want to reinstall:

apt-get remove --purge krb5-kdc krb5-admin-server krb5-config

It could be that you need to search for files that were left behind and delete them:

find / -name 'krb5*'

Most of the time, these files/directories are /etc/krb5.keytab and /var/lib/krb5kdc/.
Copy all the scp’ed files to the correct location, and create a new database:

kdb5_util create

Insert a passwd (doesn’t matter which one, you’ll overwrite it when replicating the master KDC). Add a file in /etc/krb5kdc:

vim /etc/krb5kdc/kpropd.acl
host/provider.example.com@EXAMPLE.COM

Start kpropd in debug mode:

kpropd -dS -r EXAMPLE.COM

Back on the master (provider.example.com), make a dump of the principal database:

kdb5_util dump /etc/krb5kdc/slave_trans

Propagate the database to the slave:

kprop -f /etc/krb5kdc/slave_trans -r EXAMPLE.COM consumer.example.com

If your system is firewalled, don’t forget to open port 754 on your slave.
If the propagation (= replication) succeeded, go back to the slave and configure xinetd (if you don’t have it, install it: apt-get install xinetd, or use inetd instead), to start kpropd from startup:

vim /etc/xinetd.d/kpropd
service krb_prop
{
socket_type = stream
wait    = no
user    = root
server  = /usr/sbin/kpropd
only_from = w.x.y.z
log_on_success = PID HOST EXIT DURATION
log_on_success = PID HOST
}

Restart xinetd:

/etc/init.d/xinetd restart

Run kpropd hourly, using crontab. In /etc/cron.hourly/ put krb_prop with the following lines:

#!/bin/sh
/usr/sbin/kdb5_util dump /etc/krb5kdc/slave_datatrans
/usr/sbin/kprop -r EXAMPLE.COM -f /etc/krb5kdc/slave_datatrans consumer.example.com

This was step 4. To proceed, go to step 5.