[Freeipa-users] A couple of quick questions about FreeIPA

[Paul Robert Marino]

Thank You every one for answering so quickly

On Thu, Apr 26, 2012 at 1:20 PM, Simo Sorce <simo at 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.