[Freeipa-devel] More types of replicas in FreeIPA

[Dmitri Pal]

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.




>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: RODC.png
Type: image/png
Size: 89945 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130202/0085091e/attachment.png>