## TCPware V5.7 Management Guide

- Introduction
- Configuration Checklist
- Server Concept
- Configuring the Server
  - Service Type
  - Realm Name
  - Primary Server Name
  - Maximum Database Age
- Management Commands
  - Kerberos Database
  - Stashing the Master Password
  - Adding Entries
  - Modifying Entries
  - Removing Entries
  - Showing Entries
  - Changing the Master Password
  - Dumping to Another File
  - Loading from Another File
  - Creating the Service Table File
- Administration Server
  - Accounts
  - Access Control Lists
  - Examples
- Kerberos for the Berkeley R Services
  - Require, Allow, or Disable Requests
  - Customizing the Kerberos Authentication Services
- Kerberos for TELNET

Chapter 23

Managing Kerberos

# Introduction

This chapter describes:

• Kerberos Server

• Kerberos management commands

• Kerberos administration server

• Kerberos .KLOGIN file

• Managing Kerberos for TELNET

# Configuration Checklist

To set up Kerberos authentication between systems, all machines have to be configured for Kerberos: the Kerberos server, application server, and client application machines. You must first decide which machine in the Kerberos realm (domain) will be the Kerberos Server, and which machines will support application clients and servers with Kerberos authentication. You also need to define the Kerberos realm, the location of the user's Kerberos ticket file, and who the Kerberos users and administrators are going to be.

On the Kerberos Server machine, you need to create a Kerberos database, add application service entries to it, and create a service table file for each application server (such as the RLOGIN server machine). For each service table, you need to transfer (preferably hand-carry) a copy of the file to each application server. You also need to add user entries and administrator accounts (with access control list entries) on the Kerberos Server.

The service table file you create from the Kerberos database is host-NEW-SRVTAB. (where host is the specific host name) for each application server with Kerberos authentication. This file should be located within the same directory where the NETCU CREATE SRVTAB command was issued. The file must be copied (preferably hand-carried) from this directory to the application server's remote host and renamed TCPWARE:SRVTAB.. Also, Kerberos must be configured for each application server.

Only the Kerberos configuration needs to occur on each client application machine. This defines the Kerberos logicals needed. Kerberos must also be started on each machine. No Kerberos database entry is needed for client applications, but entries are needed for server applications and user accounts. See Figure 23-1.

Figure 23-1

Kerberos Configuration Checklist

# Server Concept

Kerberos provides network security by regulating user access to network services. Kerberos solves the problem of how a server can be sure of a client's identity by having both the client and server trust a third party, in this case the Kerberos Server. The Kerberos Server verifies the client's identity.

If you set up your machine as a Primary Kerberos Server, TCPware creates two processes:

• Kerberos Server (TCPWARE_KERBV4)

The Kerberos Server handles authentication requests. This server uses UDP as its transport protocol.

• Kerberos Administration Server (TCPWARE_KADMV4)

The Kerberos Administration Server handles remote administration of the Kerberos database (KDB). This server uses TCP as its transport protocol.

# Configuring the Server

During configuration, CNFNET defines each of the logicals listed in Table 23-1.

Table 23-1 Kerberos Logicals

Logical | Description
TCPWARE_KERBV4_MAXAGE | Sets the maximum age of the Kerberos database
TCPWARE_KERBV4_PRIMARY | Sets the Primary Kerberos Server name
TCPWARE_KERBV4_REALM | Sets the realm name of the Kerberos Server
TCPWARE_KERBV4_RLOGIN | Determines if the RLOGIN Server mandates, accepts, or disallows any Kerberos request
TCPWARE_KERBV4_RSHELL | Determines if the RSH Server mandates, accepts, or disallows any Kerberos request
TCPWARE_KERBV4_SRVTYP | Sets the type of server (primary, or applications only)
TCPWARE_KERBV4_TELNET | Determines if the TELNET Server mandates, accepts, or disallows any Kerberos request
TCPWARE_KERBV4_TKFILE | Sets the location of the user's ticket file

## Service Type

The TCPWARE_KERBV4_SRVTYP logical determines the type of service on the local machine. You can have the Primary Kerberos Server and Kerberos applications running on it, or just Kerberos applications running on it.

You usually set the service type during CNFNET. If you need to define the logical manually, do so in one of the following two ways:

1 $ DEFINE/SYSTEM/EXEC TCPWARE_KERBV4_SRVTYP P

