[Freeipa-devel] More types of replicas in FreeIPA

[Ondrej Hamada]

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.