The information in this document is subject to change without notice.
Hewlett-Packard makes no warranty of any kind with regard to this
manual, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. Hewlett-Packard
shall not be held liable for errors contained herein or direct, indirect,
special, incidental or consequential damages in connection with the
furnishing, performance, or use of this material.
Warranty. A copy of the specific warranty terms applicable to your
Hewlett-Packard product and replacement parts can be obtained from
your local Sales and Service Office.
Restricted Rights Legend. Use, duplication or disclosure by the U.S.
Government is subject to restrictions as set forth in subparagraph (c) (1)
(ii) of the Rights in Technical Data and Computer Software clause at
DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and
(c) (2) of the Commercial Computer Software Restricted Rights clause at
FAR 52.227-19 for other agencies.
HEWLETT-PACKARD COMPANY
3000 Hanover Street
Palo Alto, California 94304
U.S.A.
Use of this manual and flexible disk(s) or tape cartridge(s) supplied for
this pack is restricted to this product only. Additional copies of the
programs may be made for security and back-up purposes only. Resale of
the programs in their present form or with alterations, is expressly
prohibited.
This manual describes how to install, configure, administer and trouble
shoot the Kerberos Server on HP 9000 servers running on HP-UX 11i.
17
Audience
HP intends this manual for system managers or administrators
responsible for configuring and maintaining the Kerberos server on
HP-UX 11i.
This manual is based on the assumption that you have:
•An understanding of distributed network concepts and client-server
computing
•Demonstrated knowledge of UNIX
•An understanding of the basics Kerberos
Related Software Products
•PAM Kerberos on HP-UX 11i delivered as part of the HP-UX
Internet operating environment component (HP-UX 11i-OE).
•KRB5 Client Software on HP-UX 11i delivered as part of the core
O/S.
•GSS-API on HP-UX 11i (J5849AA) delivered as part of the core O/S.
Related Documentation
•Configuration Guide for Kerberos Client Products on HP-UX
(T1417-9005)
18
•PAM Kerberos Release Notes for HP-UX 11i (J5849-90002)
•PAM Kerberos Release Notes for HP-UX 11.0 (J5849-90004)
•KRB5 Client Software Release Notes for HP-UX 11.0 (J5849-90005)
•GSS-API Release Notes for HP-UX 11.0 (J5849-90006)
•Installing and Administering Internet Services (B2355-90759)
•Using Internet Services (B2355-90148)
•HP-UX operating system version 11i or later - see Installing and
Updating HP-UX for HP 9000 Series 700, or Installing and Updating
HP-UX for HP 9000 Series 800.
•HP-UX IT Resource Center:
— http://us-support.external.hp.com (US and Asia Pacific)
— http://europe-support.external.hp.com (Europe)
•The Internet Engineering Task Force RFC Pages
— http://www.ietf.org/rfc.html
Related Request for Comments (RFCs)
•RFC 1510 - The Kerberos Network Authentication Service (V5)
•RFC 1964 - The Kerberos Version 5 GSS-API Mechanism
•RFC 2743 - Generic Security Service Application Program Interface
•RFC 2744 - Generic Security Service API
19
Conventions
The following conventions are used throughout this manual:
Text Conventions
italicIdentifies book titles
boldIdentifiescommand-lineoptions, command buttonsand
menu items
Syntax Conventions
fixed widthIdentifies file names, system prompts, operating
system commands, and UNIX error and system
messages
italic fixed Identifies variables that you need to replace according
widthto your environment
bold fixed Identifies the default in a series of parameters
width
|Separates mutually exclusive parameters; only one of
the parameters separated by the bar is allowed
[ ]Pair indicates that the enclosed parameter(s) are
optional
{ }Pair indicates that only one of the enclosed parameters
is required.
20
\Indicates that a command line, parameter, or code
continues in the following line
#Precedes a UNIX command that must be performed as a
root user
%Precedes a UNIX command that must be performed as
an ordinary user
Using This Manual
The Installing, Configuring and Administering the Kerberos Server on
HP-UX 11i manual describes how this product can provide the
infrastructure for your security needs. Use this guide as a road map to
find information that you need to configure and maintain the KerberosServer.
This manual is organized as follows:
•Chapter 1, Overview - Provides an introduction to the Kerberos
Server, outlines the new features in this release and highlights the
key advantages of using the Kerberos Server.
•Chapter 2, Installation - Describes the pre-requisites and the
procedure for installing the Kerberos Server.
•Chapter 3, Migration - Explains the migration process from
Kerberos Server V 1.0 to the latest version, Kerberos Server V
2.0.
•Chapter 4, Interoperability - Contains information specific to
establishing interoperability with Windows 2000 Kerberos
implementations.
•Chapter 5, Configuration - Provides information on the
Configuration files of the Kerberos Server.Theseconfigurationfiles
have been explained in detail with relevant examples and sample
files. Also, the process for configuring your Primary SecurityServer and Secondary Security Servers, have been explained
here.
•Chapter 6, Administration - Describes the procedures for
administering the Kerberos Servers’ database. It also entails a
discussion on Principals and their attributes.
•Chapter 7, Propagation - Describes the tools and procedures that
enable propagation of the Kerberos Server’s database from the
Primary Security Sever to the Secondary Security Servers.
•Chapter 8, Inter-realm - Explains inter-realm authentication and
interoperability trust. Also, a brief on the additional server
configuration requirements in deployments that use multiple realms
and inter-realm authentication.
that will enable you to resolve most of the common problems
encountered while using the Kerberos Server. Also, a brief note on
reporting problems to your Hewlett-Packard Support Contact is
provided here.
•Glossary
•Index
22
1Overview
This chapter provides an introduction to the HP’s Kerberos Server V
2.0, now available on HP-UX 11i.
Chapter 123
Overview
Chapter Overview
Chapter Overview
This chapter covers the following topics:
•“How The Kerberos Server Works” on page 25
•“Authentication Process” on page 27
•“DES vs 3DES Key Type Settings” on page 32
Chapter 124
Overview
How The Kerberos Server Works
How The Kerberos Server Works
The term “Kerberos” was derived from Greek mythology. “Cerberus” is
the latin variant of Kerberos who guarded the entrance of Hades, the
Greek hell. The Kerberos security system, on the other hand, guards
electronic transmissions that are sent across the network.
Kerberos is a mature network authentication protocol based on the RFC
1510 specification of the IETF. It is designed to provide strong
authentication for client or server applications by using the shared
secret-key cryptography.
The Kerberos Server is based on a distributed client-server
architecture. It ensures secure communication in a networked
environment by leveragingindividualtrustrelationships. It then brokers
that trust across enterprise-wide, distributed client-server networks.
The basic currency of Kerberos is the ticket, which the user presents in
order to use a specific service. Each service, be it a login service or an
FTP service, requires a different kind of ticket. Fortunately, the
Kerberized applications keep track of all the various kinds of tickets, so
you don’t have to.
When you first log on to Kerberos each day, you enter your Kerberos
password. In return, the Kerberos server gives you an initial ticket,
which you use to request for additional tickets from the Kerberos server
for all the other services. For this reason, the initial ticket is also often
called the ticket-granting-ticket, or TGT.
The communication between the client and server is secured by using the
Kerberos protocol. Thus, client programs make authentication requests
to an authentication server, and server programs in-turn service those
client requests. Based on a user’s credentials the server program grants
or denies a user’s request to access network applications and services.
The Kerberos Server allows entities to authenticate themselves,
without having to transmit their passwords in clear text form, over the
networks.
Chapter 125
Overview
How The Kerberos Server Works
NOTEFor more information on the basics of Kerberos, refer to Installing,
Configuring and Administering the Kerberos Server on HP-UX 11i
(T1417 -0001). This document is available at,
http://www.docs.hp.com
The next section describes the Kerberos Authentication process. This
section enables you to understand the intricacies of the Authentication
process.
Chapter 126
Overview
Authentication Process
Authentication Process
Toaid you in understanding the configuration and administration issues
this section describes the authentication process. The process of
Configuring and Administering your Kerberos Server have been
discussed in detail in the subsequent chapters of this manual.
Before the Kerberos Server grants tickets to a user principal to access
secured network services, a user must sign on to the Server by providing
knowledge of secret information, such as a user name and password.
Once the server authenticates the user, it returns a set of initial
credentials for the user, consisting of a ticket-granting-ticket (TGT)
and a session key.
A service ticket is granted for a specific service principal, which can be
associated with one or more Kerberos-secured services on the same
system. The service ticket is used by a client application on behalf of the
user, to authenticate the user to the Kerberos-secured network service.
The secured client application automatically handles the transactions
with the Server and the secured application server. Service tickets and
associated session keys are generally cached in the user’s credentials
cache along with the user’s TGT.
Chapter 127
Overview
Authentication Process
The figure shown below depicts the components of the secure
environment and the Kerberos protocol. Also, given below is a step-wise
procedure of how a client and server authenticate each other using
Kerberos. The step numbers match with the numbered arrows in the
figure below.
Figure 1-1Authentication Process
Step 1. The user begins to use a Kerberos-secured application by entering the
user principal name and password. Optionally, the user can request for
specific ticket flags and specify the key type to be used to construct the
secret key. The user can also accept the default, configured for the client.
Step 2. The Key Distribution Center (KDC) transforms the password into the
user’s secret key and uses it to construct a message, which it sends to the
Authentication Service (AS), requesting a TGT for the user. The AS is
the component of the Kerberos Server that grants initial tickets.
Chapter 128
Authentication Process
Step 3. If the AS can decrypt the message successfully, it knows that the
requesting user is who they claim to be, and issues a TGT. The TGT
contains the name of the user, a session key to be used by the user and
the Server for any subsequent communication. The reply message is
encrypted using the user’s secret key.
Step 4. The KDC decrypts the message using the user’s secret key. If the
application can successfully decrypt the message, the user is allowed to
use the application. The TGT and the session key from the message are
stashed in the user’s credential cache.
This protocol exchange has three important features namely:
•the authentication scheme does not require that the password be
sent across the network, either in encrypted form or in clear text
•tickets are not returned unless the principal name and password are
correct
•the client, or anyone else cannot look at or modify the contents of the
TGT
At the end of this initial exchange with the AS, the user’s credential
cache holds the user principal’s TGT and the associated session key.
These are used to obtain tickets for each network service the principal
wants to access.
Overview
To obtain access to a secured network service, the requesting client
application uses the previously obtained TGT in a dialog with the Server.
The protocol is the same as used while obtaining the TGT, except the
messages contain the name of the server, the message type and an
encrypted copy of the previously obtained TGT.
Step 5. The user runs a secured application, such as rlogin, rsh, rcp, ftp or telnet
Step 6. The secured application checks for the required service ticket in the
user’s credential cache. If it is there, skip to Step 10.
If the user does not have the required service ticket, the secured
application reads the user principal’s TGT and session key from the
user’s private credentials cache
Step 7. The secured applications sends its request for a specific service ticket to
the ticket-granting-service (TGS), along with the user principal’s TGT
and an authenticator. An authenticator is known data, such as
timestamp and user name, encrypted with the session key
Chapter 129
Overview
Authentication Process
Step 8. The TGS decrypts the authenticator to check the user’s identity and
Step 9. The secured application uses the session key received with the TGT to
verifies that the user’s TGT and credentials have not expired. The TGS
reads the secured application’s service principal key from the principal
database, then builds and sends a reply back to the secured client
application.
The reply contains two different packets:
•The packet intended for the service principal contains a service
ticket, a new session key, an authenticator and other information, all
encrypted in the service principal’s key.
•The packet intended for the client contains the same session key and
other information.
Both packets are encrypted in a session key received by the client
with the TGT
decrypt the reply. It stores the service ticket packet and the new session
key in the user’s credentials cache.Theclientdoesnotattempttodecrypt
the service ticket portion of the reply. It cannot as it does not have the
service principal’s key that was used to encrypt it.
Step 10. The secured application sends the service ticket packet to the secured
service, requesting a connection. The secured service decrypts the packet
using its key stored in a service key table file (default key table file name
is v5srvtab).
If the service can decrypt the packet, it uses the session key included in
the packet to decrypt the authenticator, which contains the user
principal’s name and a timestamp. The service checks that the
timestamp is within a five minute window centered around the service’s
clock. This limits an attackers ability to replay a ticket at a time outside
the clock skew.
From the principal name contained in the authenticator, the service
knows that the user has been authenticated and is who the user claims
to be. The service then performs authorization checks for the principal
name. If the checks are successful, a connection is established.
Step 11. The secured application may require the secured service to authenticate
itself, mutual authentication.
Chapter 130
Loading...
+ 255 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.