| 1 |
On Fri, 2005-07-22, Benjamin Smee wrote: |
| 2 |
|
| 3 |
> On Thu, 2005-07-21 at 19:17 -0700, Bill Johnstone wrote: |
| 4 |
|
| 5 |
> I was coming from a different angle. My users don't have command line |
| 6 |
> access nor any unix skills whatsoever. For that scenario I use the |
| 7 |
web |
| 8 |
> page which makes a call to a ldap aware pam backend so that they |
| 9 |
> change their passwords that way while I am still able to enforce |
| 10 |
> password policies etc via pam. |
| 11 |
|
| 12 |
OK, that's indeed different from my environment. In my environment, |
| 13 |
all users are Unix users and will be logging in via SSH (or maybe |
| 14 |
console). |
| 15 |
|
| 16 |
>> I don't see why this needs to be the case. Sure, you need a rootdn |
| 17 |
>> to initially populate the directory, but after that, it's easy to |
| 18 |
use |
| 19 |
>> ACLs to give each user write capability to his own user attributes, |
| 20 |
>> such as"loginShell". |
| 21 |
|
| 22 |
> sure but if you have a ldap setup that doesn't allow anonymous binds |
| 23 |
> then you have to have an extra password input phase that seems to |
| 24 |
> break many command line utils. |
| 25 |
|
| 26 |
Yes, the LDAP setup has to allow anonymous binds, and auth access to |
| 27 |
the userPassword attribute for anonymous. This is the typical way LDAP |
| 28 |
is used for user authentication and name services in the Unix |
| 29 |
environment, as the Gentoo LDAP Guide document indicates. |
| 30 |
|
| 31 |
>> Moreover, it is possible to add a specific user to the |
| 32 |
>> directory who has write access to the the subtree under the ou (via |
| 33 |
>> ACLs again), and have that password stored within the directory db, |
| 34 |
>> just like all the other users have their passwords stored. This |
| 35 |
>> eliminates the need to have a "rootpw" stored within the slapd.conf |
| 36 |
, |
| 37 |
>> and due to the ACLs, makes it easier to restrict the ability of the |
| 38 |
>> administrative user and keep him from damaging the whole directory. |
| 39 |
|
| 40 |
> not entirely following what you are wanting to do with this. adding a |
| 41 |
> specific user with write access to WHAT subtree under the ou. |
| 42 |
> Generally speaking I wouldn't give a user write access to anything |
| 43 |
> apart from their own entry and even then in most cases only to their |
| 44 |
> password field and to nothing else. |
| 45 |
|
| 46 |
> The second part of this makes no sense to me at all. If you can't |
| 47 |
make |
| 48 |
> the userland utils call ldap as the user (I don't believe all of them |
| 49 |
> can, most want to run as root) then you have to provide the utils a |
| 50 |
> way of being able to bind and make modifications to any users entry |
| 51 |
> which means a psuedo root user. |
| 52 |
|
| 53 |
What I mean to say is this. First, let us agree that each user has |
| 54 |
write access to his own userPassword attribute and could just as easily |
| 55 |
be given access to, say, his loginShell attribute. As-is, the shadow |
| 56 |
suite's PAM-aware "passwd" command, along with pam_ldap and nss_ldap, |
| 57 |
allow the individual user to change his own password at the |
| 58 |
command-line. |
| 59 |
|
| 60 |
The "specific user" I mentioned above is like a restricted "root" type |
| 61 |
user, except that he is added to the directory like a normal user, and |
| 62 |
has a password like a normal user. This means, unlike slapd's built-in |
| 63 |
"rootdn" and "rootpw", the password is not stored in slapd.conf -- it |
| 64 |
is stored along with all the other users' passwords in the directory |
| 65 |
database. What makes this user "special" is that ACLs can be used to |
| 66 |
give him tailored write access to the Groups and People ous, so by |
| 67 |
using the standard ldap{add, modify, delete} commands, and specifying |
| 68 |
this new username as the dn, someone logging in as this user can add |
| 69 |
new users or groups (or modify/delete existing ones), just as root |
| 70 |
would be able to do on a standard Unix system relying on /etc/passwd. |
| 71 |
However, the chief danger associated with the rootdn and rootpw, the |
| 72 |
password being available in slapd.conf (or a separately named file) is |
| 73 |
alleviated. In addition, picking your own name for this manager user |
| 74 |
gives you a similar level of security-through-obscurity as does |
| 75 |
disabling direct root logins. |
| 76 |
|
| 77 |
This all presumes the mandatory use of TLS, as I have configured my |
| 78 |
clients and server to do. |
| 79 |
|
| 80 |
|
| 81 |
|
| 82 |
____________________________________________________ |
| 83 |
Start your day with Yahoo! - make it your home page |
| 84 |
http://www.yahoo.com/r/hs |
| 85 |
|
| 86 |
-- |
| 87 |
gentoo-server@g.o mailing list |
Archives