[Freeipa-devel] More types of replicas in FreeIPA

[Dmitri Pal]

On 02/12/2013 08:20 AM, Simo Sorce wrote:
> 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.
>
It looks like thinks are starting to boil down to building a Kerberos proxy.
Is this something that fits within your thesis agenda Ondra?

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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