Sigbjorn Lie wrote:
On 05/11/2011 09:25 PM, JR Aquino wrote:
On May 11, 2011, at 10:51 AM, Sigbjorn Lie wrote:

On Wed, May 11, 2011 14:42, Stephen Gallagher wrote:
On Tue, 2011-05-10 at 23:42 +0200, Sigbjorn Lie wrote:


I would like to see the ipa client scripts and possibly the admin
in a nice Solaris package. This would make my job a lot easier as
we have a lot of customers
running Solaris. :)

For the server part I agree with you, keep it at RHEL.

SSSD @ Solaris / HP-UX / AIX ... well there isn't much (if any) of the
UNIX vendors selling their iron as client machines anymore. And I
see a considerable benefit in adding SSSD to servers, who will be
well connected to the network

Actually, SSSD is still valuable on server systems (and is used very
often in datacenters). The reason is that it can allow a server to
ride out an outage in the LDAP
and/or Kerberos server and still handle authentication and identity
requests from its cache.

We've expressed interest several times in working WITH other platforms
to help them port the SSSD, but we've received no real commitment to
assisting with it. We have a
lot on our plates already, so it is difficult for us to justify
spending time improving our
competitors' offerings :)

Also, SSSD has additional features with FreeIPA integration that
nss_ldap and pam_krb5 do not. Specifically, it has support for
managing access-control using
FreeIPA's host-based access control model. This is
a very valuable piece of the puzzle and should not be ignored.

I see you're having a valid point about the outage support. This
could be worked around using the
"High Availability Add-on" in RHEL, sharing an IP address between
your IPA servers, which you
would switch to the currently active IPA server.
Not only is there a question of high availability with regard to
lookups into ldap. But there is also a problem of scale and overhead.

nss_ldap and pam_ldap perform a lookup per iteration in many cases.

Consider for example. 4 data centers with 100 servers each, all tied
back to ldap for uid/gid mappings and pam_ldap for authentication and

If you have a task that logs into each of these 400 servers and
performs a 'sudo ls -la /home' for example,
your ldap servers are going to incur the cost of looking up each file
on each server, the cost of each authentication, and the cost of
performing several ldap lookups from the sudo binary.

SSSD is not only beneficial during periods of network inaccessibility,
but also crucial with regard to scale.

With regards to IPA's host-based access control: What about doing
access control through using
netgroups via the tcp wrappers?

You could still be configuring host based access control in IPA as
it's creating transparent
netgroups for the host groups.
Host based access control is currently a mess in the Linux Community.

There are currently a few ways to go about it.

netgroups with
TCP Wrappers

^ This method implies that the changes in your central database must
eventually be pushed to flatfile configs on the end hosts.
While this works pretty well in small environments, it can fall apart
and have serious scale issues when dealing with hundreds or thousands
of hosts.
(Yes, even when using something like Satellite or Puppet)
Consider the case of Active Directory where you scratch your head and
go: "Gee, I'm SURE that i pushed that GPO, but for some reason, this
set of hosts didn't get the memo"

pam_ldap + pam_check_host_attr

^ This issue has a sheer drop off problem with scale. In this
approach, you need to fill the user objects with every host that the
user is permitted to login to.
When the number of users/administrators grow along with the number of
hosts you have, you get: n^users * n^hosts and the administrative
overhead becomes overwhelming.

These are all workarounds, I assume having the functionality
available trough the native sssd
would be of an advantage. But this way you would the mentioned extra
functionality of SSSD without
having to do the work of supporting your competitors operating
systems. :)
There have been _some_ discussions surrounding a pam module that could
be used as a very base level of hbac support since there are a lot of
pre-required dependancies for sssd.

The advantage would be theoretical portability, and the loss would be

I have personally written such a pam plugin prototype in python, and
it functions just fine in linux installations. the c code that calls
the python script is not compatible with open_pam,
so there is still work to be done to support the BSD / MAC solutions,
but I believe its just a matter of some syntax changes...

I hope this information helps clarify these points.

I wasen't going at SSSD for not being usable. I was trying to make a
suggestion for a alternative solution for using IPA with *nix OS' that
does not currently have SSSD.

I do agree that the host access controls in SSSD would be of great
benefit to any server. This is not a part of IPA I've not spent a lot of
time testing....yet....and I did not think about it before sending my

Back to the discussion, wouldn't nscd be able to cope with some of the
caching for ldap passwd,group, etc lookups? Not providing an offline
identity like SSSD would, but enough for the folder listings example you

You could also extend the High Availability configuration I mentioned
earlier with 1 high-available IP per IPA host, and serve them in a round
robin DNS. This would distribute the load of the LDAP server in IPA, and
provide high availability in case of a IPA server becoming unavailable.

The way I see it for our customers; when it comes to IPA integration
as-it-is-today, an ipa-client-install script for other *nix that would
configure kerberos, ldap client, and retrieves the host's keytab from
the IPA server would make a great improvement for IPA. Then the SSSD
could come at a later point.

The tricky bit is having all the required libraries. These other *nix operating systems tend not to have the things we need by default. Things are slightly better with Solaris 10 which ships with a slew of open source libraries (all old).

What I see as one of the selling points of IPA over any "*nix client for
Active Directory", is the ability to use the operating system built in

That's the idea of nss_ldap, etc. The trouble has been layering our other tools on top (ipa-getkeytab, ipa-join, etc.). I did manage to hack both to work on Solaris 10 a couple of years ago and remember nothing but pain, and the output would have been miserable to package.

Certainly in the realm of possibility but it represents a fair chunk of work. And that's just one Solaris release!



Freeipa-users mailing list

Reply via email to