LDAP [was: Re: [plug] NFS]

Craig Ringer craig at postnewspapers.com.au
Sat May 31 18:04:14 WST 2003


  > A general note (probably not applicable to a home-office scenario) is
> that OpenLDAP's slurpd replication works well (when it works).

It's a bit fussy to set up, but once it's running it works well. The 
method I use involves adding a "replica master" user to the db, 
generally outside the normal user tree. slapd on the master is then 
configured to replicate to a given host (all on one line):

replica host=bucket.localnet binddn="cn=repmaster,dc=localnet" 
bindmethod=simple credentials="repmaster"

while the client sets the "updatedn" and "updateref" values to accept 
replication from the remote slurpd and forward modifications to the 
master server:

updatedn cn=repmaster,dc=localnet
updateref ldap://10.0.0.10/dc=localnet

Then, I stop slapd, use slapcat > /tmp/dbfile, copy the db to the new 
machine then use slapadd to read it back. This works well even if the 
two hosts are running different slapd versions or are compiled against 
different db libraries.

You'll usually want to remove any pending "rejected" replications too.

Put it this way - its easy enough that I'm running it on my home network 
(OK, that's because we have several users, several machines, and I need 
to know it well for work anyway). One of the big advantages is that each 
machine can refer to its local slapd for user accounts - great if you've 
borrowed the ethernet cable to do something else. Its also (marginally) 
faster because the slapd is on the local machine.

> As a general authentication note, one 'save the day' feature is if your
> authentication system allows multiple auth methods to be used. Thus if
> your LDAP authentication breaks, you have a "fall back" authentication
> method. 

This can be done pretty easily with PAM on linux, and is pretty much the 
default when using ldap authentication. OTOH, it means you still have to 
maintain users in /etc/passwd and /etc/shadow, so its usually only worth 
bothering with for a few critical users, eg the person doing the ldap 
dir admin.

 > People often aim (and I
> think Craig mentioned something along these lines) to ensure that each
> machine's root account is always accessible.

Unfortunately, its not all that easy to do. PAM has the nasty habit of 
assuming that an error on any auth method means the user should not be 
authenticated, rather than that more methods should be tried. As a 
result, a box that loses its ldap server may refuse to authenticate 
local-only accounts. I think this is fixable with the right parameters 
in PAM, but I haven't had time to really dig and find out yet.

Craig Ringer



More information about the plug mailing list