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

[Simo Sorce]

On Thu, 2012-04-26 at 16:52 -0400, Paul Robert Marino wrote:
> Thank You every one for answering so quickly

> 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.

Use replicas with forntend servers, that way you will at most bring down
a replica but not the core infrastructure.

> 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.

Yes, tuning is always important when dealing with network facing
services, you will be required to tune your installations in all cases.

With sssd we replace nscd simply because it knows better when it make
sense to make a query, how to pool queries, and when servers are not
reachable and it can immediately answer back.
Also we added a shmem bases cache to pam_sss in master that brings
performance on par with nscd for the cases where it matters most.


> 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.

Well we have no magic wand here do we :-)
If you have those applications you will have to decide if it is a good
idea to relax permissions on userPassword or if it is possible to modify
the application or use alternatives.

> 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.

Yes, we are planning to eventually extend this method to a usable method
for third party apps on other servers through standard APIs, but we are
not there yet.


> 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,

FWIW all of samba except libsmbclient is not multi-threaded and is
largely non multi-thread safe, so I am not really sure why that would
have been an issue there, but it is fixed, and we are all happy now :)

> 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.

A few other samba libraries cough*nss_winbindd*cough were also not
thread safe until relatively recently ... this things happen, and they
get fixed.

> 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.

We are working on cross realm trust as the next big feature, that will
allow you to have a separate infrastructure for network gear if you like
and still be able to authenticate from one realm to the other.

IPA-IPA cross realm is not fully tabled yet, it will come after our
first stab at AD-IPA cross realm trust support.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York