Subject: Re: (long) Re: Authenticating with LDAP
To: NetBSD User's Discussion List <netbsd-users@NetBSD.ORG>
From: Greg A. Woods <>
List: netbsd-users
Date: 01/20/2003 16:11:12
[ On Monday, January 20, 2003 at 15:11:56 (-0500), Chuck Yerkes wrote: ]
> Subject: (long) Re: Authenticating with LDAP
> nsswitch.conf can be taught to use LDAP with a fair amount of
> effort.

It's not that hard!  Given an existing LDAP access library it should be
mostly a cut&paste job.

>  The implementations I've seen that make sense are
> Currently, getpwent, for example, includes nsswitch.h
> which statically defines the supported methods.  In the
> end, this must be dynamic.

Why do you say that?  Nothing whatsoever _needs_ to be dynamic in any
open-source system.  You know your target environment.  Adjust your
complie-time -D's and maybe add any missing code, compile, burn a CD,
install on the target machine(s), and you're done.  Repeat as necessary
if/when your target environment changes.  If you don't want to do it
yourself then pay/coerce someone else to do it for you!

It is in fact the dynamic nature of PAM which is one of its biggest
drawbacks, security-wise.  I static-link all of my security sensitive

There's also still the scheme used by BSD/OS....

> 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.

Yup, sure, but that's an entirely separate issue.  It should be
considered in the question of whether LDAP is an appropriate mechanism
for a given site to use for authentication and authorisation information
retrieval.  It is not a concern of how to enhance nsswitch to do LDAP
lookups -- only a concern for the implementation and configuration of
the LDAP access library used by the nsswitch hooks.

> 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).

Then they should be enhancing their access library to suite.  :-)

								Greg A. Woods

+1 416 218-0098;            <>;           <>
Planix, Inc. <>; VE3TCP; Secrets of the Weird <>