On 05/11/2011 01:51 PM, 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.

This is not enough. Think about highly distributed environments with
small offices. You are not going to have the IPA server in every place.
The outage might be related to the network connectivity between the data
centers. Also think about cloud. We do not know yet what kind of outages
or latency issues some will face in highly dynamic environments but for
sure SSSDs caching would be very handy.

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

Netgroups is the concept that we try to phase out. It will take quite a
while but native sudo+sssd integration is one of the steps forward along
this long and thorny path.

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

We are all open for the competitor to take sssd and support on their OSSes.

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to