1 |
heya, |
2 |
|
3 |
On Mon, 2005-07-25 at 21:34 -0700, Bill Johnstone wrote: |
4 |
> OK, that's indeed different from my environment. In my environment, |
5 |
> all users are Unix users and will be logging in via SSH (or maybe |
6 |
> console). |
7 |
|
8 |
Hence the difference I guess :) |
9 |
|
10 |
> Yes, the LDAP setup has to allow anonymous binds, and auth access to |
11 |
> the userPassword attribute for anonymous. This is the typical way LDAP |
12 |
> is used for user authentication and name services in the Unix |
13 |
> environment, as the Gentoo LDAP Guide document indicates. |
14 |
|
15 |
The typical way, perhaps, but its fairly insecure imo, I don't like |
16 |
giving out more information then I have to and exposing my DIT to anon |
17 |
binds is something that I dislike. Of course proper layout of the DIT |
18 |
means that there is nothing sensitive being exposed, but I still don't |
19 |
like giving out ANY information to anon users. My level of paranoia is |
20 |
not always appropriate for others though :) |
21 |
|
22 |
> What I mean to say is this. First, let us agree that each user has |
23 |
> write access to his own userPassword attribute and could just as easily |
24 |
> be given access to, say, his loginShell attribute. As-is, the shadow |
25 |
> suite's PAM-aware "passwd" command, along with pam_ldap and nss_ldap, |
26 |
> allow the individual user to change his own password at the |
27 |
> command-line. |
28 |
|
29 |
agreed, and I believe chsh etc can all be configured to change the |
30 |
relevant parts in the DIT as well. |
31 |
|
32 |
> The "specific user" I mentioned above is like a restricted "root" type |
33 |
> user, except that he is added to the directory like a normal user, and |
34 |
> has a password like a normal user. This means, unlike slapd's built-in |
35 |
> "rootdn" and "rootpw", the password is not stored in slapd.conf -- it |
36 |
> is stored along with all the other users' passwords in the directory |
37 |
> database. What makes this user "special" is that ACLs can be used to |
38 |
> give him tailored write access to the Groups and People ous, so by |
39 |
> using the standard ldap{add, modify, delete} commands, and specifying |
40 |
> this new username as the dn, someone logging in as this user can add |
41 |
> new users or groups (or modify/delete existing ones), just as root |
42 |
> would be able to do on a standard Unix system relying on /etc/passwd. |
43 |
> However, the chief danger associated with the rootdn and rootpw, the |
44 |
> password being available in slapd.conf (or a separately named file) is |
45 |
> alleviated. In addition, picking your own name for this manager user |
46 |
> gives you a similar level of security-through-obscurity as does |
47 |
> disabling direct root logins. |
48 |
|
49 |
and we come full circle. My initial comment was: |
50 |
"Well by putting your accounts into LDAP you really should be using LDAP |
51 |
management tools to manage it. " |
52 |
and that is precisely what you are doing. ldap{search,modify,add} are |
53 |
designed for that and are just low level tools for manipulating the DIT. |
54 |
The problem you have when trying to use native unix binutils type |
55 |
commands is that they don't deal with the auth layer in the ldap well, |
56 |
that is when you invoke say chsh to change someones shell you need to |
57 |
auth as someone other then yourself (if you are trying to manipulate |
58 |
another users info)and it is that step that will _generally_ require a |
59 |
password in a file somewhere. |
60 |
|
61 |
Benjamin Smee (strerror) |
62 |
|
63 |
-- |
64 |
gentoo-server@g.o mailing list |