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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
