Re: More PAM/NSS-DAP stuff

[Danny Sauer <sauer@cloudmaster.com>]

Mmm, lots of quoted text to send around...

On Sun, Jul 09, 2000 at 08:26:38PM -0500, Jeff Licquia wrote:
> Sorry I haven't been keeping up with the list.  Drat that real life
> thing!

And here I just ended up getting stuff to work on my own... :)

> On Tue, Jun 20, 2000 at 10:09:35PM -0500, Danny Sauer wrote:
> 
> > The problem arises when passwd tries to change the password.  Since pam,
> > and thus passwd, bind anonymousl;y, it does not see the userpassword
> > attribute, let alone have permission to change it.  The way I see it, I
> > have 3 options:
> > 
> > 1) set up pam_ldap to bind as manager.  Then passwd chan change fields
> > (as can chsh), but any program gone awry or poorly written can also
> > bing to the LDAP server as manager.  the Authen::PAM module comes to
> > mind.  Is this as big fo a security risk as I view it (in a public
> > lab where programming and systems administration are taught)?
> > 
> > 2) set up a PAM user wh ohas permission to modify the fields that
> > passwdand chsh would modify, but can't modify any of the others.  I
> > think this might be a better solution, but I'm still concerned about
> > letting every pam module bind with permissions like that.
> > 
> > 3) modify the pam_ldap and nss_ldap source to freaking bind as the user
> > after they authenticate themselves, like it should have been done in 
> > the first place.
> 
> Here are a few more options:
> 
> 4) recompile pam_ldap (at least) to use SSL, and use stunnel on the
> server-side to provide LDAP-over-SSL for strong encryption.  This, in
> conjunction with option 2, provides you with a bit more strength.  I'm
> told this is possible, though I haven't had a chance to try it.
> 
> 5) write a proxy password module that simply stores the requested
> changes in a spool directory, and have a daemon or cron job do the
> actual work from that (after highly verifying it).  This could have
> lots of benefits for any distributed network directory, not just
> LDAP.

This is similar to what I've done.  I've set up a cron job that gets the
userpassword attribute for each user every night if it was changed,
and then updates /etc/shadow accordingly.  Unfortunately, for it to work,
I need to get my version of usermod finished...

> 6) just write a password replacement.  This is what I did.  Remember
> that you don't have to be limited to something that runs from a shell;
> one of the things I'm working on is a password changer Web page that
> runs over SSL.

I'm limited to a shell.  Since they teach unix in that lab, not just linux,
one of the things they need to have is a "passwd" that behaves like
"passwd" everywhere else.  Although, I've also been getting started on
a web-based password changer that works over SSL, using webmin as a base.
The unix lab still needs the regular passwd, though.

I first wrote a wrapper using ldappasswd as a backend, which is what they're
using now.  The current version of pam_ldap and nss_ldap working together
seems to work with the regular linux pam-ified passwd, except that it
segfaults when changing a local user's info.

> > Now, the first 2 options will require recompiling pam_ldap and nss_ldap
> > anyway, as they are modufied by SuSE to use /etc/openldap/ldap.conf,
> > which needs to be world readable for the utilities like ldapsearch
> > et. al. to work.  So, I need to rebuild the authentication stuff to
> > use /etc/ldap.conf, which doesn't need to be world readable and can
> > thus have a privledged bind dn and passwd within.  The third option
> > also requires recompiling stuff, but gosh damn it, that's the way they
> > should work to begin with.
> 
> ObShamelessDebianPlug: Or you could just use Debian, which uses
> /etc/pam_ldap.conf and /etc/libnss_ldap.conf, respectively. :-)

Or I could use the RPM's I'm polishing up now that use a shared
/etc/ldap.conf.  I really need to try a new Debian out someday...

> > What I'm doing right now is just writing a passwd program (in perl,
> > initially, because there are classes going on right now that need to
> > change their passwords and I don't have time to figure out the C API).
> > I'd much more like to just distribute working pam stuff, though, because
> > that's the right way to fix the problem, and the purpose of PAM to
> > begin with.  That, and it would give me the time to finish the webmin
> > module that keeps an LDAP database in sync with the system file, which
> > is far beyond the scope of PAM in the network environment anyway...
> 
> Why is that beyond the scope of PAM?  Couldn't you just daisy-chain
> the password modules in the config file?  "use_first_pass" seems just
> right for the situation concerning the password, at least.

Beyond the scope because it needs to update both LDAP and /etc/{passwd,shadow}
from any workstation, not just the auth server.  I guess I could write a
password daemon on the auth server that updates both when connected, and
a PAM module to use on all the clients, but that sucks. :)  It might be
a good experience, but I'm sure I can come up with better expereinces
for the time being...

> I'd also wonder about the need for keeping anything synchronized in
> the first place; only one of my Linux servers at work has user
> accounts defined outside of LDAP, with no problems so far.

Since I'm leaving Parkland pretty soon, I want to leave the option of going
to NIS or rsync or anything else without the new admin having to figure
out how to pull the info from LDAP.  I also want the sys admin and other
*nix classes to be able to look through the "standard" files for instructional
purposes.  If I wasn't adminning an educational lab, this would be a lot
easier... :)  Everything needs to be transparent though.

BTW, the utilities I've written / am writing get stuck up on my project
page.  If anyone else wants to start from my hideous code, they're welcome
to do so...  /cloudmaster/projects/

--Danny, woh needs to find a good reference on using ssl
-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.