RE: Backend authentication

["Pierangelo Masarati" <ando@sys-net.it>]

> Howard Chu wrote:
>>
>> Always use the latest release when creating a fresh
>> installation. 2.1.22 is old.
>>
> I am using SuSE Linux 9.0 and that comes with OpenLDAP 2.1.22.  If I
> stick with this version I will get automatic patches and security fixes
> and will not need to maintain the package myself.  Is there a very good
> reason to move to a newer version of OpenLDAP?

new versions of a "stable" package are mainly intended
for bug fixing and maintenance.  2.1.22 is pretty frozen,
so it is likely to get very little new features, which
are targeted for 2.2, but may get bug fixes.  There are
three more versions available, and others might follow,
because bugs are getting fixed.  You can browse thru the
CHANGELOG and see if these changes are important to you,
but the essential reason to stay up to date with releases
is that at least they fix known bugs.  There might be
more, and new ones may be introduced, of course.


>
>> > However, I would like
>> > to utilize the "master" server for authentication purposes so that
>> when users change their "master" password they can still log into my
>> local LDAP
>> > server.
>>
>> > Is this possible?
>>
>> Yes, using back-ldap.
>
> I envisage the user objects in the "master" and local LDAPs will have
> the same (unique) cn attributes but different dn.  The tree structure in
> the "master" LDAP uses the cn,ou,o model rather than the cn,dc,dc model.

back-ldap allows to remap attribute types and DNs;
see the REWRITING section of slapd-meta(5) (back-ldap
and back-meta share the same mapping code).

>
>
> I suppose back-ldap will need to associate objects across the two trees,
> using some sort of map or search filter.
>
> Please can you provide an example of how to set all this up.

see slapd-meta(5).

>
>>
>> > Ideally I would prefer to setup a "shadow" system: if an
>> object has a
>> > value in the local server then use that, otherwise lookup
>> the value in
>> > the "master" server.  Again, is this possible?
>>
>> Almost, in 2.2.4. The proxy-cache overlay in 2.2.4 provides
>> part of this, but it doesn't allow you to create objects
>> locally. I suppose it may be feasible to extend the overlay,
>> but there are issues wrt the local and remote trees getting
>> out of sync.
>
> All of the user objects do already exist in the "master" LDAP, so I
> don't need to create objects but I do need to extend the schema on my
> local LDAP. I guess if I use the proxy-cache overlay in 2.2.4 the dn for
> each object will need to be the same.
>
> Again, if you can provide any pointers on this I would be truly
> grateful.
>
>> If you can restrict your local objects to a separate subtree
>> from the remote master, then you can just use back-ldap glued
>> to a local backend.
> I plan to use the local LDAP server for NSS and SAMBA, so I will need to
> create local objects and extend existing "master" user objects.
>
> Your help is much appreciated.

Entries cannot be distributed (yet?), that is,
different entries can reside on different servers
and get glued together when presented to the client,
but a single entry cannot be distributed (e.g. some
of its attributes on a server and some on another
one).  So, if you need to extend user objects you'll
need to create a local copy and modify it.  You'll
probably need to create your own procedures for this.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it