133 lines
8.3 KiB
HTML
133 lines
8.3 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="How does network authentication service work?" />
|
||
|
|
<meta name="abstract" content="Use the following information to understand how network authentication service works." />
|
||
|
|
<meta name="description" content="Use the following information to understand how network authentication service works." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzakhconcept.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzakhhowdoes" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>How does network authentication service work?</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzakhhowdoes"><a name="rzakhhowdoes"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">How does network authentication service work?</h1>
|
||
|
|
<div><p>Use the following information to understand how network authentication
|
||
|
|
service works.</p>
|
||
|
|
<p> 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. </p>
|
||
|
|
<p>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.</p>
|
||
|
|
<p><strong>iSeries as
|
||
|
|
a server</strong></p>
|
||
|
|
<p>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. </p>
|
||
|
|
<p>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<sup>®</sup> <img src="eserver.gif" alt="e(logo)server" /> iSeries Access
|
||
|
|
for Windows<sup>®</sup>.</p>
|
||
|
|
<br /><img src="rzakh500.gif" alt="iSeries as Kerberos server" /><br /><div class="p"><blockquote>This description provides an overview of how this authentication process
|
||
|
|
works within a network: <ol><li>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).</li>
|
||
|
|
<li>The Kerberos server validates his principal name and password and sends
|
||
|
|
a TGT to jday.</li>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>The Kerberos server responds with the service ticket.</li>
|
||
|
|
<li>The application sends the service ticket to the iSeries service to authenticate the user.</li>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>Using an EIM association, the Kerberos principal is then mapped to the i5/OS user
|
||
|
|
profile</li>
|
||
|
|
</ol>
|
||
|
|
</blockquote>
|
||
|
|
</div>
|
||
|
|
<p><strong>iSeries as
|
||
|
|
a client</strong></p>
|
||
|
|
<p>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.</p>
|
||
|
|
<br /><img src="rzakh503.gif" alt=" iSeries client in Kerberos network" /><br /><div class="p"><blockquote>This description provides an overview of how this authentication process
|
||
|
|
works within a network: <ol><li>A principal, jday signs in to iSeries A and then requests a ticket-granting
|
||
|
|
ticket by performing a <span class="cmdname">kinit</span> command in the Qshell Interpreter.
|
||
|
|
The iSeries sends
|
||
|
|
this request to the Kerberos server.</li>
|
||
|
|
<li>The Kerberos server validates his principal name and password and sends
|
||
|
|
a ticket granting ticket to jday.</li>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>The Kerberos server responds with the service ticket. <div class="note"><span class="notetitle">Note:</span> 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.</div>
|
||
|
|
</li>
|
||
|
|
<li>The application sends the server ticket to the iSeries service to authenticate the user.</li>
|
||
|
|
<li>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.</li>
|
||
|
|
<li>Using EIM association, the Kerberos principal is then mapped to the i5/OS user
|
||
|
|
profile</li>
|
||
|
|
</ol>
|
||
|
|
</blockquote>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakhconcept.htm" title="Network authentication service supports Kerberos protocols and Generic Security Service (GSS) APIs that provide user authentication in a network.">Concepts</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|