heya,
On Tue, 2005-07-26 at 16:15 -0700, Bill Johnstone wrote:
> Let me preface everything I'm about to say by constraining it to the
> domain of Unix users in the typical command-line and/or X environment.
>
> I suppose allowing anon binds is marginally less secure than needing to
> be logged into a Unix system to read the plaintext /etc/passwd , but if
> you run a finger service that allows outside finger @<hostname>
> (admittedly, that's uncommon these days), it's no more insecure than
> that. However, you could use host-based access controls to only permit
> connections from your network's own IPs and in fact I'm sure you're
> already doing something to this effect, since to do otherwise would be
> sloppy system administration.
>
> Also, as Arturo Busleiman said, the userPassword is not simply readable
> by anyone binding as anon (assuming the ACLs are correct), so again the
> info available via anon bind is no more "secret" than the plaintext
> contents of /etc/passwd .
I am not making myself clear because both of you are misunderstanding
me. I am not suggesting that it makes the password any more accessible I
am talking about being uncomfortable allowing ANYONE to bind to my DIT
and see the DIT's structure at all. I could of course start putting more
and more ACLs on the DIT to ensure that anon binds could only see a tiny
amount of information but then when the DIT changes I have to try and
maintain my ACLs and its a needless complication imo. Instead I think it
is much more secure to simply require an auth bind BEFORE giving away
ANY information, even information as trivial as to the layout of the DIT
or the subtree's etc etc.
> Can they be configured to do so?? That was one of the questions I was
> asking in the first place. Without having changed the PAM config for
> those commands, but having changed the system-auth policy to use ldap,
> I have found chsh and chfn to explicitly look in /etc/passwd and fail
> when they don't find a user there. If this is a matter of me needing
> to reconfigure PAM to tell them to use LDAP, then by all means, please
> tell me how.
the changes you made for system-auth in /etc/pam.d/chsh should do it.
> That's what I'm doing *now* while I deal with other aspects of the
> system administration and configuration. I will be coming back to
> re-visit the issue, writing my own wrapper scripts around the ldapX
> tools if necessary.
I see, precisely what would your wrapper tools do that would be better
then just invoking ldapX ? You have said that your users are happy on
the unix command line so I am not sure what you are trying to gain via
using wrappers.
> What the ldap{add,modify,delete} tools let you do is specify the dn you
> want to connect as, and they can be configured to prompt for the
> password. An ldap-aware shadow suite replacement would need to be told
> somehow that it was using ldap, and then it could either have the
> "privileged" dn to connect as within a configuration file, or that
> could be prompted for as well, no different than prompting for a login.
I know what they allow you to do, but that is precisely my point (again
I am obviously not explaining myself well). The point is that all of the
usual command line tools are NOT LDAP aware (eg poppasswd_ceti) so that
when using auth binds and LDAP the tool breaks because it gets an extra
prompt request. Eg on a LDAP aware system using "passwd" shows the
following behaviour:
Normal system:
[~]# passwd
New UNIX password:
Retype new UNIX password:
passwd: password updated successfully
[root] [photon] 0 0.24 [10:09:51]
[~]#
Whereas on a LDAP system:
[~]# passwd
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
passwd: password updated successfully
[root] [photon] 0 0.24 [10:09:51]
[~]#
My point being that most of the command line tools don't deal with that
extra prompt. Even if they do and you are trying to use them in an
automated manner to manage OTHER accounts, then you must keep the auth
bind password somewhere on the system in a file.
regards,
Benjamin Smee (strerror)
--
[email protected] mailing list
