Sun Enterprise Authentication Mechanism 1.0.2 Guide

Subsequent Authentications

After the client has received the initial authentication, each individual authentication follows the pattern that is shown in the following figure.

Figure 1-2 Obtaining Access to a Service

Flow diagram shows the client using a TGT to request a ticket from the KDC, and then using the returned ticket for access to the server.

  1. The client requests a ticket for a particular service (say, to rlogin into another machine) from the KDC by sending the KDC its ticket-granting ticket as proof of identity.

  2. The KDC sends the ticket for the specific service to the client.

    For example, suppose user joe wants to access an NFS file system that has been shared with krb5 authentication required. Since he is already authenticated (that is, he already has a ticket-granting ticket), as he attempts to access the files, the NFS client system automatically and transparently obtains a ticket from the KDC for the NFS service.

    For example, suppose the user joe uses rlogin on the server boston. Since he is already authenticated (that is, he already has a ticket-granting ticket), he automatically and transparently obtains a ticket as part of the rlogin command. This ticket allows him to rlogin into boston as often as he wants until it expires. If joe wants to rlogin into the machine denver, he obtains another ticket, as in Step 1.

  3. The client sends the ticket to the server.

    When using the NFS service, the NFS client automatically and transparently sends the ticket for the NFS service to the NFS server.

  4. The server allows the client access.

These steps make it appear that the server doesn't ever communicate with the KDC. The server does, though; it registers itself with the KDC, just as the first client does. For simplicity's sake, we have left that part out.