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