How network authentication service works

The IBM® i product can act as a server or a client in the Kerberos network. It is important to understand the authentication processes and the tickets flow in both of these situations.

The Kerberos protocol provides an authentication method for users and services on your network. As a network administrator, you can configure network authentication service so your IBM i platform accepts Kerberos tickets as a form of authentication. The IBM i product and several system-specific applications act as a client/server within a Kerberos network, requesting tickets for users and for services for authentication. The Kerberos protocol provides users and services a means to prove their identities (authenticate) to an entire network, but it does not authorize them to resources on that network. Specific authorization to IBM i functions is maintained through user profiles that are created on the IBM i operating system.

When a user is authenticated using Kerberos, that user is issued an initial ticket, called a ticket-granting ticket (TGT). The user can then use the TGT to request a service ticket to access other services and applications on the network. For authentication to work successfully, an administrator must register the users, IBM i service principals, and applications that use Kerberos protocol with the Kerberos server. The IBM i product can act either as a server, where principals request authentication to services, or it can act as a client requesting tickets for applications and services on the network. The following graphics show how tickets flow in both of these situations.

IBM i product as a server

This graphic shows how authentication works when a IBM i product acts as a server in a Kerberos network. In this graphic, the Kerberos server or key distribution center (KDC) located in PASE for i issues tickets to the principal, jday.

The principal, jday, wants to access an application on System A. In this case, Enterprise Identity Mapping (EIM) is used on the system to map the Kerberos principal to an IBM i user profile. This is done for any IBM i function that supports Kerberos authentication, such as IBM i Access Client Solutions.

System i product as Kerberos server
This description provides an overview of how this authentication process works within a network:
  1. The user, jday, authenticates to the Kerberos server by providing a principal and password when he signs into the Kerberos realm. This sends a request to the Kerberos server for a ticket-granting ticket (TGT).
  2. The Kerberos server validates his principal name and password and sends a TGT to jday.
  3. Jday needs access to an application on the IBM i platform. The Kerberos client application on jday's PC sends his TGT to the Kerberos server to request a service ticket for the specific application, such as IBM i Access Client Solutions. The user's workstation manages his credentials cache, which holds tickets and other identifying information for the user. These credentials are read from the cache as they are needed and new credentials are stored in the cache as they are obtained. This relieves the application of the responsibility for managing the credentials itself.
  4. The Kerberos server responds with the service ticket.
  5. The application sends the service ticket to the IBM i service to authenticate the user.
  6. The server application validates the ticket by calling the network authentication service APIs and optionally can send a response back to the client for mutual authentication.
  7. Using an EIM association, the Kerberos principal is then mapped to the IBM i user profile.

IBM i product as a client

This graphic shows how authentication works when a IBM i product acts as a client in a Kerberos network. In this graphic, the Kerberos server, which is located on the Windows server, issues tickets to the user who authenticated to Kerberos. System A can be authenticated to other services. In this example, EIM is used on System B to map the Kerberos principal to a user profile. This is done for any IBM i function that supports Kerberos authentication, such as QFileSvr.400.

System i client in Kerberos network
This description provides an overview of how this authentication process works within a network:
  1. A principal, jday signs in to System A and then requests a ticket-granting ticket by performing a kinit command in the Qshell Interpreter. The system sends this request to the Kerberos server.
  2. The Kerberos server validates the principal name and password and sends a ticket-granting ticket to jday.
  3. Jday needs access to an application on System B. By calling the Network Authentication Service APIs, the application sends jday's TGT to the Kerberos server to request a service ticket for the specific application or service. The principal's local machine manages a credentials cache, which holds tickets, session keys, and other identifying information for the user. These credentials are read from the cache as they are needed and new credentials are stored in the cache as they are obtained. This relieves the application of the responsibility for managing the credentials itself.
  4. The Kerberos server responds with the service ticket.
    Note: A service principal for System B needs to be added to the Kerberos server and network authentication service must also be configured on System B.
  5. The application sends the server ticket to the IBM i service to authenticate the user.
  6. The server application validates the ticket by calling the network authentication service APIs and optionally can send a response back to the client for mutual authentication.
  7. Using EIM association, the Kerberos principal is then mapped to the IBM i user profile.