On Fri, 2005-07-22, Benjamin Smee wrote:
> On Thu, 2005-07-21 at 19:17 -0700, Bill Johnstone wrote:
> I was coming from a different angle. My users don't have command line
> access nor any unix skills whatsoever. For that scenario I use the
web
> page which makes a call to a ldap aware pam backend so that they
> change their passwords that way while I am still able to enforce
> password policies etc via pam.
OK, that's indeed different from my environment. In my environment,
all users are Unix users and will be logging in via SSH (or maybe
console).
>> I don't see why this needs to be the case. Sure, you need a rootdn
>> to initially populate the directory, but after that, it's easy to
use
>> ACLs to give each user write capability to his own user attributes,
>> such as"loginShell".
> sure but if you have a ldap setup that doesn't allow anonymous binds
> then you have to have an extra password input phase that seems to
> break many command line utils.
Yes, the LDAP setup has to allow anonymous binds, and auth access to
the userPassword attribute for anonymous. This is the typical way LDAP
is used for user authentication and name services in the Unix
environment, as the Gentoo LDAP Guide document indicates.
>> Moreover, it is possible to add a specific user to the
>> directory who has write access to the the subtree under the ou (via
>> ACLs again), and have that password stored within the directory db,
>> just like all the other users have their passwords stored. This
>> eliminates the need to have a "rootpw" stored within the slapd.conf
,
>> and due to the ACLs, makes it easier to restrict the ability of the
>> administrative user and keep him from damaging the whole directory.
> not entirely following what you are wanting to do with this. adding a
> specific user with write access to WHAT subtree under the ou.
> Generally speaking I wouldn't give a user write access to anything
> apart from their own entry and even then in most cases only to their
> password field and to nothing else.
> The second part of this makes no sense to me at all. If you can't
make
> the userland utils call ldap as the user (I don't believe all of them
> can, most want to run as root) then you have to provide the utils a
> way of being able to bind and make modifications to any users entry
> which means a psuedo root user.
What I mean to say is this. First, let us agree that each user has
write access to his own userPassword attribute and could just as easily
be given access to, say, his loginShell attribute. As-is, the shadow
suite's PAM-aware "passwd" command, along with pam_ldap and nss_ldap,
allow the individual user to change his own password at the
command-line.
The "specific user" I mentioned above is like a restricted "root" type
user, except that he is added to the directory like a normal user, and
has a password like a normal user. This means, unlike slapd's built-in
"rootdn" and "rootpw", the password is not stored in slapd.conf -- it
is stored along with all the other users' passwords in the directory
database. What makes this user "special" is that ACLs can be used to
give him tailored write access to the Groups and People ous, so by
using the standard ldap{add, modify, delete} commands, and specifying
this new username as the dn, someone logging in as this user can add
new users or groups (or modify/delete existing ones), just as root
would be able to do on a standard Unix system relying on /etc/passwd.
However, the chief danger associated with the rootdn and rootpw, the
password being available in slapd.conf (or a separately named file) is
alleviated. In addition, picking your own name for this manager user
gives you a similar level of security-through-obscurity as does
disabling direct root logins.
This all presumes the mandatory use of TLS, as I have configured my
clients and server to do.
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
--
[email protected] mailing list
