The software described in this documentation is either in Extended Support or Sustaining Support. See https://www.oracle.com/us/support/library/enterprise-linux-support-policies-069172.pdf for more information.
Oracle recommends that you upgrade the software described by this documentation as soon as possible.

23.6 About Kerberos Authentication

Both LDAP and NIS authentication optionally support Kerberos authentication. In the case of IPA, Kerberos is fully integrated. Kerberos provides a secure connection over standard ports, and it also allows offline logins if you enable credential caching in SSSD.

Figure 23.5 illustrates how a Kerberos Key Distribution Center (KDC) authenticates a principal, which can be a user or a host, and grants a Ticket Granting Ticket (TGT) that the principal can use to gain access to a service.

Figure 23.5 Kerberos Authentication

The figure illustrates how a Kerberos Key Distribution Center (KDC) authenticates a principal, which can be a user or a host, and grants a Ticket Granting Ticket (TGT) that the principal can use to gain access to a service.


The steps in the process are:

  1. A principal name and key are specified to the client.

  2. The client sends the principal name and a request for a TGT to the KDC.

    The KDC generates a session key and a TGT that contains a copy of the session key, and uses the Ticket Granting Service (TGS) key to encrypt the TGT. It then uses the principal's key to encrypt both the already encrypted TGT and another copy of the session key.

  3. The KDC sends the encrypted combination of the session key and the encrypted TGT to the client.

    The client uses the principal's key to extract the session key and the encrypted TGT.

  4. When the client want to use a service, usually to obtain access to a local or remote host system, it uses the session key to encrypt a copy of the encrypted TGT, the client’s IP address, a time stamp, and a service ticket request, and it sends this item to the KDC.

    The KDC uses its copies of the session key and the TGS key to extract the TGT, IP address, and time stamp, which allow it to validate the client. Provided that both the client and its service request are valid, the KDC generates a service session key and a service ticket that contains the client’s IP address, a time stamp, and a copy of the service session key, and it uses the service key to encrypt the service ticket. It then uses the session key to encrypt both the service ticket and another copy of the service session key.

    The service key is usually the host principal's key for the system on which the service provider runs.

  5. The KDC sends the encrypted combination of the service session key and the encrypted service ticket to the client.

    The client uses its copy of the session key to extract the encrypted service ticket and the service session key.

  6. The client sends the encrypted service ticket to the service provider together with the principal name and a time stamp encrypted with the service session key.

    The service provider uses the service key to extract the data in the service session ticket, including the service session key.

  7. The service provider enables the service for the client, which is usually to grant access to its host system.

    If the client and service provider are hosted on different systems, they can each use their own copy of the service session key to secure network communication for the service session.

Note the following points about the authentication handshake:

  • Steps 1 through 3 correspond to using the kinit command to obtain and cache a TGT.

  • Steps 4 through 7 correspond to using a TGT to gain access to a Kerberos-aware service.

  • Authentication relies on pre-shared keys.

  • Keys are never sent in the clear over any communications channel between the client, the KDC, and the service provider.

  • At the start of the authentication process, the client and the KDC share the principal's key, and the KDC and the service provider share the service key. Neither the principal nor the service provider know the TGS key.

  • At the end of the process, both the client and the service provider share a service session key that they can use to secure the service session. The client does not know the service key and the service provider does not know the principal's key.

  • The client can use the TGT to request access to other service providers for the lifetime of the ticket, which is usually one day. The session manager renews the TGT if it expires while the session is active.