The P indicates that this machine is to have a Primary Kerberos Server and Kerberos applications running on it

2 $ DEFINE/SYSTEM/EXEC TCPWARE_KERBV4_SRVTYP A

The A indicates that this machine is to have only Kerberos applications running on it.

## R ealm Name

The TCPWARE_KERBV4_REALM logical determines the name of the Kerberos realm. You normally set the name of the local realm during CNFNET. The following example shows how to define the logical manually:

$ DEFINE/SYSTEM/EXEC TCPWARE_KERBV4_REALM DAISY.COM

DAISY.COM is the realm (domain) in which the Kerberos Server resides. To set up a realm:

• GateD or the TCPWARE:ROUTING.COM file (but not both) must be set up to handle other subnets within the Kerberos realm.

• Domain Name Services should be configured on both the client and server applications using Kerberos V4 authentication.

## Primary Server Name

The TCPWARE_KERBV4_PRIMARY logical determines the name of the primary Kerberos server. All Kerberos functions use the primary server.

You normally set the name of the primary server during CNFNET. The following example shows how to define the logical manually with the primary server defined as CHARON:

$ DEFINE/SYSTEM/EXEC TCPWARE_KERBV4_PRIMARY CHARON

## Maximum Database Age

The TCPWARE_KERBV4_MAXAGE logical determines the maximum age (in seconds) of the Kerberos database. The Kerberos Server uses this logical to determine if the database is too old. If the logical value is -1, the Server does not check the database age. Otherwise, the value must be between 3600 (seconds, or one hour) and 259200 (seconds, or three days).

If, when checking the age of the database, the Server detects that it is too old, it logs an error message in the Kerberos log file (TCPWARE:KERBEROS.LOG). The Server then continues, using an "old" database, if needed.

You normally set the maximum database age during CNFNET. The following example shows how to define the logical manually with the maximum age of the database set to one hour:

$ DEFINE/SYSTEM/EXEC TCPWARE_KERBV4_MAXAGE 3600

# Management Commands

The management interface with Kerberos comprises the following NETCU commands:

ADD KDB | Adds an entry to the KDB
CREATE KDB | Creates the KDB
CREATE SRVTAB | Creates a Kerberos service table
DUMP KDB | Dumps the KDB into a text file
LOAD KDB | Loads the KDB from a text file
MODIFY KDB | Modifies an entry in the KDB
REMOVE KDB | Removes an entry from the KDB
SET MASTER_PASSWORD | Sets the Kerberos master password
SHOW KDB | Shows a KDB entry
STASH MASTER_PASSWORD | Stashes the master password

See the NETCU Command Reference for details.

All commands require the OPER or SYSPRV privilege and entry of the Kerberos master password.

NETCU prompts for the master password the first time you use a Kerberos management command, unless you specify /NOPROMPT with the command. In the latter case, TCPware reads the master password from the file created by the STASH MASTER_PASSWORD command. You do not need the master password for the remainder of the NETCU session.

Uppercase entries convert to lowercase in these commands. If you have mixed case values or want to preserve case, enclose the value in double quotes. Use an asterisk (*) as a wildcard in parameters, but do not combine it with any other character.

## Kerberos Database

Use the CREATE KDB command to create the KDB and enter the master password. CREATE KDB is equivalent to the UNIX command kdb_init. The command format is:

CREATE KDB
Enter Kerberos master password:
Verifying, please re-enter:

You must enter the Kerberos master password at the prompt and re-enter it as verification at the next prompt. TCPware does not echo the password. However, keep the master password as secure as the password for the SYSTEM account.

The KDB, by default, is in the TCPWARE:PRINCIPAL.OK file. When you create the KDB, you can also specify an alternate location, using the /KDBFILE qualifier. CREATE KDB uses your local domain name by default as the Kerberos realm in the KDB. If you want to specify an alternate realm name, use the /REALM qualifier.

## Stashing the Master Password

Use the STASH MASTER_PASSWORD command to stash the master password in a protected file (TCPWARE:KSTASH.KEY). This allows you to add entries to the KDB without being prompted for the password. STASH MASTER_PASSWORD is equivalent to the UNIX command kstash. The command format is:

STASH MASTER_PASSWORD

If you do not stash the Kerberos password, after you create the Kerberos database (using CREATE KDB) and try to use it, you will not get a response; the Kerberos Server terminates automatically when this happens. The Kerberos Server cannot get the master key.

