There are three parties:
The client constructs an authenticator – a package with such information as:
The authenticator is valid for only some period of time so that it cannot be captured and re-played by a hacker.
Some information about the client in the authenticator is unencrypted and a portion of it is encrypted using the user's password as the encryption key.
This part is important because it emphasized the fact that kerberos doesn't share the password over the network but uses it as a shared secret. KDC then tries to decrypt the encrypted part of the authenticator and if it can't – it means that the client merely used a wrong password for encryption – because KDC does know the password of the user.
But, if KDC can decrypt – it means that the client is who they claim they are and responds to it with a TGT – a ticket granting ticket. And KDC encrypts TGT with its own encryption key that only it knows.
From this point, the client has TGT. TGT, on the client's side, is stored in kerberos cache. It can have many forms [2] and it is configured in krb5.conf with default_ccache_name parameter in libdefaults section.
Then, for every resource the client wants to access, it sends the TGT back to the KDC and asks for a ticket to access the resource.
At this point KDC doesn't check anything about the client as in the previous step (where it decrypts the authenticator). KDC simply uses its own key to decrypt TGT (as it was encrypted by this very key previously).
TGTs are ususally valid for 24 hours so that they usually need to be destroyed and renewed (also, by default in IPA – up to 7 days) – see kdc.conf and krb5.conf.
So, KDC decrypts the TGT and responds to the client with a ticket that is encrypted with the password the resource uses to log on the same way the client does (as they are both kerberos principals). Thus when the client wants to access the resource and sends the ticket, the resource can decrypt it because the ticket was encrypted with its own key.
The resource opens the ticket and reads the username of the client and what groups they are member of. And it will use that information to decide what it's allowed to access. And every time the client wants to communicate with the resource – it has to send their requests along with the copy of the ticket so that the resource doesn't have to store anything in memory.