John,
Thanks again for the information! As I go through this process I am sure it will be invaluable. I am making progress but I have also run into a specific problem. I am going to post this to the entire group since it does not specifically have to do with your prior informtion. I may post to this thread in the future with questions specific to your instrucitons. This is sort of a long term project for me that I am working on besides my other responsibilities. Anyway I guess I am trying to say "stay tuned."
Thanks again, Doug
On Mon, Jun 8, 2009 at 4:41 AM, John A. Sullivan III
<jsullivan@opensourcedevel.com> wrote:
On Sun, 2009-06-07 at 14:33 -0500, Doug Coats wrote:
> Thanks a ton John! This certainly gives me somewhere to start. Now I
> just need to figure out what parts Linux needs to authenticate to
> begin with. Do I need SSL if all of my LDAP reequests are coming from
> internal servers?
<snip>
The bottom part of the plan should give you most of that information.
Some of the essential bits are in the clientsetup script we created and
I really shouldn't post that. We do set up our users with
objectlclasses of posixaccount and ntuser (I believe that's correct). On
RedHat systems we also do something that I believe is technically
incorrect, we add a posixgroup objectclass to the users to account for
the personal group created by default.
To keep the IDs unique among all the systems, we enforce unique uid,
uidnumber, and gidnumber and, for other reasons in our multi-client
environment, cn. This is one of the major reasons why we divide our DIT
at the top level between Internal objects (which must enforce this
uniqueness) and External objects (such as client contact lists) which do
not enforce that uniqueness.
At that point, one can use ldap.conf, nsswitch.conf, and the pam.d
modules (largely configured automatically by, oh I forget the package
name, I think it is authconfig - it's in the plan) to allow the Linux
systems to authenticate users against LDAP.
Certainly because we are a multi-client environment but even if we
weren't, we do not believe in the hard and crunchy outside, soft and
chewy inside security model. The network revolution means the primary
attack vector is now on the inside of the network and not the outside.
Truth be told, it always was. That's why we use SSL even on the
internal network. If someone plants a protocol analyzer on the network,
with a little bit of ARP poisoning, there's nothing they can't see
traversing the wire. That's why we launched the ISCS network security
project (http://iscs.sourceforge.net) and tend to "firepipe" rather than
firewall our networks.
Hope this helps - John
--
John A. Sullivan III
Open Source Development Corporation