1 |
On Tue, 2005-07-26, Benjamin Smee wrote: |
2 |
|
3 |
> On Mon, 2005-07-25 at 21:34 -0700, Bill Johnstone wrote: |
4 |
|
5 |
>> Yes, the LDAP setup has to allow anonymous binds, and auth access to |
6 |
>> the userPassword attribute for anonymous. This is the typical way |
7 |
>> LDAP is used for user authentication and name services in the Unix |
8 |
>> environment, as the Gentoo LDAP Guide document indicates. |
9 |
|
10 |
> The typical way, perhaps, but its fairly insecure imo, I don't like |
11 |
> giving out more information then I have to and exposing my DIT to |
12 |
anon |
13 |
> binds is something that I dislike. Of course proper layout of the DIT |
14 |
> means that there is nothing sensitive being exposed, but I still |
15 |
don't |
16 |
> like giving out ANY information to anon users. My level of paranoia |
17 |
is |
18 |
> not always appropriate for others though :) |
19 |
|
20 |
Let me preface everything I'm about to say by constraining it to the |
21 |
domain of Unix users in the typical command-line and/or X environment. |
22 |
|
23 |
I suppose allowing anon binds is marginally less secure than needing to |
24 |
be logged into a Unix system to read the plaintext /etc/passwd , but if |
25 |
you run a finger service that allows outside finger @<hostname> |
26 |
(admittedly, that's uncommon these days), it's no more insecure than |
27 |
that. However, you could use host-based access controls to only permit |
28 |
connections from your network's own IPs and in fact I'm sure you're |
29 |
already doing something to this effect, since to do otherwise would be |
30 |
sloppy system administration. |
31 |
|
32 |
Also, as Arturo Busleiman said, the userPassword is not simply readable |
33 |
by anyone binding as anon (assuming the ACLs are correct), so again the |
34 |
info available via anon bind is no more "secret" than the plaintext |
35 |
contents of /etc/passwd . |
36 |
|
37 |
> agreed, and I believe chsh etc can all be configured to change the |
38 |
> relevant parts in the DIT as well. |
39 |
|
40 |
Can they be configured to do so?? That was one of the questions I was |
41 |
asking in the first place. Without having changed the PAM config for |
42 |
those commands, but having changed the system-auth policy to use ldap, |
43 |
I have found chsh and chfn to explicitly look in /etc/passwd and fail |
44 |
when they don't find a user there. If this is a matter of me needing |
45 |
to reconfigure PAM to tell them to use LDAP, then by all means, please |
46 |
tell me how. |
47 |
|
48 |
> and we come full circle. My initial comment was: |
49 |
> "Well by putting your accounts into LDAP you really should be using |
50 |
> LDAP management tools to manage it. " and that is precisely what you |
51 |
> are doing. ldap{search,modify,add} are designed for that and are just |
52 |
> low level tools for manipulating the DIT. |
53 |
|
54 |
That's what I'm doing *now* while I deal with other aspects of the |
55 |
system administration and configuration. I will be coming back to |
56 |
re-visit the issue, writing my own wrapper scripts around the ldapX |
57 |
tools if necessary. |
58 |
|
59 |
> The problem you have when trying to use native unix binutils type |
60 |
> commands is that they don't deal with the auth layer in the ldap |
61 |
well, |
62 |
> that is when you invoke say chsh to change someones shell you need to |
63 |
> auth as someone other then yourself (if you are trying to manipulate |
64 |
> another users info)and it is that step that will _generally_ require |
65 |
a |
66 |
> password in a file somewhere. |
67 |
|
68 |
What the ldap{add,modify,delete} tools let you do is specify the dn you |
69 |
want to connect as, and they can be configured to prompt for the |
70 |
password. An ldap-aware shadow suite replacement would need to be told |
71 |
somehow that it was using ldap, and then it could either have the |
72 |
"privileged" dn to connect as within a configuration file, or that |
73 |
could be prompted for as well, no different than prompting for a login. |
74 |
|
75 |
__________________________________________________ |
76 |
Do You Yahoo!? |
77 |
Tired of spam? Yahoo! Mail has the best spam protection around |
78 |
http://mail.yahoo.com |
79 |
-- |
80 |
gentoo-server@g.o mailing list |