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

More PAM/NSS-DAP stuff




Regarding my new lab setup that uses PAM_LDAP and NSS_LDAP for
authentication, and tries to keep the system passwd database
and the LDAP database in sync for fault tolerence reasons:

So, now that I've got useradd rewritten, and usermod + userdel + passwd
underway, I have a question about PAM.  Apperently passwd does not work.
I'm guessing this is because pam_ldap uses a config entry in ldap.conf
that specifies how it should bind to the LDAP server.  By default, it
appears to do an anonymous bind.  I allow everyone to compare the
userpassword field, so it's fine with verifying that users have entered
the right password.

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.

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.

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

So, I'm wondering if there's a good solution that I haven't thought of
yet, and if there's any compelling reason to strike any of my obvious
options out.  I want to keep the changes from a stock SuSE system
as minimal as possible, although with my helix-gnome setup I've already
drifted away...

I appreciate any thought on the matter (except for those wondering why I
typed so damned much stuff). :)

Later,
Danny

--
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.