[Freeipa-devel] More types of replicas in FreeIPA

[Dmitri Pal]

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.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/