Subject: Re: (long) Re: Authenticating with LDAP
To: NetBSD User's Discussion List <netbsd-users@NetBSD.ORG>
From: Greg A. Woods <email@example.com>
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
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; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>