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.
-- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel