1 |
heya, |
2 |
|
3 |
On Tue, 2005-07-26 at 16:15 -0700, Bill Johnstone wrote: |
4 |
> Let me preface everything I'm about to say by constraining it to the |
5 |
> domain of Unix users in the typical command-line and/or X environment. |
6 |
> |
7 |
> I suppose allowing anon binds is marginally less secure than needing to |
8 |
> be logged into a Unix system to read the plaintext /etc/passwd , but if |
9 |
> you run a finger service that allows outside finger @<hostname> |
10 |
> (admittedly, that's uncommon these days), it's no more insecure than |
11 |
> that. However, you could use host-based access controls to only permit |
12 |
> connections from your network's own IPs and in fact I'm sure you're |
13 |
> already doing something to this effect, since to do otherwise would be |
14 |
> sloppy system administration. |
15 |
> |
16 |
> Also, as Arturo Busleiman said, the userPassword is not simply readable |
17 |
> by anyone binding as anon (assuming the ACLs are correct), so again the |
18 |
> info available via anon bind is no more "secret" than the plaintext |
19 |
> contents of /etc/passwd . |
20 |
|
21 |
I am not making myself clear because both of you are misunderstanding |
22 |
me. I am not suggesting that it makes the password any more accessible I |
23 |
am talking about being uncomfortable allowing ANYONE to bind to my DIT |
24 |
and see the DIT's structure at all. I could of course start putting more |
25 |
and more ACLs on the DIT to ensure that anon binds could only see a tiny |
26 |
amount of information but then when the DIT changes I have to try and |
27 |
maintain my ACLs and its a needless complication imo. Instead I think it |
28 |
is much more secure to simply require an auth bind BEFORE giving away |
29 |
ANY information, even information as trivial as to the layout of the DIT |
30 |
or the subtree's etc etc. |
31 |
|
32 |
> Can they be configured to do so?? That was one of the questions I was |
33 |
> asking in the first place. Without having changed the PAM config for |
34 |
> those commands, but having changed the system-auth policy to use ldap, |
35 |
> I have found chsh and chfn to explicitly look in /etc/passwd and fail |
36 |
> when they don't find a user there. If this is a matter of me needing |
37 |
> to reconfigure PAM to tell them to use LDAP, then by all means, please |
38 |
> tell me how. |
39 |
|
40 |
the changes you made for system-auth in /etc/pam.d/chsh should do it. |
41 |
|
42 |
> That's what I'm doing *now* while I deal with other aspects of the |
43 |
> system administration and configuration. I will be coming back to |
44 |
> re-visit the issue, writing my own wrapper scripts around the ldapX |
45 |
> tools if necessary. |
46 |
|
47 |
I see, precisely what would your wrapper tools do that would be better |
48 |
then just invoking ldapX ? You have said that your users are happy on |
49 |
the unix command line so I am not sure what you are trying to gain via |
50 |
using wrappers. |
51 |
|
52 |
> What the ldap{add,modify,delete} tools let you do is specify the dn you |
53 |
> want to connect as, and they can be configured to prompt for the |
54 |
> password. An ldap-aware shadow suite replacement would need to be told |
55 |
> somehow that it was using ldap, and then it could either have the |
56 |
> "privileged" dn to connect as within a configuration file, or that |
57 |
> could be prompted for as well, no different than prompting for a login. |
58 |
|
59 |
I know what they allow you to do, but that is precisely my point (again |
60 |
I am obviously not explaining myself well). The point is that all of the |
61 |
usual command line tools are NOT LDAP aware (eg poppasswd_ceti) so that |
62 |
when using auth binds and LDAP the tool breaks because it gets an extra |
63 |
prompt request. Eg on a LDAP aware system using "passwd" shows the |
64 |
following behaviour: |
65 |
|
66 |
Normal system: |
67 |
[~]# passwd |
68 |
New UNIX password: |
69 |
Retype new UNIX password: |
70 |
passwd: password updated successfully |
71 |
[root] [photon] 0 0.24 [10:09:51] |
72 |
[~]# |
73 |
|
74 |
Whereas on a LDAP system: |
75 |
[~]# passwd |
76 |
Enter login(LDAP) password: |
77 |
New UNIX password: |
78 |
Retype new UNIX password: |
79 |
passwd: password updated successfully |
80 |
[root] [photon] 0 0.24 [10:09:51] |
81 |
[~]# |
82 |
|
83 |
My point being that most of the command line tools don't deal with that |
84 |
extra prompt. Even if they do and you are trying to use them in an |
85 |
automated manner to manage OTHER accounts, then you must keep the auth |
86 |
bind password somewhere on the system in a file. |
87 |
|
88 |
regards, |
89 |
|
90 |
|
91 |
Benjamin Smee (strerror) |
92 |
-- |
93 |
gentoo-server@g.o mailing list |