To fix this, perform the following commands:

$ NETCU STASH MASTER_PASSWORD
$ @TCPWARE:SHUTNET KERBEROS
$ @TCPWARE:STARTNET KERBEROS

## Adding Entries

Use the ADD KDB command to add an entry to the KDB. ADD KDB is equivalent to the UNIX command kdb_edit. The command format is:

ADD KDB principal password [instance]

• principal is the client user's login name or the name of the service provided.

• password is the user password.

Specifying "RANDOM" as the password generates a random password and is recommended for the application services entries; do not use this for Kerberos users or administrators. You can also specify "NULL" as the password; its entry will have no password.

• instance is usually omitted for a general Kerberos user, admin for an administrative user, or the name of the machine on which the Kerberos application resides.

You can specify the alternate location of the KDB (using the /KDBFILE qualifier). You can also indicate the maximum lifetime and expiration date of the KDB entry in minutes, using the
/MAX_LIFE and /EXP_DATE qualifiers, respectively.

## Modifying Entries

Use the MODIFY KDB command to modify an entry in the KDB. MODIFY KDB is equivalent to the UNIX command kdb_edit. The command format is:

MODIFY KDB principal [instance]

Entry of the master password and options are the same as for the ADD KDB command.

## Removing Entries

Use the REMOVE KDB command to remove an entry in the KDB. REMOVE KDB is equivalent to the UNIX command kdb_edit. The command format is:

REMOVE KDB principal [instance]

You can also use /KDBFILE and /NOPROMPT with this command.

## Showing Entries

Use the SHOW KDB command to show the status of KDB tickets. SHOW KDB is equivalent to the UNIX command klist. The command format is:

SHOW KDB principal [instance]

You can use /KDBFILE and /NOPROMPT with this command.

## Changing the Master Password

Use the SET MASTER_PASSWORD command to change the master password you entered at the CREATE KDB Enter Kerberos master password: prompt.

SET MASTER_PASSWORD is equivalent to the UNIX command kdb_util new_master_key. The command format is:

SET MASTER_PASSWORD

As with creating the KDB, you need to enter the current Kerberos master password. You can then enter the new master password. You can also specify an alternate KDB file other than PRINCIPAL.OK using the /KDBFILE qualifier.

## Dumping to Another File

Use the DUMP KDB command to dump the contents of the KDB into an ASCII text file. DUMP KDB is equivalent to the UNIX command kdb_util dump. The command format is:

DUMP KDB filespec

You can use /KDBFILE and /NOPROMPT with this command.

## Loading from Another File

Use the LOAD KDB command to load the KDB from the ASCII text file produced by DUMP KDB. LOAD KDB is equivalent to the UNIX command kdb_util load. The command format is:

LOAD KDB filespec

You can use /KDBFILE and /NOPROMPT with this command.

## Creating the Service Table File

Use the CREATE SRVTAB command to create an encrypted service table file for a remote host. The remote host's application servers use this to authenticate principals. CREATE SRVTAB is equivalent to the UNIX command ext_srvtab. The command format is:

CREATE SRVTAB instance

You can use the /KDBFILE, /NOPROMPT, and /REALM qualifiers with the SRVTAB command. The Kerberos Server uses the instance as part of the service table filename, as shown in the next example.

You must create a service table for the Kerberos application server after its service ticket entry is added to or modified in the Kerberos database. After adding a service ticket entry (using NETCU ADD KDB rcmd "RANDOM" BART) for remote host bart, create the service table for bart as shown in the next example:

CREATE SRVTAB BART

The Kerberos Server creates the BART-NEW-SRVTAB. file in the local directory. You must bring this file over to remote host bart. If bart runs TCPware, you must copy it to bart's TCPWARE:SRVTAB. file. If bart is UNIX, you must copy it into its /etc/srvtab file.

CAUTION! You must keep the service table file secure. Copy the file to a tape or disk for transfer to the remote host rather than transferring it over the network. This way, no one can intercept it.

# Administration Server

The Kerberos Administration Server (KADMIN) allows remote administration of the Kerberos primary server database. Kerberos administrators can add, modify and show Kerberos user records. KADMIN also allows Kerberos users to change their Kerberos passwords. You can create Kerberos administrator accounts and the Access Control Lists (ACLs) used to control access to the database.

KADMIN automatically starts up when you configure the machine to be a Primary Kerberos Server. However, Kerberos users can only get access to KADMIN to change their Kerberos passwords, unless further configuration takes place.

