Re: More PAM/NSS-DAP stuff

[Jeff Licquia <jeff@luci.org>]

Sorry I haven't been keeping up with the list.  Drat that real life
thing!

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.

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.

> 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. :-)

> 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.

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.
-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.