On Tue, 2005-07-26, Benjamin Smee wrote:
> On Mon, 2005-07-25 at 21:34 -0700, Bill Johnstone wrote:
>> Yes, the LDAP setup has to allow anonymous binds, and auth access to
>> the userPassword attribute for anonymous. This is the typical way
>> LDAP is used for user authentication and name services in the Unix
>> environment, as the Gentoo LDAP Guide document indicates.
> The typical way, perhaps, but its fairly insecure imo, I don't like
> giving out more information then I have to and exposing my DIT to
anon
> binds is something that I dislike. Of course proper layout of the DIT
> means that there is nothing sensitive being exposed, but I still
don't
> like giving out ANY information to anon users. My level of paranoia
is
> not always appropriate for others though :)
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 .
> agreed, and I believe chsh etc can all be configured to change the
> relevant parts in the DIT as well.
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.
> and we come full circle. My initial comment was:
> "Well by putting your accounts into LDAP you really should be using
> LDAP management tools to manage it. " and that is precisely what you
> are doing. ldap{search,modify,add} are designed for that and are just
> low level tools for manipulating the DIT.
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.
> The problem you have when trying to use native unix binutils type
> commands is that they don't deal with the auth layer in the ldap
well,
> that is when you invoke say chsh to change someones shell you need to
> auth as someone other then yourself (if you are trying to manipulate
> another users info)and it is that step that will _generally_ require
a
> password in a file somewhere.
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.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
[email protected] mailing list
