Re: nss_ldap, pam_ldap woes

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

On Fri, 27 Aug 1999, Amy Tebbe wrote:

> > It's not absolutely necessary to install/run the MigrationTools - they
> > just give you an idea of how to convert existing users from /etc/passwd
> > to LDAP-based RFC 2307 entries.
> 
> 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.

It's most definitely possible - the previous reference into the
openldap-general archives that I gave contained a URL to a report/presentation
that uses PADL Software's pam_ldap/nss_ldap modules against both OpenLDAP and
Novell NDS as LDAP servers, to authenticate users who no longer exist in
/etc/passwd.  Although the focus is Solaris, the latest Red Hat-based Linux
systems (and many other Linux distributions these days) now contain the same
functionality.

> I tried ssh (which from past postings probably won't work) and telnet.

The key interfaces are PAM and NSS - 9/10 UNIX applications already use NSS
because it's not a new API, it just places an administrator-configurable
backend on existing functions such as gethostbyname(), getpwent(), etc.

PAM is new - Sun developed it, submitted the spec to the Open Software
Foundation (OSF) which then adopted it for CDE so any vendor shipping
Motif/CDE products should (in theory) also support PAM.  In practice though
you may have to look for this as a separate feature.  Sun Solaris 2.6 (and
newer) support PAM (with caveats), newer Red Hat Linux versions support PAM,
as does HP-UX.  Digital/Compaq's Tru64 UNIX has an NSS/PAM equivalent called
"SIA" (or similar).

So, if the software you're using (be it TELNET, SSH or anything else) is
written to these interfaces (or your platform's equivalents) then you (as
admin) can change the backend without having to change the application at all.
This is how we've used TELNET (in the project/presentation at the URL
referenced above).  I know one of our admins has also compiled up a
PAM-capable SSH, but I don't know if she patched SSH source directly or just
recompiled with a supplied option.

If, on the other hand, the software accesses the authentication database
(/etc/passwd) directly, then the software has to be recoded to work with LDAP
or any other backend database.

> > In doing the "simple ldapsearch", are you using the RFC 2307 suggested NSS
> > patterns/filters?
> 
> % ldapsearch -b 'dc=real-time,dc=com' 'objectclass=*'
> ...to see everything...
> this works

The reason I asked about the RFC 2307 filters is those are what the pam_ldap
and nss_ldap modules use, so you will be able to "see" the same entries it
does;  for example, even if an "objectclass=*" pattern shows everything in
your directory, using the NSS patterns may not (thus, the modules won't see
the user/s and authentication won't work).

> > The extra "LDAP" prompt is an artifact of the PAM configuration - you
> > can get rid of this (or at least, make it replace the UNIX prompt) by
> > changing your PAM configuration accordingly.

I have no idea what PAM configuration the RPM you installed may have, but I
don't recommend anyone throw the "pam.conf" included with the pam_ldap and
nss_ldap modules directly on their system and expect everything to work;  use
it as a guide for how to configure your own system.

> > > 2. What do I enter for the LDAP password?  I tried the binddn password
> > The userPassword value stored for that user in the LDAP directory.
> But if I'm adding a user, then it wouldn't exist already in LDAP,
> so it wouldn't have a userPassword value.

Ahh, but you weren't;  at the point where this prompt appeared (in the
snippet you posted) you were actually changing a user's password with the
"passwd" command.  Chances are, the reason the LDAP prompt appears is because
in your PAM configuration for the pam_ldap module you'll see the
"try_first_pass" option.  This is what I meant by changing your PAM config (in
the report I keep mentioning, I note how to retain existing behaviour we had
to change this to "use_first_pass").

In a "working environment", you would enter the userPassword value as noted
above.

> So, it sounds like ldap can act as an nis server for lookups and
> authentication, but you need to use scripts to make changes to your ldap
> database if you want to add/modify nis users.  Is this correct?

It comes back to what I said above - the application needs to be written to
some standardised APIs (like NSS and PAM);  if this is not the case, then the
app won't work (and you need to either make changes to the app, or code around
it).  In our case, we had to write our own add/modify scripts (at least, from
the UNIX side) which wasn't a big deal for us since we already had custom
scripts in place for permitting support people to change passwords, create
user accounts from a central database extract, etc.

> > > 3. What are the capabilities of nss_ldap and pam_ldap?  What should
> > > I expect to be able to do with it?  
> > 
> > As the pam_ldap README file says:
[...]
> This actually doesn't tell me much.  I was hoping for a list of what
> add/modifications that you would normally do w/ other tools (linuxconf,
> for instance), could be integrated w/ LDAP.

Then that's what you should have asked!  :-)

It all comes down to how those tools (like linuxconf) access the information
database;  if they do so through PAM/NSS, then you're sweet and can throw
everything into LDAP, end of story.

> I saw something about a beta linuxconf-ldap patch but haven't tried that
> yet.

I don't know enough about linuxconf to be able to comment, sorry.

> Is there a list of which applications will properly authenticate from an
> LDAP database?  Specifically, I'm interested in ssh & qpopper to start.

No - nor will there likely ever be such a comprehensive list.  The reason is
simple - these applications don't have to *know* that they're authenticating
to an LDAP database;  as far as they're concerned, they're just calling NSS
and PAM functions and the underlying operating system is just returning the
requested data from "somewhere".

The admin does the backend matching to say, "requests for this type of
information come from LDAP, requests for this other type of info come from
NIS, etc."

What you should be asking, "Is there a list of what applications have been
written to support these interfaces?"  Even then you would probably have to
look at the apps themselves rather than a centralised list (unfortunately).

In Qualcomm's "qpopper" case, one of our admins had to patch the source to
support PAM (now it successfully authenticates uses via LDAP - or whatever
backend database we configure).  I haven't checked the 3.0 betas to see if PAM
support has been incorporated.  UW's popd (as part of PINE and imapd) supports
PAM if compiled with the appropriate options.  I mentioned SSH above.

Cheers..


dave