[Freeipa-users] FreeIPA for Linux desktop deployment

[Rob Crittenden]

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:
>>>>
>>>>> 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.
>>
>
> 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
> email.
>
> 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
> provided.
>
> 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
> tools.

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!

regards

rob