21. 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.
Server Concepts
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.
|
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.
Realm 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:
|
Adds an entry to the KDB |
|
|
Creates the KDB |
|
|
Creates a Kerberos service table |
|
|
Dumps the KDB into a text file |
|
|
Loads the KDB from a text file |
|
|
Modifies an entry in the KDB |
|
|
Removes an entry from the KDB |
|
|
Sets the Kerberos master password |
|
|
Shows a KDB entry |
|
|
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 principalpassword[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 applicationserver 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.
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-2114 23:59
Modification Date : 1-Feb-2014 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_kerberosqualifier 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.