[Freeipa-devel] More types of replica in FreeIPA

[Simo Sorce]

On Thu, 2012-04-19 at 16:29 -0400, Dmitri Pal wrote:
> 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.

Well if we have to go through all these steps just to cache the user
password we can also simply replicate the userPassword attribute for
select users and just not the kerberos keys. Much simpler architecture
and gives you the same results w/o any chaining at all.

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

Yes, but I was assuming Kerberos to be naturally necessary. If an
organization deploys kerberized services then naturally users will have
to use them. Case in point the Web UI for FreeIPA itself.

Proxying pure LDAP is a solved problem, there are a number of
meta-directories that could probably also allow caching LDAP binds, I
think we want to concentrate on a solution that gives you the full
functionality of a freeIPA realm, but that's just me. I am not opposed
to a lesser solution, just not sure we should concentrate too many
energies into it.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York