Gentoo Archives: gentoo-server

From: Bill Johnstone <beejstone3@×××××.com>
To: gentoo-server@l.g.o
Subject: [gentoo-server] Re: Re: Re: Re: Practical user management with OpenLDAP?
Date: Tue, 26 Jul 2005 23:16:39
Message-Id: 20050726231504.31620.qmail@web33912.mail.mud.yahoo.com
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

Replies

Subject Author
[gentoo-server] Re: Practical user management with OpenLDAP? Benjamin Smee <strerror@g.o>