[Freeipa-devel] More types of replica in FreeIPA

[Dmitri Pal]

On 04/19/2012 03:44 PM, Simo Sorce wrote:
> On Thu, 2012-04-19 at 15:00 -0400, Dmitri Pal wrote:
>> 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.
> Sorry I do not get how SSSD is going to make any difference on the
> server.
>
>> 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.
>>
> This would be really complicated to manage. At the very least we need to
> define what's the expected user experience and data set access, then we
> can start devising technical solutions.
>
> What we really want to protect here, at the core, is user keys, for user
> and services not located in the branch office. All the info that is
> accessible from the branch office and is not super sensitive can always
> be replicated. The cost of choosing what to replicate and what not
> should be deferred to a later "enhancement". I would try to get the
> mechanism right for the authentication subset first, and deal with more
> fine-grained 'exclusions' later, once we solved that problem and gained
> experience with at least one aspect of data segregation.
>
> Simo.
>
I do not see a problem and it looks like you do not see the solution
that I see. So let me try again:

1) Consumer (remote office server) will sync in whatever user and other
data that we decide is safe to sync (may be configurable but this is a
separate question).
2) It will not sync the kerberos keys .
3) The authentication between clients and Consumer will be done using
LDAP since eSSO is not a requirement so Kerberos tickets are not needed
4) The consumer would use pam proxy to do the authentication against the
real master on the client behalf
5) We will configure SSSD under the pam proxy to point to the real
master. If access to the realm master is broken the authentication in
the remote office would still be successful as they would be performed
against credentials cached by SSSD.
Online case: client -> ldap auth -> Consumer -> pam proxy -> PAM ->
pam_sss -> SSSD -> real master
Offline case: client -> ldap auth -> Consumer -> pam proxy -> PAM ->
pam_sss -> SSSD -> SSSD cached credentials
6) We can assume that the Consumer is the latest RHEL and this can
leverage SSSD capabilities regardles of what OS or versions the actual
clients in the remote office run.
 

If we need Kerberos SSO in the remote office this is a different use case.
Does this make sense now?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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