Figure 23-2 shows a request to a KADMIN Server. The following list describes each step:

1 The KADMIN client sends a request to the Kerberos Server for a Kerberos administrator ticket.

2 The Kerberos Server checks the Kerberos database to see if the client is legitimate.

3 If the client is legitimate, the Kerberos Server returns a Kerberos administrator ticket to the client. (If the client is not legitimate, the Kerberos Server returns an error message.)

4 The KADMIN client places the ticket in a temporary ticket file. This ticket contains an encryption key.

5 The KADMIN client encrypts its request for service, opens a TCP connection, and sends the encrypted request to the KADMIN server for processing. The KADMIN server recognizes four operations:

• A user changing his password

• Changing a Kerberos user's password

• A user displaying a Kerberos user record

• Adding a Kerberos user record

If the server detects an error at any point, it sends an error message to the KADMIN client.

6 The KADMIN server decrypts the request, and checks the ACL lists to see if the KADMIN client has the necessary privileges for the requested operation.

7 If the request is legitimate, the KADMIN server consults the Kerberos database, performs the requested operation, and saves the results.

8 The KADMIN server encrypts the status of the operation and any requested data, sends it back to the KADMIN client, and closes the TCP connection.

To perform this operation, use the following KADMIN commands at the NETCU level on the server system:

ADD KACL | Adds a Kerberos access control list (KACL) for the Kerberos database
REMOVE KACL | Removes a KACL entry
SHOW KACL | Shows the KACL entries

Use the following KADMIN commands at the NETCU level from a remote client system:

ADD KERBEROS USER | Adds a user entry to the KDB
MODIFY KERBEROS USER | Modifies a user record in the KDB
SET KERBEROS_PASSWORD | Changes a user's Kerberos password
SHOW KERBEROS USER | Lists a Kerberos user entry

See Chapter 2, NETCU Commands, in the NETCU Command Reference for details.

Figure 23-2 Kerberos Administration Server see graphic

## Accounts

The first step in the KADMIN process is to create Kerberos administrator accounts by adding KADMIN users to the Kerberos primary server database. These accounts take the form:

username.admin

For example, to create a Kerberos administrator account for persephone, use the following NETCU command on the Kerberos server, where persephone is the principal name, spring is the password, and admin is the instance that identifies the Kerberos administrator:

$ NETCU ADD KDB PERSEPHONE SPRING ADMIN
Enter Kerberos master password:
Verifying, please re-enter:

Use the following command to see the results of the operation:

$ NETCU SHOW KDB PERSEPHONE ADMIN

Name : persephone
Instance : admin
Expiration Date : 31-DEC-2104 23:59
Modification Date : 1-Feb-2004 09:21:09
Attributes : 0
Maximum Lifetime : 255
Key Version : 1

## Access Control Lists

The next step is to add the ACL entries specifying what persephone can do. There are three possible operations: ADD, SHOW, and MODIFY access. ADD allows the administrator to add new Kerberos users. SHOW allows the administrator to show Kerberos user records. MODIFY allows the administrator to change the Kerberos password of other Kerberos users. Perform all these operations on the machine on which the Kerberos database resides.

To add ACL entries for Kerberos administrator account persephone, do the following at the NETCU prompt:

ADD KACL ADD PERSEPHONE ADMIN HADES.COM
ADD KACL MODIFY PERSEPHONE ADMIN HADES.COM
ADD KACL SHOW PERSEPHONE ADMIN HADES.COM

On the first line, the ADD after ADD KACL is the ACL type, persephone is the username, admin is the instance, and hades.com is the optional realm name. The above commands allow add, modify, and show operations.

To see the added ACL records, do the following at the NETCU prompt:

SHOW KACL PERSEPHONE ADMIN HADES.COM
ACL Type Kerberos user
-------- -------------
ADD persephone.admin@hades.com
MODIFY persephone.admin@hades.com
SHOW persephone.admin@hades.com

## Examples

Once you set up the Kerberos administrator account, you can do the following remote administration operations through NETCU:

• Add a new Kerberos user, specifying the administrator password, as follows:

ADD KERBEROS USER ACHILLES RUNNING /ADMIN=PERSEPHONE
Administrator password for 'persephone':

• Show a Kerberos user record, specifying the administrator password, as follows:

