Quoting Stephane Bortzmeyer (bortzmeyer@nic.fr):
> On Wed, Jan 15, 2003 at 12:37:41PM -0500,
>  Greg A. Woods <woods@weird.com> wrote 
...
> > Read the many various related threads on various netbsd mailing lists.
> The one you gave me:
> http://mail-index.netbsd.org/netbsd-advocacy/2001/09/30/0001.html
> is very interesting, technically speaking, but it boils down to "PAM
> is not perfect, one day, I will do something better".
> 
> > Plainly put PAM is utterly useless and unnecessary for NetBSD.
> The problem is more pragmatic. OK, PAM sucks but:
> 
> 1) What do you suggest instead? (If you say "NIS", I will ask why NIS
> is better than LDAP, specially when we talk about security.)
> 
> 2) What do you do when the current network uses LDAP and the issue is
> not "What authentication protocol should we use?" but "Will I be able
> to integrate a NetBSD machine into that network or should I reformat
> the hard disk right now? Specially considering that I am the only one
> in the technical team which uses NetBSD."

Clearly, more than just authentication hooks are needed.

If I log in, the getpw* routines (and the equiv for various services
and info) need to be populated with my information.

Like kerberos being used for authentication, hesiod was
the complement for providing other information (groups,
location of home dir, etc).

nsswitch.conf can be taught to use LDAP with a fair amount of
effort.  The implementations I've seen that make sense are
on RedHat, but I've not studied them fully.  They complement
PAM, which does the authentication, by getting user info
after the authentication.

Abstracting get*() routines (/usr/src/lib/libc/{gen,net}/get*.c)
is important.

[side note added late:  the HESIOD routines are all there
and hesiod allows for varying backends (default was DNS,
but I know trading companies that used SQL as the backend).
Implement HESIOD with LDAP as the back end, and you might
be set....]

Currently, getpwent, for example, includes nsswitch.h
which statically defines the supported methods.  In the
end, this must be dynamic.  While is SHOULD be hardcoded
to be able to use "the usual" (/etc/passwd), it should likely
call an abstracted routine that can use modules installed
by the admin.

You drop in a module that supports getting information via LDAP
(getting the festival of fields that create a passwd line,
barring the actual password field), and it will work.



It will work slowly, however.  And your load and the LDAP server's
load will climb.

With LDAP specifically, some design points need to be considered.
LDAP servers SHOULD be contacted over a secure link.  If that's
a secure "pocket network" (common for infrastructure services
and at ISPs), or some longer term relationship (e.g. an IPSEC
connection to the server) then cleartext is fine but quite
often, you'll have an LDAP/SSL connection.

Setting up and breaking down SSL connections is very expensive.
So using a "helper" daemon to maintain a connection is called
for to alleviate this.  Once we have this daemon caching
information information for a period (even where period = 5sec
or less) becomes obviously desirable.  (Analogous to running
a cache-only name server; this is a HUGE benefit in mail
environments, even when delivering as few as 30 or 40
messages/minute).

The OpenLDAP folks are aware of people's desire for such a
tool and are also aware of the complexity of this (what
attributes to you cache, can individual entries or branches
have varying cache times, how many entries to cache, etc).
EMail servers in particular would benefit from it.  Our interrim
solution is slave servers on or near the mail machines with
a private connection to that server (mitigating the need for
SSL).


On the simpler side, a daemon that did the connections, shut
down the connection after a configurable amount of idle time
and got the POSIX described user information and cached it
(in RAM, in a db v3 or v4 file?) for N seconds with a cleanup
thread to free space might be doable in short order.  It
listens on a socket, reads the config file and runs as an
unpriviledged user.

It can bind to an LDAP server via SSL with or without
authentication (Active Directory requires an authentication).
Perhaps it can translate some of the non-standard, but common
LDAP schemae (AD)

No matter what, it must be configurable with the search routines
that keep ANY user who just exists in LDAP from having an
account on the system.  Of course, you open yourself up to
the LDAP administration controlling who can log into your
machines.

This sounds like it should start as a port.  Nothing keeping
it as part of NetBSD particularly...