125 lines
8.2 KiB
HTML
125 lines
8.2 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="Network authentication service terminology" />
|
||
|
|
<meta name="abstract" content="Use the following information to understand Network authentication service terminology." />
|
||
|
|
<meta name="description" content="Use the following information to understand Network authentication service terminology." />
|
||
|
|
<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="rzakhterm" />
|
||
|
|
<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>Network authentication service terminology</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzakhterm"><a name="rzakhterm"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Network authentication service terminology</h1>
|
||
|
|
<div><p>Use the following information to understand Network authentication
|
||
|
|
service terminology.</p>
|
||
|
|
<p> Network authentication service uses the following Kerberos protocol terminology:</p>
|
||
|
|
<dl><dt class="dlterm">forwardable tickets</dt>
|
||
|
|
<dd>Forwardable tickets allow a server to pass on the credentials of the requester
|
||
|
|
to another service. For this to happen, the initial TGT must have been requested
|
||
|
|
with the forwardable option and the server is allowed to delegate credentials. </dd>
|
||
|
|
<dt class="dlterm">Kerberos server or key distribution center (KDC)</dt>
|
||
|
|
<dd>A network service that provides tickets and temporary session keys. The
|
||
|
|
Kerberos server maintains a database of principals (users and services) and
|
||
|
|
their associated secret keys. It is composed of the authentication server
|
||
|
|
and the ticket granting server. The authentication server issues ticket granting
|
||
|
|
tickets, while the ticket granting server issues service tickets. It is important
|
||
|
|
that you use a secure machine to act as your Kerberos server. If someone gained
|
||
|
|
access to the Kerberos server, your entire realm might be compromised. </dd>
|
||
|
|
<dt class="dlterm">key table</dt>
|
||
|
|
<dd>A file on the service's host system. Each entry in the file contains the
|
||
|
|
service principal's name and secret key. On the iSeries™, a key table file is created
|
||
|
|
during configuration of network authentication service. When a service requests
|
||
|
|
authentication to an iSeries with network authentication service configured,
|
||
|
|
that iSeries checks
|
||
|
|
the key table file for that service's credentials. To ensure that users and
|
||
|
|
services are authenticated properly, you must have users and services created
|
||
|
|
on the Kerberos server and on the iSeries server. Entries are added to
|
||
|
|
the key table during the finish processing of the Network Authentication Service
|
||
|
|
wizard. You can also add entries to the key table by using the <tt>keytab</tt> command
|
||
|
|
from within the Qshell Interpreter in a character-based interface. <div class="note"><span class="notetitle">Note:</span> This
|
||
|
|
DNS name must be the same as the host name defined on the machine. For more
|
||
|
|
information about how DNS and Kerberos work together, see <a href="rzakhpdns.htm#rzakhpdns">Host name resolution considerations</a>.</div>
|
||
|
|
</dd>
|
||
|
|
<dt class="dlterm">password server</dt>
|
||
|
|
<dd>Allows clients (principals) to change their password on the Kerberos server
|
||
|
|
remotely. The password server typically runs on the same machine as the Kerberos
|
||
|
|
server. </dd>
|
||
|
|
<dt class="dlterm">principal</dt>
|
||
|
|
<dd>The name of a user or service in a Kerberos realm. A user is considered
|
||
|
|
a person where a service is used to identify a specific application or set
|
||
|
|
of operating system services. On i5/OS™, the <strong>krbsvr400</strong> service principal
|
||
|
|
is used to identify the service used by iSeries Access for Windows<sup>®</sup>,
|
||
|
|
QFileSrv.400 and Telnet servers when authenticating from the client to the iSeries. </dd>
|
||
|
|
<dt class="dlterm">proxiable tickets</dt>
|
||
|
|
<dd>A proxiable ticket is a ticket granting ticket (TGT) that allows you to
|
||
|
|
get a ticket for a service with IP addresses other than those in the TGT.
|
||
|
|
Unlike forwardable tickets, you cannot proxy a new TGT from your current TGT;
|
||
|
|
you can only proxy service tickets. Forwardable tickets let you transfer your
|
||
|
|
complete identity (TGT) to another machine, where proxiable tickets only let
|
||
|
|
you transfer particular tickets. Proxiable tickets allow a service to perform
|
||
|
|
a task on behalf of a principal. The service must be able to take on the identity
|
||
|
|
of the principal for a particular purpose. A proxiable ticket tells the Kerberos
|
||
|
|
server that it can issue a new ticket to a different network address, based
|
||
|
|
on the original ticket granting ticket. With proxiable tickets, a password
|
||
|
|
is not required. </dd>
|
||
|
|
<dt class="dlterm">realm</dt>
|
||
|
|
<dd>A set of users and servers for which a given Kerberos server is the authenticating
|
||
|
|
authority. </dd>
|
||
|
|
<dt class="dlterm">realm trust</dt>
|
||
|
|
<dd>The Kerberos protocol either searches the configuration file, such as <strong>krb5.conf</strong>,
|
||
|
|
to determine realm trust or by default looks for trust relationships within
|
||
|
|
the realm hierarchy. Using <strong>Trusted realms</strong> in network authentication
|
||
|
|
service allows you to bypass this process and creates a shortcut for authentication.
|
||
|
|
Realm trust can be used in networks where realms are in different domains.
|
||
|
|
For example, if a company has one realm at NY.MYCO.COM and another at LA.MYCO.COM,
|
||
|
|
then you can establish trust between these two realms. If two realms trust
|
||
|
|
each other their associated Kerberos servers must share a key. Before creating
|
||
|
|
a shortcut, you must set up the Kerberos servers to trust each other. </dd>
|
||
|
|
<dt class="dlterm">renewable tickets</dt>
|
||
|
|
<dd>In some cases, an application or service may want to have tickets which
|
||
|
|
are valid for an extended period of time. However, the extended time might
|
||
|
|
allow someone to steal these credentials which are valid until the ticket
|
||
|
|
expired. Renewable tickets allow for applications to obtain tickets that are
|
||
|
|
valid for extended periods. Renewable tickets contain two expiration times.
|
||
|
|
The first expiration applies to the current instance of the ticket and the
|
||
|
|
second time applies to the latest permissible expiration for the ticket. </dd>
|
||
|
|
<dt class="dlterm">service ticket</dt>
|
||
|
|
<dd>A ticket that authenticates a principal to a service. </dd>
|
||
|
|
<dt class="dlterm">ticket-granting service (TGS)</dt>
|
||
|
|
<dd>A service provided by the Kerberos server that issues service tickets. </dd>
|
||
|
|
<dt class="dlterm">ticket-granting ticket (TGT)</dt>
|
||
|
|
<dd>A ticket that allows access to the ticket granting service on the Kerberos
|
||
|
|
server. Ticket granting tickets are passed to the principal by the Kerberos
|
||
|
|
server after the principal has completed a successful request to the authentication
|
||
|
|
server. In a Windows 2000 environment, a user logs on to the network
|
||
|
|
and the Kerberos server will verify the principal's name and encrypted password
|
||
|
|
and then send a ticket granting ticket to the user. From an iSeries server,
|
||
|
|
users can request a ticket using the kinit command within the Qshell Interpreter
|
||
|
|
in the character-based interface. </dd>
|
||
|
|
</dl>
|
||
|
|
</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>
|