Re: nss_ldap, pam_ldap woes

["Mark Wilcox" <mark@mjwilcox.com>]

-----Original Message-----
From: Amy Tebbe <atebbe@real-time.com>
To: David J N Begley <david@avarice.nepean.uws.edu.au>
Cc: openldap-general@OpenLDAP.org <openldap-general@OpenLDAP.org>
Date: Friday, August 27, 1999 11:21 PM
Subject: Re: nss_ldap, pam_ldap woes


>On Sat, Aug 28, 1999 at 11:49:08AM +1000, David J N Begley
(david@avarice.nepean.uws.edu.au) wrote:
>> On Fri, 27 Aug 1999, Amy Tebbe wrote:
>>
>> > Date: Fri, 27 Aug 1999 19:22:17 -0500
>> > From: Amy Tebbe <atebbe@real-time.com>
>> > Reply-To: amy@real-time.com
>> > To: openldap-general@OpenLDAP.org
>> > Subject: nss_ldap, pam_ldap woes
>>
>> For discussion that is specific to PADL Software's nss_ldap/pam_ldap (as
>> opposed to having more of an OpenLDAP bias), it's best to join the
ldap-nis
>> mailing list (see the ANNOUNCE file in the nss_ldap package - at least,
the
>> source code includes it, I have no idea whether or not Red Hat's RPMs
include
>> it).
>>
>> > I'm running openldap 1.2.6-5 with nss_ldap-85-1 and pam_ldap-36-1
>> > on RedHat 6.0.  I can connect to my ldap server fine and do a simple
>> > ldapsearch.  I also installed the MigrationTools and ran the
>> > migrate_all_online.sh script.
>>
>> 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.  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.
should look like
+mewilcox:::::::
) that's how the OS knows to retrieve the user information from NIS.

>
>> 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
>
>
>> > 1. When I create a user with useradd, should the user be added to
>> > ldap automatically?  Here's what I get:
>>
>> Depends - if useradd is specific to /etc/passwd, then I would say "No".
>>
>> > % useradd -m tester
>> > % passwd tester
>> > Changing password for user tester
>> > New UNIX password:
>>
>> "UNIX" refers to users who have an entry in /etc/passwd - looks like
useradd
>> created the user locally rather than remotely.
>>
>> > Retype new UNIX password:
>> > Enter login(LDAP) password:
>>
>> 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.
>>
>> > 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.
>
>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?


Actually from my understanding LDAP is replacement for the DBM files in NIS
when using something like ypldap (or Sun DS). So anytime you make
modifications to NIS this makes modifications into the LDAP server. From the
looks of things though, you haven't used the NIS tools to do this. To modify
NIS you must use the NIS tools (which usually start with the letters "yp"
such as yppasswd) otherwise 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.

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 (but of course that's only good for the password
database).

>> > (default of secret still)  After 3 unsuccessful attempts for the LDAP
>> > password I get a segmentation fault.
>>
>> Ouch.. something could be broken in Red Hat's RPMs.
>>
>> > 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:
>>
>>   "Here are some possible deployment scenarios:
>>
>>     "o pam_ldap with account information in /etc flat files,
>>        kept manually in sync with LDAP
>>
>>     "o pam_ldap with account information in LDAP, using
>>        nss_ldap
>>
>>     "o pam_ldap with account information in NIS, using
>>        ypldapd"
>
>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.  I saw something about
>a beta linuxconf-ldap patch but haven't tried that yet.

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.

However, just about every authentication system that I know of now has the
ability to tie into LDAP (you may have to change vendors of the software but
it's out there). And I thought that ssh just used the system for
authentication?

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.

>> I'm using the second option - this means user entries do not need to
exist in
>> /etc/passwd+/etc/shadow, they exist in an LDAP directory instead.  You
then
>> need some way of telling all those UNIX applications to look in the LDAP
>> directory for their user data - this is where PAM and NSS (both by Sun)
enter
>> the picture.
>
>Is there a list of which applications will properly authenticate from an
>LDAP database?  Specifically, I'm interested in ssh & qpopper to start.
>
>>   PAM = Pluggable Authentication Modules
>>   NSS = Name Service Switch
>>
>> Essentially, PAM allows applications to use different sources for
>> authentication information.  NSS does something similar but is for simple
>> "lookups" (mapping login ID to UID and back again, for example) rather
than
>> authentication.  The reason the two exist is that they need not be
talking to
>> the same source.
>>
>> > I can't find much info on nss_ldap or pam_ldap anywhere.  I've been
>>
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. Also directory services are just now
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.

>> As above - join the ldap-nis mailing list (very low volume).  If you need
>> specific Linux/PAM information, there's a separate list (hosted by Red
Hat)
>> for that.
>
>Thanks - I've subscribed.
>
>> > to rage.net but it doesn't look like that site is being maintained.
>> > padl.com doesn't have much either.  I checked the openldap-general
>> > archives too.  Any help would be appreciated.
>>
>> How about this (August 10, 1999):
>>
>>   http://www.openldap.org/lists/openldap-general/9908/msg00051.html
>
>yep - saw that.
>
>Thanks for your help.
>--
>Amy Tanner                                      Voice: 612.943.8700
>Real Time Enterprises, Inc.                   Fax: 612.943.8500
>amy@real-time.com        http://www.real-time.com
>PGP fingerprint =  67 6C 8F DB B1 7A 8D 41  DC 7B CA 0B 28 1E 67 AD
>
>
>
Mark