Obtaining Access to a Specific Service

1. To request access to a specific service, the client must first have obtained a credential for the ticket-granting service from the authentication server, and a server credential from the ticket-granting service. See "Obtaining a Credential for the Ticket-Granting Service" and "Obtaining a Credential for a Server". The client can send a request to the server including ticket 2 and another authenticator. The authenticator is encrypted by using session key 2.

2. Ticket 2 was encrypted by the ticket-granting service with the service key for the service. Since the service key is known by the service principal, the service can decrypt ticket 2 and get session key 2. Session key 2 can then be used to decrypt the authenticator. If the authenticator is successfully decrypted, the client is given access to the service.

Figure 12-4 Obtaining Access to a Specific Service

Using the gsscred Table

The gsscred table is used by an NFS server when the server is trying to identify a SEAM user. The NFS services use UNIX IDs to identify users. These IDs are not part of a user principal or credential. The gsscred table provides a mapping from UNIX UIDs (from the password file) to principal names. The table must be created and administered after the KDC database is populated.

When a client request comes in, the NFS services try to map the principal name to a UNIX ID. If the mapping fails, the gsscred table is consulted. With the kerberos_v5 mechanism, a root/hostname principal is automatically mapped to UID 0, and the gsscred table is not consulted. Thus, there is no way to do special remappings of root through the gsscred table.