Thank You every one for answering so quickly On Thu, Apr 26, 2012 at 1:20 PM, Simo Sorce <s...@redhat.com> wrote: > On Thu, 2012-04-26 at 12:57 -0400, Paul Robert Marino wrote: >> Hello >> I'm trying to figure out if free IPA is a good solution for my >> environment or if i should just construct a custom infrastructure with >> 389 server and i just have a couple of quick questions. I have a long >> history working with LDAPv3 and I'm currently planing a new >> infrastructure for my current employer. I've worked with OpenLDAP 389 >> server and even 389 servers original incarnation when Netscape was >> still around >> >> 1) Can the Kerberos server be on an other box. >> I'm not a python programer so I haven't been able to test it my self >> but many of the Kerberos calls look like wrappers to the C libraries. >> if so than it might be possible > > No. > Our install scripts support setting up the KDC only locally on the same > box for various reasons of simplicity and performance.
I understand the reasoning I just don't like sub components to be too dependent on each other, especially when talking about distributed authentication infrastructures. Ive had instances where a bug in a piece of software (or just a poorly written piece of software) has opened a ridiculous number of connections and caused cascading failures of LDAP servers due to exceeding the max file handle limit on the boxes usually its web apps that do it. In those instances the only thing that bought me enough time to deal with the issues before it caused a serious outage was the fact that my Kerberos servers were not effected and the fact that I had properly tuned nscd on the boxes. I know ssd and pam_nss are planed to completely replace it but I still find nscd very useful, and every place I've seen it cause problems it was because it was never properly tuned e.g. if you have a web server that accepts 1000 or more connections the maximum number of threads being limited to default of 32 is obviously far too low and results in the Apache processes DOSing it. that's how it winds up in states where it eats an entire cpu core and never seems to answer any queries essentially its still working through its backlog of expired queries, and eventually crashes if the problem persists. I also tend to double the deceptively named " suggested size" for passwd, group, and hosts as i find it significantly improves the hit rate and max number of cached values. > >> 2) Can I configure it not to store the Kerberos data in the LDAP >> server. I don't like the chicken and the egg authentication conundrum >> this can cause, and I have no intention of allowing users to use >> LDAPv2 so I actually don't want the password field in the database or >> at least blocked by an ACL so it cant be used. I personally find the >> fact that applications still use this field for authentication >> appalling because it essentially turned back the clock to before >> shadow password files. > > No, KDC data is in LDAP, but there is no chicken/egg issue, plus we do > not expose userPassword nor any of the krb5 keys to users (keys are > exposed to the KDC process of course). > You have to use LDAP simple binds or SASL/GSSAPI binds to authenticate > when you use IPA. glad to hear the userPassword is not exposed however many poorly written applications expect to login as a user that can see the field and than do the authentication themselves rather than doing a bind for each user who logs in. even Apaches LDAP auth modules do this, personally I think the idea behind "Auth MemCache Cookie" sounds close to the ideal way web apps should handle authentication for this kind of thing even for non LDAP auth because it avoids doing a full login for every file downloaded although admittedly I haven't tried that module yet. > >> 3) This is the most important question, there has been a lot of talk >> about fixing the issues with MIT Kerberos. Is there someplace I can >> look To see what the status of these fixes are other than pouring >> through the change logs for MIT Kerberos. > > Plans for what goes in various MIT Kerberos releases are generally > available on http://k5wiki.kerberos.org/, but the changelog is the > authoritative source of info for what is fixed in current releases. > >> I don't want to get in to a Kerberos holy war but most of these are >> really old bugs in MIT Kerberos that made me abandon the Idea of ever >> using the MIT server in production over a decade ago. I know exactly >> the issues that lead to the Samba group choose to code only to Heimdal >> all too well because I first remember hitting them and reporting them >> back 2001 to the Samba group via usenet. >> The big thing for me is the thread safety because this often caused >> the MIT Kerberos server to crash then Samba was running in domain mode >> on the same box, Honestly I still don't trust MIT's implementation in >> a mission critical environment, > > MIT Kerberos libraries are thread safe, this has been the case for a > long while now. If you have specific questions or doubts feel free to > ask. Glad to hear that the thread safety was fixed it has been a few years since i looked to that.it use to be quite a serious problem and not just for Samba, for those of you who were familiar with it. it was a libkrb5 issue that was caused usually when a multi-threaded app would try to simultaneously via local socket instead of the network. These condition usually resulted the Kerberos server crashing. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > I still have to think about it because there are still a few separation things I would like to do that I would still be prohibited from doing on one set of servers like have a second realm and OU just for my network gear. but ill definitely do some experiments before i make my final decision. _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users