[Freeipa-devel] More types of replicas in FreeIPA

[Simo Sorce]

On Mon, 2013-02-11 at 20:30 -0500, Dmitri Pal wrote:
> On 02/11/2013 03:21 PM, Simo Sorce wrote:
> > On Mon, 2013-02-11 at 21:03 +0100, Ondrej Hamada wrote:
> >> Dne 3.2.2013 02:51, Dmitri Pal napsal(a):
> >>> On 01/31/2013 06:09 PM, Ondrej Hamada wrote:
> >>>> Hello,
> >>>> I'm starting to work on my thesis about 'More types of replicas in
> >>>> FreeIPA' again. One of the main problems is the way how should the
> >>>> read-only replicas deal with KDC because they're not supposed to
> >>>> posses the Kerberos (krb) master key. The task was to investigate how
> >>>> is this solved in Active Directory and its Read Only Domain Controllers.
> >>>>
> >>>> I found out that the basic of RODC behaviour is described on technet
> >>>> page
> >>>> (http://technet.microsoft.com/en-us/library/cc754218%28v=ws.10%29.aspx).
> >>>>
> >>>> Login situation:
> >>>> RODC by default forwards the KRB requests to the DC. RODC then
> >>>> forwards the response back to the client and also requests the
> >>>> password to be replicated to RODC. Both the user and his host must be
> >>>> members of 'Allowed RODC Password Replication' group in order to let
> >>>> user's passwords being replicated to RODCs.
> >>>>
> >>>> Request services that the RODC doesn't have credentials for:
> >>>> Client sends TGS-REQ to RODC. RODC can read the TGT in the request,
> >>>> but doesn't have credentials for the service. So the request is
> >>>> forwarded to the DC. DC can decrypt the TGT that was created by RODC
> >>>> and sends back the TGS-RES that is forwarded to the client. (but it
> >>>> does not trust the RODC so it recalculates the privilege attribute
> >>>> certificate). RODC does not cache the credentials for the service.
> >>>>
> >>>> During my experiments the credentials got replicated to the RODC on
> >>>> the first log on of the user. The user's KRB requests were first
> >>>> forwarded to the DC. When the user got krbtgt and TGS for host, ldap
> >>>> and cifs, his TGT was revoked by RODC. He run through the auth.
> >>>> process again, but this time the requests were served by RODC only -
> >>>> no forwarding - and not TGS for host was requested.
> >>>>
> >>>> Unfortunately I can not still recognize how the keys are processed.
> >>>> There's barely any RPC communication - only one DCERPC packet exchange
> >>>> between RODC and DC that takes place when the user sends his first TGS
> >>>> request (this exchange happens also for the clients with disabled
> >>>> replication).
> >>>>
> >>>> It looks to me like the DC knows all the RODC keys. According to
> >>>> Technet, the MS implementation of Kerberos is able to recognize the
> >>>> key owner from the Key Version Number value.
> >>>>
> >>>> I think I can't get more info from the network traffic examination. Do
> >>>> you have any ideas or hints on further investigation of the problem?
> >>> The page you listed shows the diagrams of the user login and TGT and
> >>> then TGS acquisition.
> >>> http://technet.microsoft.com/en-us/library/cc754218%28v=WS.10%29#BKMK_AuthRODC
> >>> Also the following thread sheds some good light on how the
> >>> authentication and caching happens in case of the RODC.
> >>> http://social.technet.microsoft.com/forums/en-US/winserverDS/thread/f8d1017e-1f0e-4a9d-a241-b03b508dfe17
> >>> So they have policy driven replication of passwords.
> >>> If password is allowed to be replicated by policy it is replicated if
> >>> not it RODC has to always proxy to RWDC for this account.
> >>> The password changes always happen on RWDC and replicated back.
> >>> They can be replicated by RSO operation that allows replicating a single
> >>> object.
> >>>
> >>> It seems that they assume that all the services are always remote thus
> >>> connectivity to the central RWDC is a must.
> >>> They do not seem to keep any service keys locally in the RODC.
> >>>
> >>> With SSSD in play on the client I am not sure we should worry about
> >>> caching at least in the first implementation.
> >>> So in our case it might make sense to have a proxy KDC and a RO replica
> >>> with the subset of data replicated to it.
> >>> I wonder if you can accomplish that by taking 389 RO replica + IAKERB
> >>> I suggest you look at IAKERB and see if it can be used as a proxy for
> >>> user authentication, password change and TGS requests.
> >>> If not may be we can at least use it as an inspiration.
> >>>
> >>> The attached diagram shows what I mean.
> >>>
> >>> Later we can add some logic for the following:
> >>> a) RODC requesting replication of a specific object
> >>> b) RWDC replicating a specific object
> >>> c) Policy to define for which accounts the passwords and keys can replicated
> >>> d) RODC getting policy and performing local authentication for the
> >>> accounts for which the keys were replicated.
> >>>
> >>> However with SSSD on the client it might be easier for KDC proxy just to
> >>> go offline and not respond to the SSSD if it loses connection to the
> >>> central server.
> >>> That would force SSSD to go offline and use local password caching. I
> >>> suspect that SSSD password caching would be enabled in many cases
> >>> anyways so not caching all passwords in one central locating in RODC
> >>> might actually be a good thing.
> >>>
> >> Thanks for hints. I was looking at IAKERB and according to RFC it should 
> >> support both AS and TGS requests/replies so it might be doable. I'll try 
> >> to prepare a prototype that will be using 389 RO replica and IAKERB as 
> >> you proposed.
> > IAKERB is a GSSAPI level interface, it is not something you can use as a
> > KDC Proxy on its own.
> > An actual KDC proxy is what is needed because you cannot change
> > applications at will and there are a number of applications that just go
> > and talk straight to a KDC server to do AS and TGS requests.
> >
> > A KDC proxy is possible to build, it just require some work in the
> > Actual KDC and probably some custom protocol to talk between KDCs.
> > We should look into what is the simplest technical way to achieve this
> > and perhaps propose it for standardization in IETF.
> >
> > Simo.
> >
> Really? I was hoping that IAKERB is exactly what you have described.
> Are you saying that IAKERB requires changes to the client?
> That sounds strange.

Clients using GSSAPI may not require may not require changes, but not
all Kerberos clients use a modern GSSAPI library.
Even SSSD uses direct Kerberos calls,a s traditionally there is no way
to get initial tickets via GSSAPI. That is slowly changing but it will
be a long time before that happens.

Simo.

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