How does network authentication service work?

Use the following information to understand how network authentication service works.

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 iSeries™ system will accept Kerberos tickets as a form of authentication. The iSeries and several iSeries-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 i5/OS™ functions is maintained through user profiles that are created on i5/OS.

When a user authenticates using Kerberos, he or she 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, i5/OS service principals, and applications that will use Kerberos protocol with the Kerberos server. The iSeries 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.

iSeries as a server

This graphic shows how authentication works when an iSeries acts as a server in a Kerberos network. In this graphic, the Kerberos server or key distribution center (KDC) located in i5/OS PASE issues tickets to the principal, jday.

Principal jday wants to access an application on iSeries A. In this case, Enterprise Identity Mapping (EIM) is used on the server to map the Kerberos principal to an i5/OS user profile. This is done for any iSeries server function that supports Kerberos authentication, such as IBM® e(logo)server iSeries Access for Windows®.


iSeries 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 an iSeries server. The Kerberos client application on jday's PC sends his TGT to the Kerberos server to request a service ticket for the specific application or service, such as iSeries Navigator. 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 iSeries 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 i5/OS user profile

iSeries as a client

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


iSeries 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 iSeries A and then requests a ticket-granting ticket by performing a kinit command in the Qshell Interpreter. The iSeries sends this request to the Kerberos server.
  2. The Kerberos server validates his principal name and password and sends a ticket granting ticket to jday.
  3. Jday needs access to an application on iSeries 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 iSeries B needs to be added to the Kerberos server and network authentication service must also be configured on iSeries B.
  5. The application sends the server ticket to the iSeries 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 i5/OS user profile
Parent topic: Concepts