[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pop3 and sendmail? (long)

[ This message is a tad long as I'm trying to wrap up a whole slew of
  questions in one hit;  my apologies for the length and I hope I've
  managed to keep it close to topic for the list (and/or of use to folks). ]

Earlier today, Matthew Hixson wrote:

> On Sun, 11 Apr 1999, Hossein S. Zadeh wrote:
> > Is it just me or others do not see any benifit in doing the former either?
> The benefit is that I only want to use PAM and not have to mess with setting
> up anything else.

In setting up PAM, you've done most of the work required to setup NSS as well 
(in fact, I'd argue that NSS is easier/quicker than PAM - see below).

Earlier today, Hossein Zadeh wrote:

> On Sun, 11 Apr 1999, David J N Begley wrote:
> > Basically, you do create a "Unix account" for those users (at least, the
> > way I'm doing it) so they need uid/gid/&c. but they don't have entries in
> > "/etc/passwd" or "/etc/shadow".
> How do you create Unix accounts without any entry in /etc/passwd?
> My understading is that /etc/passwd is the only means of relating UID/GID
> with username. How can they have UID/GID if there is no entry in
> /etc/passwd?

That's NSS' job - it returns passwd(4)-like (or passwd(5) for Linux users)
entries that contain all the relevant entries (UID, GID, home directory, login
shell, GECOS field, &c.), it's just that the information didn't originate in
the regular "/etc/passwd" and "/etc/shadow" files.

> On Sun, 11 Apr 1999, David J N Begley wrote:
> > I mentioned Luke Howard's NSS/PAM modules for LDAP the other day - taking
> > them as an example, I've now gotten a Solaris box correctly providing
> > "user" access for an account that doesn't exist in "/etc/passwd" or
> > "/etc/shadow" at all.
> WOW! Now this is what I call *useful*!

No kidding!  ;-)

Okay, kick up yer feet and prepared to be bored - here's The Story So Far(tm):

- our student labs are either Macintosh- or PC-based (Windows NT Workstation
  4.0) with Novell NetWare 5.0 file/printer servers (all scattered over an
  ATM/serial WAN across microwave and fibre optic links - currently six sites
  in total)

- our student mail/Web home page server is a Solaris 2.6 machine (single
  centralised server);  all students automatically get an account on this
  server (generated automagically from the student records system), with
  about 13,000-14,000 accounts in total

- we have a stated requirement to authenticate student access to the labs,
  and share the same login ID/password with the student mail server

- since the labs are already in a position to authenticate through NetWare,
  using the NetWare 5.0 NDS as the primary authentication source seemed the
  logical way forward

- all the necessary applications (POP3/IMAP servers, &c.) on the Solaris
  machine were PAM-ified (if they weren't already);  we then just needed a
  PAM module for Solaris{*} to authenticate users against the NetWare 5 NDS

{*} Solaris is the primary platform since that's what runs on the mail server;
    when we were looking around at options, Linux was a stated "bonus" as it
    runs on the printer spool (Cobalt Raq) and could see expanded use in

- we were a beta-test site for Novell's "NDS for Solaris" product which
  basically did what we needed, though it was fairly slow in the testing
  we performed (amongst other concerns, but not enough to stop us going
  ahead with it)

- when the product went FCS, we started talking pricing with Novell;  they
  told us their NDS for Solaris product was priced according to Microsoft's
  pricing model for Windows NT and therefore to do what we want we'd have
  to part with.. .  .   . around half a million dollars, give or take a few
  tens of thousands of dollars (I'm NOT kidding - just to allow one Solaris
  machine to authenticate against another NetWare box);  I have no idea (nor
  do I care) if Novell's revised their pricing since then, but basically we
  declared NDS for Solaris a non-starter

- since our ultimate goal was "LDAP everywhere" (we were going to use NDS for
  Solaris as a quick 'n' dirty solution to that one problem, since all the
  Solaris apps needed to be PAM-ified anyway regardless of ultimate solution)
  we decided that "now was as good a time as any" to push ahead with LDAP

- that didn't remove the need for a proper "server" (with replication, &c.)
  that could handle both the labs (NetWare) and mail server (Solaris), so
  we decided to stick with NetWare 5.0 NDS as the authentication server, just
  use LDAP to talk to it rather than NDS' native protocols

- okay, so where do we find an LDAP authentication PAM module?  everywhere we
  looked led to a dead-end URL;  time was running out (well, we were already
  over our deadline for the project) and since there are only three vaguely
  Unix-related folks here (all of whom have other "emergency" day-to-day
  work to do), we decided to hire a contractor, give him all the relevant
  pointers/sample code/docs/RFCs and say, "come up with a PAM module for us"

- unfortunately there was some miscommunication and the contractor decided the
  task too onerous for our (newly revised) deadline, but didn't actually get
  word back to us (sigh);  this led to a rather embarrassing situation for the
  Unix folks (used to jibing the NetWare folks for not getting things done on
  time), so yet another frantic search was conducted to find sample PAM code
  that handled LDAP

- voila!  this time we managed to locate the latest URLs for Luke Howard's
  PAM and NSS modules, so we set out trying to make them work as required
  (that was last Wednesday - today is Sunday)

So, what has been accomplished in four days?

- we can talk to the NetWare box using LDAP V2 (we figured it would be easier
  for starters - we're using the Netscape Directory SDK 3.0 so we can switch
  to SSL later), and pull out certain user details (also change some details)

- the NetWare box is missing the required object classes (posixAccount and
  shadowAccount) used by Luke's NSS/PAM modules, so we need to get those added
  to the NDS;  meanwhile, we've run up an OpenLDAP server against which we've
  been testing the modules and ironing out any "behavioural differences"

- right now, I have a user defined in the OpenLDAP directory who exists only
  in the OpenLDAP directory, not in the normal Unix user/group files at all;
  yet, that user can login, change their password, create files, see files
  owned by them in the file system, send/receive email, &c.

What needs to be done?

- get the necessary object classes (and attributes) into the NDS (RFC 2307)

- ensure some form of future compliance with the Cisco/Microsoft/Novell
  DEN (directory-enabled networks) classes (I think that's okay since the
  last draft I read said user details were outside the scope of DEN anyway)

- switch to LDAP V3 with SSL encryption

- figure out how to get NetWare and Solaris to share the one userPassword
  attribute (and to have password changing work everywhere)

How was it done and why were both PAM and NSS modules used?

- PAM provides authentication services (pluggable authentication modules),
  so we need that to handle authentication through things like TELNET, FTP,
  POP3, IMAP, &c.

- NSS provides lookup services (name service switch) for anything that
  relies on information normally stored in files such as "/etc/passwd",
  "/etc/group", "/etc/hosts", "/etc/protocols", "/etc/services", &c;  a
  simple "ls -l" in a directory causes lookups to convert UIDs and GIDs in
  the file system into textual login IDs, so that's where NSS comes in

- using both PAM and NSS meant the users wouldn't need to have entries in
  "/etc/passwd" or "/etc/shadow" at all, they could exist remotely (in NDS
  ultimately) but still look/act as though they were normal Unix accounts

- the "how" is boringly simple:

  - download Luke Howard's PAM/NSS modules for LDAP from:


  - download Netscape's Directory SDK 3.0 for C (with export SSL) from:


  - install Netscape's Directory SDK

  - compile/install nss_ldap

  - compile/install pam_ldap

  - configure "/etc/ldap.conf" (controls both ???_ldap modules)

  - configure "/etc/nsswitch.conf" to add "ldap" for "passwd";  restart
    nscd (for Solaris) and that's it, NSS is configured and running

  - configure "/etc/pam.conf" (Solaris) to include the LDAP module where
    necessary (we search local files first, LDAP second using the
    "use_first_pass" option) and that's it, PAM is configured and running

    (adding "ldap" to "/etc/nsswitch.conf" is much easier than figuring out
    the ordering and nuances of everything in "/etc/pam.conf" - that's why
    I reckon NSS is much easier to setup than PAM, but both are required)

  - insert user object (with necessary attributes) into remote LDAP directory
    and voila, user can login without existing in "/etc/passwd" (we used the
    posixAccount and shadowAccount schemas from RFC 2307, as required by
    Luke's modules)

As noted above, there's still some way to go but at least we're making

> We have a huge Novell tree (NDS). Everyone has an account in the NDS. We
> hace a Unix box as MX for our department. Emails arrived at the Unix box
> that have no correspondent local username get passed on to the Novell
> (some people have Unix accounts, some don't).
> I want to setup the Unix box such that it accepts emails for everyone AND
> keep the email locally (not passing them on to Novell).

This alone should work with the NSS module - make sure your NDS user objects
have all the necessary posixAccount attributes (I've left them out of this
email as it's way too long already) and the lookups should be sufficient to
allow your MX to receive/store mail for those users.

> I was thinking of setting up POP3 (authenticating users from the Novell via
> PAM).

Definitely, this is where the PAM module comes into play - your POP3 daemon
needs to be PAM-ified and again your NDS user objects need the requisite
posixAccount attributes (if using Luke's LDAP modules).

Of course, you could always approach Novell regarding NDS for your variant of
Unix...  ;-)

(See unresolved issues above.)

> The problem is that users need to have local account on the Unix to have
> mailboxes there.

With the NSS/PAM combination, your users will still need unique UIDs and GIDs
it's just that they don't need to exist in your /etc/* files (ie., an account
properly added to the NDS with all the necessary attributes will automatically
"exist" on your Unix mail server).

> Any ideas? Is NSS my answer? Any pointer/documentation for NSS?

NSS is half the answer - PAM is the other half.  :-)

A simple URL for NSS is:


Also you may find something useful on Sun's documentation site:


Phew!  I hope I've covered the ground sufficiently to answer the raised
questions (and probably some others too), without (I hope) straying too far
from topic.  Also, if anyone has any comments regarding the shared password
issue (above), I'd appreciate it.  ;-)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []