<div>John, </div> <div> </div> <div>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." </div> <div> </div> <div>Thanks again, Doug<br><br></div> <div class="gmail_quote">On Mon, Jun 8, 2009 at 4:41 AM, John A. Sullivan III <span dir="ltr"><<a href="mailto:jsullivan@opensourcedevel.com">jsullivan@opensourcedevel.com</a>></span> wrote:<br> <blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"> <div> <div></div> <div class="h5">On Sun, 2009-06-07 at 14:33 -0500, Doug Coats wrote:<br>> Thanks a ton John! This certainly gives me somewhere to start. Now I<br>> just need to figure out what parts Linux needs to authenticate to<br> > begin with. Do I need SSL if all of my LDAP reequests are coming from<br>> internal servers?<br></div></div><snip><br>The bottom part of the plan should give you most of that information.<br>Some of the essential bits are in the clientsetup script we created and<br> I really shouldn't post that. We do set up our users with<br>objectlclasses of posixaccount and ntuser (I believe that's correct). On<br>RedHat systems we also do something that I believe is technically<br>incorrect, we add a posixgroup objectclass to the users to account for<br> the personal group created by default.<br><br>To keep the IDs unique among all the systems, we enforce unique uid,<br>uidnumber, and gidnumber and, for other reasons in our multi-client<br>environment, cn. This is one of the major reasons why we divide our DIT<br> at the top level between Internal objects (which must enforce this<br>uniqueness) and External objects (such as client contact lists) which do<br>not enforce that uniqueness.<br><br>At that point, one can use ldap.conf, nsswitch.conf, and the pam.d<br> modules (largely configured automatically by, oh I forget the package<br>name, I think it is authconfig - it's in the plan) to allow the Linux<br>systems to authenticate users against LDAP.<br><br>Certainly because we are a multi-client environment but even if we<br> weren't, we do not believe in the hard and crunchy outside, soft and<br>chewy inside security model. The network revolution means the primary<br>attack vector is now on the inside of the network and not the outside.<br> Truth be told, it always was. That's why we use SSL even on the<br>internal network. If someone plants a protocol analyzer on the network,<br>with a little bit of ARP poisoning, there's nothing they can't see<br> traversing the wire. That's why we launched the ISCS network security<br>project (<a href="http://iscs.sourceforge.net/" target="_blank">http://iscs.sourceforge.net</a>) and tend to "firepipe" rather than<br> firewall our networks.<br><br>Hope this helps - John<br> <div class="im">--<br>John A. Sullivan III<br>Open Source Development Corporation<br></div> <div class="im">+1 207-985-7880<br><a href="mailto:jsullivan@opensourcedevel.com">jsullivan@opensourcedevel.com</a><br><br><a href="http://www.spiritualoutreach.com/" target="_blank">http://www.spiritualoutreach.com</a><br> Making Christianity intelligible to secular society<br><br>--<br></div> <div> <div></div> <div class="h5">389 users mailing list<br><a href="mailto:389-users@redhat.com">389-users@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-directory-users</a><br> </div></div></blockquote></div><br>