Re: nss_ldap, pam_ldap woes

[David J N Begley <david@avarice.nepean.uws.edu.au>]

On Sat, 28 Aug 1999, Mark Wilcox wrote:

> On Fri, 27 Aug 1999, Amy Tebbe wrote:
> >yes, I understand that.  However, I tried to migrate the users
> >from /etc/passwd, then remove a user's entry from /etc/passwd to
> >see if I could still authenticate.  I tried ssh (which from past
> >postings probably won't work) and telnet.
> 
> You still need to have the userid stored in /etc/passwd as a "plussed" in
> account (E.g.

This is not strictly true if using generalised backends (like PAM/NSS) as
opposed to a NIS-specific environment;  certainly with LDAP as the backend
there is no need for any entry in /etc/passwd or /etc/shadow for the system to
find the user.  The system is driven by "/etc/nsswitch.conf" instead of a
plussed account.

For example:

  passwd:  files ldap

This will lookup users in /etc/passwd, and failing to find a match there will
continue using an admin-configured LDAP backend.

> Actually from my understanding LDAP is replacement for the DBM files in NIS
> when using something like ypldap (or Sun DS).

That's essentially a NIS/LDAP gateway - by placing LDAP directly in the NSS
configuration, you replace NIS completely.

> ...the standard UNIX tools are going to just modify the local system
> regardless if you're using standard password files, NIS, NIS+, LDAP or
> Kerberos.

It gets tricky because something like "passwd" for changing passwords may very
well be written to support PAM (so it will work with NIS, LDAP, etc.) but
"useradd" (for adding users - duh) won't (this appears to be true on Red Hat
Linux and Solaris).

> The only caveat to this is with PAM. From my understanding of PAM, when
> you make a change with a local tool in a PAM system that will modify the
> back-end database...

Assuming the local tool supports PAM, yes.

> ...(but of course that's only good for the password database).

Ack.

> I'm not sure what's all available yet, but anything you would/could store in
> a centralized database, then you could use LDAP for it.

IETF RFC 2307 defines a number of useful object classes for the purposes of
replacing what appears in NIS or /etc/* flat files;  these need to be
carefully balanced against other applications' needs for user entries in an
LDAP directory.

Solaris 8, HP-UX and Compaq/Digital Tru64 UNIX (w/IASS 5.0) all have RFC
2307(bis) support;  Novell and Microsoft and talking about adding it to NDS
and AD, but it could prove to be a problem (more for Microsoft than Novell).

> Most people just use it now for user authentication, but as that becomes
> passe and LDAP become standard infrastructure, then other uses will popup.
> After we get through Y2K watch for LDAP applications to grow very fast.

Ack!

> That's probably because they aren't used much. Most people built their UNIX
> systems around NIS/NIS+ so they're more interested in
> replacements/enhancements for NIS.

LDAP (using those two modules) can do this for most people now;  the trick is
that LDAP knowledge (and PAM/NSS knowledge, for that matter) is still pretty
thin on the ground.

> finally getting a head of steam behind them. They've been around forever but
> until recently most people didn't really see the need for them.

Or with X.500/OSI stack, people found 'em too cumbersome.  ;-)

> >> How about this (August 10, 1999):
> >>
> >>   http://www.openldap.org/lists/openldap-general/9908/msg00051.html

I know it's not perfect, but it at least documents a project that has gotten
some of this stuff working together successfully.  Comments for improvement
appreciated (hint, hint)!  ;-)

Cheers..


dave