[Freeipa-users] FreeIPA for Linux desktop deployment

[JR Aquino]

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:
>> 
>>> Hi,
>>> 
>>> 
>>> I would like to see the ipa client scripts and possibly the admin tools
>>> 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 don't
>>> see a considerable benefit in adding SSSD to servers, who will be well connected to the network
>>> anyway.
>> 
>> 
>> 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 authorization.

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

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

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.

> 
> 
> Rgds,
> Siggi
> 
> 
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users