RE: Yet Another Beginner Question

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Jan-Piet Mens [mailto:jpm@Retail-SC.com]

> Hello Howard,
>
> that is an interesting view; I hadn't thought of that one. What
> comes to mind
> though, is that if your source of data is (e.g.) /etc/passwd directly, how
> do you, if at all, synchronize it on other systems ? What I mean
> is that using
> NSS for example, I can have a multitude of LDAP slave servers as
> backups. I
> don't immediately see the possibility of doing that with your
> solution. Can you
> give us a little insight as to how you cope with failures on your
> master /etc/passwd
> system ?

Excellent questions. There is a management framework that is used to
maintain
synchronization for a network of managed systems. In principle you can use
exactly the same mechanisms as you would use in the NSS + LDAP slaves
scenario. I.e., by observing the lastmod date and maintaining checksums on
entries in each file, you can generate a replog that can be used with slurpd
to update all of your other machines. There is of course a fanout problem if
you want to keep a large number of machines in sync. This isn't the exact
approach we use, but I think by pointing it out you can understand that it's
a solvable problem, and we have solved it.

Failures on the master /etc/passwd system just mean that single machine is
down and password changes won't be propagated until it returns. All other
machines continue to operate normally.

> Why did you develop your UnixAuth agent ? Is it because the
> passwd backend back-passwd
> doesn't support writing ? Would it not have been easier to
> implement that ?

Yes, it would have been simpler, but that would miss the point. We have an
agent framework that we can rapidly deploy to manage any security system; we
have agents for NT (workstations and PDCs) and Oracle, for example. Just
extending back-passwd would not have made it any easier to develop support
for other platforms.

Also, just fleshing out back-passwd on its own is a dangerous thing to do
from a security standpoint. Many people are using LDAP as a general
public-information repository, and as such run with minimal security
controls. It would be inappropriate to even suggest plugging an
administrative interface into such an unprotected LDAP service. Without TLS
or SASL protection on the connections, you really don't want a module that
has write access to /etc/passwd. Our agent framework requires TLS and is
hardcoded to do client certificate checking, so that we have a measure of
protection from misconfiguration.

> And of course: is UnixAuth available to us mortals ? :-)

Just visit us at www.symas.com and contact us from there.
>
> Regards,
> 	-JP
>
>
> On Fri, 29 Mar 2002, Howard Chu wrote:
>
> > > -----Original Message-----
> > > From: owner-openldap-software@OpenLDAP.org
> > > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Mark Lehrer
> >
> > > Also, what is the best way to deal with keeping both the ldap database
> > > and /etc/passwd, /etc/shadow, and /etc/group, /etc/aliases in sync?  I
> > > would prefer to keep using the standard adduser tools, and vi to
> > > handle the aliases; would it make sense to have an periodic cron job
> > > blow away the LDAP info and re-load it, or is it better to re-generate
> > > these files from the LDAP database?
> >
> > The best thing to do is to avoid the synchronization step in the first
> > place.
> > PAM/NSS solutions have already been discussed in someone else's
> reply. To
> > keep your existing standard adduser tools working, I suggest
> using an LDAP
> > backend that parses /etc/passwd et. al directly. Symas Corp.
> has a UnixAuth
> > agent that does exactly this, presenting an LDAP read/write interface to
> > the /etc/passwd, /etc/shadow, and /etc/group files. Ours is fairly
> > efficient,
> > written in C, but you could achieve most of the functionality using
> > back-shell or back-perl and some parsing scripts. We also handle
> > /etc/aliases and several
> > other sendmail config files directly. PAM has got a lot of
> momentum behind
> > it, but we believe there's value and security in non-invasive
> solutions that
> > keep your existing infrastructure intact, while still making it more
> > manageable.
> > Reliability is a big reason to take our approach; you'll always
> be able to
> > login even if your LDAP service or network connection dies.
> Compatibility
> > and performance are two more reasons; NSS searches thru LDAP
> can be slow and
> > the NS Cache Daemon is not known for its reliability, and there
> are still
> > programs out there that like to use fgetXXent() to walk thru the tables.
> >
> > Note that rolling your own solution here probably isn't
> something you should
> > do as an LDAP beginner, unless you're already proficient with
> shell or perl
> > programming, and you're comfortable setting up slapd ACLs to protect the
> > information you're exposing. Making a mistake on the ACLs could be
> > disastrous.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support