[Freeipa-devel] More types of replica in FreeIPA

[Dmitri Pal]

On 04/19/2012 12:33 PM, Simo Sorce wrote:
> On Thu, 2012-04-19 at 10:10 -0400, Dmitri Pal wrote:
>> If the eSSO is not required and we talk about the initial login only
>> we
>> can have a DS instance as a consumer do not need to have the whole IPA
>> becuase KDC, CA and management frameworks are not needed. This DS can
>> replicate a subset of the users, groups and other data using
>> fractional
>> replication for the identity lookups can and use PAM pass-through
>> feature with SSSD configured to go to the real master for
>> authentication. 
>>
> What's the point of a "login" server if SSSD then has to go and talk to
> a different remote server ?
> I mean what is the use case ?

Local server is the central hub for the authentications in the remote
office. The client machines with SSSD or LDAP clients might not have
access to the central datacenter directly. Another reason for having
such login server is to reduce the traffic between the remote office and
central data center by pointing to the clients to the login server for
the identity lookups and cached authentication via LDAP with pam proxy
and SSSD under it.

The SSSD will be on the server.

> Also we need to keep in mind that we cannot assume SSSD to be always
> available on clients.

We can assume that SSSD can be used on this login server via pam proxy.
> Also replicating a subset of user is easy, but once you try to decide
> about other data it becomes progressively more difficult, do you
> replicate all the groups that are referenced by the users you
> replicated ? (not possible with current fractional replication)
> What about HBAC and hosts groups and sudo rules ... ?
> Or do we let admins decide what to replicate and rely on referrals to
> resolve missing parts referenced by the users ?
>
> Referrals have 2 issues: a lot of clients do not support them properly
> and they would probably break the compat plugins (although I guess we
> can fix the plugins to add referrals as well for the ldap part).

I agree with the questions and challenges. This is something for Ondrej
to research as an owner of the thesis but I would think that it should
be up to the admin to define what to synch. We have a finite list of the
things that we can pre-create filter for.

Think about some kind of the container that would define what to replicate.
The object would contain following attributes:

uuid - unique rule id
name - descriptive name
description - comment
filter - ldap filter
base DN - base DN
scope - scope of the search
attrs - list of attributes to sync
enabled - whether the rule is enabled

we can define (but disable by default) rules for SUDO, HBAC, SELinux,
Hosts etc and tel admin to enable an tweak.

> Simo.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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