Hello Troy,

> > - the login program looks up (may be by some pam_somethingelse) the
> >   homedir path corresponding to the user "name"
> 
> The login program need know nothing about this.... I believe this could

sure, it's most logical to let pam take care of it, not the program itself.

> be accomplished with a "libnss_superdooperldap" library, along with some
> extensions to NSCD (name service switch cache daemon).

> I'm using libnss_ldap right now, with static mappings of
> username->userid, but there's no reason a cache daemon running on the
> local machine couldn't be responsible for allocating a local UID, and
> local GID's for the groups the user is in.

Why would you care to change nscd? the mapping operation is done once per
user, and can be easily accomplished out of nss - then just let nss report
the result to all interested processes, either via nscd or without it...

Local groups? Which local resources have to be authorized to be accessed?
As long as you have all user files on Coda, you wouldn't care about
local groups...

> You *could* do pam_ldap for auth, but I think it would be better in the

Exactly, ldap is a directory service, not an authentication service.
It is possible to abuse it - but why bother :)

> long run to use kerberos. The systems I admin at work use libnss_ldap
> for anythign that would do 'getpwent' & friends, and use pam_krb5 (and
> then pam_openafs_session) to get the user authenticated and access to
> the filesystem.

A sane approach!

See you,
--
Ivan