SHOW KERBEROS USER ACHILLES /ADMIN=PERSEPHONE

Administrator password for 'persephone':

Name : achilles

Instance :

Expiration Date : 31-DEC-2099 23:59

Attributes : 0

Maximum Lifetime : 255

• Modify a Kerberos user record, specifying the administrator password, as follows:

MODIFY KERBEROS USER ACHILLES FAST /ADMIN=PERSEPHONE

Administrator password for 'persephone':

• Kerberos users can change their own passwords as follows:

SET KERBEROS_PASSWORD ACHILLES

Old password for 'achilles':

New password for 'achilles':

Verifying, please re-enter:

# Kerberos for the Berkeley R Services

Establishing Kerberos authentication for RLOGIN, RSH, and RCP occurs during TCPware's CNFNET procedure.

See the Installation & Configuration Guide, Chapter 4, Configuring the TCP/IP Services, the Configure the Kerberos Applications section.

In addition to setting up the Primary Kerberos Server, the configuration process implements an additional klogin service (if Kerberos authentication for the RLOGIN service is requested) and kshell service (if Kerberos authentication for the RSH or RCP service is requested). These services allow users to pass a Kerberos service ticket in place of a password to authenticate themselves.

The Berkeley R Commands use the .KLOGIN file to authenticate a remote Kerberos user. The klogin or kshell service checks the .KLOGIN file in the user's login directory.

Each line in the .KLOGIN file should contain a Kerberos principal in the following format:

name.instance@realm

For example:

fred@daisy.com
persephone.admin@rose.com

For details on Kerberos principals, see Kerberos Services in Chapter 19, Managing Security.

If the remote user is authenticated to one of the principals in the .KLOGIN file, the remote user has access to the service. The principal username@local-realm is granted access if there is no .KLOGIN file. Otherwise, standard authentication is used to log in to the server, if allowed.

## Require, Allow, or Disable Requests

You can change whether you want to require, allow, or disable the RLOGIN or RSH server from handling Kerberos authentication requests. Do this by rerunning CNFNET KERBEROS and restarting the Kerberos Services. You can select one of the following:

REQUIRED | Handle only Kerberos requests
ALLOWED | Handle both Kerberos and non-Kerberos requests
DISABLE | Reject all Kerberos requests

The RLOGIN and RSH servers use the value of the TCPWARE_KERBV4_RLOGIN and TCPWARE_KERBV4_RSHELL logicals, respectively, to determine how requests are handled.

## Customizing the Kerberos Authentication Services

CNFNET implements the proper NETCU ADD SERVICE /ROUTINE=create_rservice_kerberos internal action routine during Kerberos configuration. This is used only in servicing RLOGIN or RSH (and RCP) Kerberos requests.

You can customize Kerberos authentication for RLOGIN and RSH after Kerberos configuration by using the NETCU ADD SERVICE command. If you customize the ADD SERVICE command, use the /ROUTINE=create_rservice_kerberos qualifier and value along with the klogin port and stream protocol (for RLOGIN service), or the kshell port and stream protocol (for the RSH service).

You can additionally show, modify, or remove Kerberos authentication for RLOGIN or RSH by using, respectively, the NETCU SHOW SERVICES, MODIFY SERVICE, or REMOVE SERVICE command. See the NETCU Command Reference.

# Kerberos for TELNET

Kerberos configuration for TELNET occurs during TCPware's CNFNET procedure.

See the Installation & Configuration Guide, Chapter 4, Configuring the TCP/IP Services, the Configure the Kerberos Applications section.

Note! You must also install and configure TCPware TELNET-OpenVMS for Kerberos authentication of TELNET requests to work. All the rules and commands for using TELNET-OpenVMS apply to TELNET with Kerberos authorization.

See Chapter 18, TELNET-OpenVMS Management, for details about TELNET logicals and options. See the User's Guide, Chapter 11, TELNET: Connecting to Remote Terminals, for details on using TELNET and a description of the available TELNET commands.

You can change whether you want to require, allow, or disable the TELNET server from handling Kerberos authentication requests. Do this by rerunning CNFNET KERBEROS and restarting the Kerberos Services. You can select one of the following:

REQUIRED | Handle only Kerberos requests
ALLOWED | Handle both Kerberos and non-Kerberos requests
DISABLE | Reject all Kerberos requests

The TELNET server uses the value of the TCPWARE_KERBV4_TELNET logical to determine how requests are handled.