On 03/13/2012 01:13 AM, Dmitri Pal wrote:
On 03/12/2012 06:10 PM, Simo Sorce wrote:
On Mon, 2012-03-12 at 17:40 -0400, Dmitri Pal wrote:
On 03/12/2012 04:16 PM, Simo Sorce wrote:
On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote:
USER'S operations when connection is OK:
-------------------------------------------------------
read data ->  local
write data ->  forwarding to master
authentication:
-credentials cached -- authenticate against credentials in local cache
                          -on failure: log failure locally, update
data
about failures only on lock-down of account
-credentials not cached -- forward request to master, on success
cache
the credentials

This scheme doesn't work with Kerberos.
Either you have a copy of the user's keys locally or you don't, there is
nothing you can really cache if you don't.

Simo.

Yes this is what we are talking about here - the cache would have to
contain user Kerberos key but there should be some expiration on the
cache so that fetched and stored keys periodically cleaned following the
policy an admin has defined.
We would need a mechanism to transfer Kerberos keys, but that would not
be sufficient, you'd have to give read-only servers also the realm
krbtgt in order to be able to do anything with those keys.

The way MS solves hits (I think) is by giving a special RODC krbtgt to
each RODC, and then replicating all RODC krbtgt's with full domain
controllers. Full domain controllers have logic to use RODC's krbtgt
keys instead of the normal krbtgt to perform operations when user's
krbtgt are presented to a different server. This is a lot of work and
changes in the KDC, not something we can implement easily.

As a first implementation I would restrict read-only replicas to not do
Kerberos at all, only LDAP for all the lookup stuff necessary. to add a
RO KDC we will need to plan a lot of changes in the KDC.

We will also need intelligent partial replication where the rules about
which object (and which attributes in the object) need/can be replicated
are established based on some grouping+filter mechanism. This also is a
pretty important change to 389ds.

Simo.

I agree. I am just trying to structure the discussion a bit so that all
what you are saying can be captured in the design document and then we
can pick a subset of what Ondrej will actually implement. So let us
capture all the complexity and then do a POC for just LDAP part.

Sorry for inactivity, I was struggling with a lot of school stuff.

I've summed up the main goals, do you agree on them or should I add/remove any?


GOALS
===========================================
Create Hub and Consumer types of replica with following features:

* Hub is read-only

* Hub interconnects Masters with Consumers or Masters with Hubs
  or Hubs with other Hubs

* Hub is hidden in the network topology

* Consumer is read-only

* Consumer interconnects Masters/Hubs with clients

* Write operations should be forwarded to Master

* Consumer should be able to log users into system without
  communication with master

* Consumer should cache user's credentials

* Caching of credentials should be configurable

* CA server should not be allowed on Hubs and Consumers

--
Regards,

Ondrej Hamada
FreeIPA team
jabber: oh...@jabbim.cz
IRC: ohamada

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

Reply via email to