The client logon process
We look at how DC and clients communicate during logon process but in addition we also look at how a RODC gets passwords from a writeable domain controller and caches them locally. Each RODC has a krbtgt account . The krbtgt accounts are the credentials used by DCs to encrypt Kerberos messages. RODC keeps the password for this locally. However, writeable DCs keep all the passwords for krbgt accounts. Let us consider an example where a user logins to his PC and there are two DCs : one read-write and another read only. First the users machine will contact RODC and provide a Kerberos authentication service request packet. When the RODC receives this KRB_AS_REQ packet it will check its local database to see if it already has the user's password. If it does not, it will forward the RWDC and provide the KRB_AS_REQ it received. The RWDC will generate a KRB_AS_REP - a Kerberos authentication service reply and forward it back to RODC. This is then relayed to the user's machine. At this point, the users machine has a Kerberos ticket-granting ticket signed with the domain krbtgt account. Two additional steps are performed next. The RODC will request the RWDC to have the user PC's credential replicated to it. The RWDC will verify if such a policy is permitted and replicate the password.
Now let's look at the process of user authentication. The following are the steps taken when the user attempts to login to his machine.
The user presents his credential to his machine that sends a KRB_AS_REQ to the use. When the RODC receives this request, it will check its local database to see if there's a password cached otherwise it proceeds to the same steps that it took for machine account. However the user logon is still not complete. Before the user can use his workstation, he must obtain a Kerberos service ticket (TGS) for his PC. The user's machine sends the  KRB_TGS_REQ including the users TGT from the previous example. However RODC is unable to decrypt since it is encrypted with the domain krbtgt account. RODC transmits the KRB_TGS_REQ to RWDC who replies with the corresponding response. The RODC receives a valid KRB_TGS_REP. At this point instead of forwarding it to the user's machine, the RODC may decide to send an error indicating the ticket has expired. Since RODC now holds cached credentials for the user it is able to construct a new KRB_AS_REP locally and thus a new TGT for the user, encrypt it with the local krbtgt account and transmit it to the user's machine. The user's machine sends a new TGS request to RODC including the new TGT for the user which the RODC is able to decrypt and construct a TGS response permitting the user to use his PC. After completing these steps, the user is able to logon.