This chapter provides information about configuring and managing a secure network using the MultiNet Kerberos Authentication Service.
You can use MultiNet Kerberos with the TELNET, RCP, RLOGIN, RSHELL, and POP3 services.
Note! This chapter applies to Kerberos V4 only. Kerberos V5 database and utilities support requires the installation of the Kerberos for OpenVMS product, based on MIT Kerberos V5 Release 1.2.6. Kerberos V5 application support is currently available for SSH and Telnet only.
MultiNet Authentication Service is an implementation of the Kerberos distributed authentication system developed at Project Athena at MIT, and is installed automatically with MultiNet.
Note! TELNET authentication support is based on a draft standard that is subject to change. However, if the standard changes, updates will be provided to MultiNet Authentication Services to conform to the latest version of the standard.
Kerberos provides network security by regulating user access to networking services. MultiNet Kerberos consists of administrative utilities and database creation and maintenance tools.
One host is designated the primary KDC (Kerberos Distribution Center) on which the authentication database resides. Other hosts, called secondary KDCs, can contain duplicates of the database for backup purposes. If no reply is obtained from the primary KDC, one of the secondary KDCs is consulted.
In Kerberos, the administrative name for a site is realm; for example, EXAMPLE.COM. The realm name is case-sensitive and is usually expressed in uppercase.
Kerberos provides a secure way to prove a user's identity across an unsecure network. A server makes authorization decisions based on the user's identity. Kerberos is an authentication system, not an authorization system, although authentication is a prerequisite for authorization.
Kerberos security works by granting users a permit to access a service. This permit is called a ticket. A ticket provides access to a single server from a single client host and has a default duration of eight hours. The duration can be set from 5 minutes to 21 hours. When this time period elapses, attempts to access servers fail; users must request new tickets.
When users log in, they run the MULTINET KERBEROS INIT utility, supplying their user names and Kerberos passwords. All necessary tickets are then issued. Before logging out, users run MULTINET KERBEROS DESTROY to release any remaining tickets. At any time during a login session, users can:
· Obtain ticket status with the MULTINET KERBEROS LIST utility
· Acquire new tickets with MULTINET KERBEROS INIT
· Change their passwords with MULTINET KERBEROS PASSWORD
· Release old tickets with MULTINET KERBEROS DESTROY
A ticket contains:
· The name of the server
· The name of the client (the user)
· The Internet address of the user's system
· A timestamp, the duration for which the ticket is valid (called the lifetime)
· A session key
Once a ticket is issued, it can be used repeatedly until it expires. A user's tickets are kept in the MULTINET_KRBTKT_username logical name table.
A detailed description of the Kerberos protocol is beyond the scope of this chapter. In short, obtaining a ticket involves sending encrypted messages between the client, the KDC, and the application server. This protocol allows a server to be sure the client has the correct password without revealing the password to intruders on the network.
Users are authenticated through the Kerberos database, which contains user names and encrypted passwords. Before creating the Kerberos database, the system manager assigns the Kerberos master password (often called the master key.)
The master key controls access to all aspects of the authentication system and must be kept confidential and secure. All other passwords in the Kerberos system are encrypted using the master key as the encryption key.
Kerberos requires a secure system on which the Kerberos authentication database resides. Process Software recommends that this system be physically secure, dedicated, not accessible over the network via NFS or the VMScluster disk-sharing protocol, and not performing paging over the network.
Kerberos files should be backed up regularly. Backup media contain copies of the KDC database and master key and should be secured.
Kerberos configuration consists of the following steps:
1. Creating the Kerberos configuration file (see the Step 1: Creating the Kerberos Configuration File section).
2. If necessary, creating a special file that matches domain names to realm names (see the Step 2: Creating the MULTINET:KERBEROS.REALMS File section).
3. Initializing the Kerberos database (see the Step 3: Initializing the Kerberos Database section).
4. Storing the database master key in a protected master key file (see the Step 4: Storing the Master Key section).
5. Adding users and services to the database (see the Step 5: Adding Users and Servers to the Principal Database section).
6. Creating a protected key file for each server that will run Kerberos-modified network server programs (see the Step 6: Creating Protected Key Files section).
7. Moving the protected key file to each server (see the Step 7: Moving the Protected Key Files section).
8. If necessary, changing the Kerberos port designation (see the Step 8: Changing the Kerberos Port Designation section).
9. Enabling the Kerberos server (see the Step 9: Enabling the Kerberos Server section).
When these steps are completed, you must test the configuration, Then, you can copy the database to other hosts (secondary KDCs), if necessary.
Create the MULTINET:KERBEROS.CONFIGURATION file with WORLD READ (W:R) permission to specify the local realm and identify your local ticket servers, and any other realms in which users need to be authenticated. The following is an example of a MULTINET:KERBEROS.CONFIGURATION file:
EXAMPLE.COM
EXAMPLE.COM holmes.example.com admin server
EXAMPLE.COM brown.example.com
EXAMPLE.ORG kerberos.example.org admin server
ATHENA.MIT.EDU kerberos.mit.edu admin server
ATHENA.MIT.EDU kerberos-1.mit.edu
In this example:
· The first line defines the local realm, EXAMPLE.COM. The local realm is often the local domain name, as in this example.
Note! In this example, the realm name is shown in uppercase, which is the usual convention and is recommended. Because realm names are case-sensitive, however, be sure to list your realm name in the proper case.
· Subsequent lines that begin with EXAMPLE.COM define local KDCs. Here, holmes.example.com is the name of the system acting as the KDC, the secure host that acts as the ticket server and contains the Kerberos principal database. The admin server argument designates a master KDC server, which services ticket requests, as well as requests for modifications to the Kerberos database (such as a user's password change requests).
Note! Use "admin server" for the primary KDC only. For secondary KDCs, omit this parameter. See the Configuring Secondary KDCs section.
· All other lines define ticket servers in foreign realms, in which users can remotely be authenticated. These servers are also used for cross-realm authentication (see the Using Cross-Realm Authentication section).
Propagate any changes you make to the Kerberos configuration file on the master KDC to all other servers so all servers contain the same information.
If the realm name in the MULTINET:KERBEROS.CONFIGURATION file is different from the domain name of this system, create a MULTINET:KERBEROS.REALMS file. This file consists of lines listing fully qualified domain names followed by their realm names. For example:
whorfin.example.com FOO.COM
In this case, whorfin.example.com is the domain name of this host, and FOO.COM is the realm name specified in the MULTINET:KERBEROS.CONFIGURATION file.
An entire domain can also be mapped to a specific realm with lines such as:
.mit.edu ATHENA.MIT.EDU
This causes domain names that end in ".mit.edu," such as "buckaroo.mit.edu," to be considered part of the ATHENA.MIT.EDU realm.
Initialize the Kerberos database on a KDC by entering:
$ MULTINET KERBEROS DATABASE INIT
Realm name [REALM]: EXAMPLE.COM
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Kerberos master key: password
Verifying, please re-enter Kerberos master key: password
$
Perform this step only on a host acting as a KDC. This command prompts you for the local realm name (EXAMPLE.COM in this example) and the database master password (master key). If you ever need to run MULTINET KERBEROS DATABASE INIT again on a system that has already been configured for Kerberos, a procedure is provided in the command page for this utility in the MultiNet for OpenVMS Administrator's Reference.
Note! The master password key is any string meeting the guidelines of an OpenVMS-style password, except it is case-sensitive and can be up to 64 characters in length. Protect the master key as carefully as you would the SYSTEM password.
After informational messages appear, the database is initialized and resides in the system-specific part of the MULTINET directory. The database files are named KERBEROS_PRINCIPAL.* and are only readable by SYSTEM. Do not change the protections on these files; doing so may compromise the security of your KDC.
Note! The database must reside on a local disk on the KDC host. A database on a network disk cannot be made sufficiently secure. For this reason, the KDC host should be dedicated solely for this use and should not have remote login servers enabled.
Run MULTINET KERBEROS DATABASE STASH to store the database master key in a file the KDC reads when it starts up, as shown here:
$ MULTINET KERBEROS DATABASE STASH
Kerberos master key: password
Verifying, please re-enter Kerberos master key: password
Current Kerberos master key version is 1.
Perform this command only on a host acting as a KDC. You are prompted for the database master key. When this utility completes, Kerberos stores the master key in the MULTINET:KERBEROS.MASTER_KEY file, and protects the file from world access. Do not change the protections on this file; doing so may compromise the security of your KDC.
Edit the principal database to add users and servers by entering the following command on the primary KDC for a given realm:
$ MULTINET KERBEROS DATABASE EDIT /NOPROMPT
KERBEROS DATABASE EDIT Prompts Error! Reference source not found.explains the prompts shown in the following examples.
The first example adds a record for the user "john." Each user is identified by a unique single-word principal name, which is usually the user name.
$ MULTINET KERBEROS DATABASE EDIT /NOPROMPT
Opening database . . .
Current Kerberos master key version is 1.
Previous of default values are in [brackets],
enter return to leave the same, or new value.
Principal name: john
Instance: RETURN
<Not found>, Create [y] ? RETURN
Principal: john, Instance: , kdc_key_ver: 1
New Password: password
Verifying, please re-enter New Password: password
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2010-12-31 ] ? RETURN
Max ticket lifetime (*5 minutes) [ 255 ] ? RETURN
Attributes [ 0 ] ? RETURN
Edit O.K.
Principal name: RETURN
$
The second example adds a record for the class of services "rcmd," which is associated with the host "whorfin."
$ MULTINET KERBEROS DATABASE EDIT /NOPROMPT
Opening database . . .
Current Kerberos master key version is 1.
Previous of default values are in [brackets],
enter return to leave the same, or new value.
Principal name: rcmd
Instance: whorfin
<Not found>, Create [y] ? RETURN
Principal: rcmd, Instance: whorfin, kdc_key_ver: 1
New Password: RANDOM
Random password [y] ? RETURN
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2003-01-01 ] ? RETURN
Max ticket lifetime (*5 minutes) [ 255 ] ? RETURN
Attributes [ 0 ] ? RETURN
Edit O.K.
Principal name: RETURN
$
When adding user information, enter the user name as the principal name; and leave the instance blank (press RETURN at the prompt). When adding a server entry:
· Enter the class name used by the service as the principal name; for example, the "rcmd" is the class name for the RCP, RLOGIN, RSHELL, and TELNET services.
· For the instance value, enter the short form name of the server host, such as "whorfin" in the previous example. Do not use the fully qualified domain name.
· Always specify RANDOM at the "New Password:" prompt. Because this password is never entered by a system manager, the password should be random to provide additional security.
When adding either a user entry or a service entry:
· Note that both the principal and instance names are case-sensitive.
· Specify the /NOPROMPT qualifier at the end of the command to cause the master key to be read from the master key file. If you do not enter this qualifier, you are prompted for the master key password.
· If a principal does not exist, you are prompted to create it. If you create a principal, you must supply a password.
· To exit, press RETURN at a principal name prompt.
· KERBEROS DATABASE EDIT takes the values to use as defaults from the "default" principal in the database. By specifying "default" as the principal name with KERBEROS DATABASE EDIT, any subsequent values you enter for the prompts that follow become the new default values the next time you use KERBEROS DATABASE EDIT. To make these values take effect, exit the utility, then re-invoke it. Any new principals created will use the new values provided by the default principal.
The below table explains the prompts displayed by the KERBEROS DATABASE EDIT command.
|
Prompt |
Meaning |
|
Enter Kerberos master key: |
The encryption key for the Kerberos database. This is the master password for Kerberos administration and must be safeguarded. This is a standard VMS-style password except the value is case-sensitive and can be up to 64 characters in length. |
|
Principal name: |
Case-sensitive value, generally a user name if you are adding a user to the database, or the name of a principal used by a Kerberized server if you are entering a class of service. Exit the utility by pressing RETURN at this prompt. |
|
Instance: |
A case-sensitive string value. When adding users to the database, enter an empty string (press RETURN.) When associating a service type with a host, the instance is the host name. If the principal name is for a new user or application, the next prompt is "Not found, Create [y] ?". Enter y to create the principal entry, or n to enter another principal name. |
|
Change password: |
Change the password for a user or service. This prompt only appears if you specified an existing principal or instance name. If you enter y, you are prompted for the new password. If you enter n, you are prompted for the Expiration date. |
|
New Password: |
Enter a new password. You can enter RANDOM for the password to indicate that the password is known only within the software. This feature adds additional security.
Note! You must enter RANDOM in all uppercase. The only use for the RANDOM password feature with user accounts is to prevent the user from accessing the Kerberos system. If you did not select the RANDOM feature, and chose to change the password, enter a new password. You are prompted to verify the password you enter. |
|
Expiration date: |
The date on which a user can no longer access the system, or the date an application is no longer valid. |
|
Max ticket lifetime: |
The maximum lifetime in minutes for a user's ticket. This can be any value from 5 to 1275 minutes (21 hours, 15 minutes). |
|
Attributes: |
The valid range of this value is 0 to 65535, inclusive. The meaning of this value is system- and application-dependent. MultiNet applications currently do not use this value. |
Generate a protected key file on the KDC for any host on which you want to run a "Kerberized" application server. Before performing this step, make sure you include the host name in the Kerberos database. (For the purposes of this discussion, it is assumed that the database has been edited to contain two principals, both of which have the name "rcmd", one with the instance "whorfin" and the second with the instance "holmes.")
Use the following command to generate a protected server key file:
$ MULTINET KERBEROS DATABASE SRVTAB /NOPROMPT server_name
Replace server_name with the name of the host on which you are creating the KERBEROS.SRVTAB file. To specify server_name as a case-sensitive name, use quotation marks. Otherwise, the MULTINET KERBEROS DATABASE SRVTAB command converts server_name to lowercase letters.
Note! server_name is not a fully qualified domain name, and does not contain dots in its name. Enter /NOPROMPT with the command before the server name and after the SRVTAB keyword to suppress the master key prompt.
The created file name has the format:
server_name-NEW-KERBEROS.SRVTAB
For example, to create the encrypted key file for the server host "whorfin," enter the following command. This command creates the WHORFIN-NEW-KERBEROS.SRVTAB file:
$ MULTINET KERBEROS DATABASE SRVTAB /NOPROMPT WHORFIN
After you create a protected key file for a server host, move it to the system-specific MultiNet directory on the specified server_name, renaming it to MULTINET:KERBEROS.SRVTAB. Protect the file from any world access.
Note! The contents of a server's KERBEROS.SRVTAB file are sensitive. A stolen KERBEROS.SRVTAB file could be used to impersonate a server so that a client doing mutual authentication could be fooled into believing that the fake server is the real one. If you do not have an encrypted data transfer facility, KERBEROS.SRVTAB files should be taken to the server hosts via tape or other nonbroadcast medium, and protected against any world access.
You can configure a KDC to listen on specific ports for ticket requests. If you set an explicit port number, the KDC listens only to that port. If you do not set a port number, both ports 88 and 750 are used. For example, to make the KDC only listen to port 88, configure Kerberos as follows:
$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.5(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SELECT KERBEROS
[The Selected SERVER entry is now KERBEROS]
SERVER-CONFIG>SET SOCKET-PORT 88
[KERBEROS socket port is 88]
SERVER-CONFIG>SHOW/FULL
Service "KERBEROS":
UDP socket (AF_INET,SOCK_DGRAM), Port 88
INIT() = Merge_Image
Program = "MULTINET:LOADABLE_KERBEROS"
SERVER-CONFIG>EXIT
On a primary KDC, enable the Kerberos server and the administration server. In a VMScluster, use the MultiNet Network Configuration Utility (NET-CONFIG) SET ENABLED-NODES command to control the node(s) on which the Kerberos and administration servers run. To enable these services, enter:
$ MULTINET CONFIGURE /SERVERS
MultiNet Server Configuration Utility 5.5(nnn)
[Reading in symbols from SERVER image MULTINET:SERVER.EXE]
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE KERBEROS
SERVER-CONFIG>ENABLE KADMIN
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] RETURN
SERVER-CONFIG>EXIT
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
$
On a secondary KDC, enable only the KERBEROS server, not the KADMIN server.
On an application server, enter the following commands to enable the Kerberized services. Enable Kerberized RLOGIN by enabling the KLOGIN service, and enable both the Kerberized RCP and RSHELL services by enabling KSHELL. The commands are:
$ MULTINET CONFIGURE /SERVERS
MultiNet Server Configuration Utility 5.5(nnn)
[Reading in symbols from SERVER image MULTINET:SERVER.EXE]
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE KLOGIN
SERVER-CONFIG>ENABLE KSHELL
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] RETURN
SERVER-CONFIG>EXIT
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
$
Kerberos is now configured.
If you have not done so already, create an entry in the database for yourself using the MULTINET KERBEROS DATABASE EDIT command. You can enter the following command to obtain your initial ticket:
$ MULTINET KERBEROS INIT
When you are prompted for a password, enter the password you specified when you created the database entry.
Alternately, you can authenticate yourself using a principal name other than your current login name by entering, for example:
$ MULTINET KERBEROS INIT /USERNAME=FRED
Note! If you use the /USERNAME qualifier with MULTINET KERBEROS INIT, you must also use the /USERNAME qualifier with MULTINET KERBEROS PASSWORD.
You should then be able to use RLOGIN to log into a system running Kerberos on which you have an account. For example, to log into WHORFIN, specify the command:
$ RLOGIN /AUTH WHORFIN /USER=FRED
The /AUTH qualifier is the shortened form of /AUTHENTICATION=KERBEROS. (Because no other options exist for the /AUTHENTICATION qualifier, specifying /AUTH without assigning a value has the same effect.) If you are using a principal name different from the OpenVMS user name under which you are logged in, use the /USERNAME qualifier with RLOGIN.
Kerberized RSHELL should also function properly, as in this example:
$ RSHELL /AUTH WHORFIN SHOW USERS
You can use an Ethernet protocol analyzer, such as TCPDUMP, to look at the differences between the protocols used by RLOGIN and RLOGIN /AUTH. Refer to the MultiNet for OpenVMS Administrator's Reference for more information on TCPDUMP.
Note! For MultiNet V4.1 and later, TCPDUMP can be invoked on the same host that you want to analyze.
Propagate the database by writing the contents of the Kerberos database to an ASCII text file. You can transport this text file to another KDC and reload it. This process is useful for creating secondary KDCs and for the interchange between different vendors' Kerberos implementations and different platforms. Refer to Configuring Secondary KDCs for more information about secondary KDCs. Passwords are encrypted and stored in the file as ASCII text.
After creating the Kerberos database, you may need to perform the following tasks during normal Kerberos usage:
· Deciding whether users can obtain tickets from alternate realms (see the Obtaining Tickets from Alternate Realms section).
· Editing or deleting user principal entries (see the Deleting and Editing Principal Entries section).
· Adding new servers to the database (see the Adding Entries for Application Servers section).
· Backing up the Kerberos database (see the Backing Up the Database section).
· Adding new users to the database (see the Adding Users and Servers to the Principal Database section).
You can configure Kerberos to allow a user to obtain a ticket-granting ticket from another realm, which grants access to the hosts in that realm. For example, if the local realm is PROCESS.COM, and the other realm is EXAMPLE.COM, a user on a host in PROCESS.COM enters:
$ MULTINET KERBEROS INIT/REALM=EXAMPLE.COM
The user could then use the obtained ticket to access hosts in the EXAMPLE.COM realm.
To permit this type of access, add information in the local KERBEROS.CONFIGURATION file to identify the KDC hosts in the foreign realm, such as:
EXAMPLE.COM holmes.example.com admin server
The complete PROCESS.COM local KERBEROS.CONFIGURATION file might be:
PROCESS.COM
PROCESS.COM buckaroo.process.com admin server
EXAMPLE.COM holmes.example.com admin server
To delete or edit principal names, you must dump the complete database into an ASCII text file, edit the file, and reload the database from the ASCII file. See the Configuring Secondary KDCs section for information about the KERBEROS DATABASE DUMP and KERBEROS DATABASE LOAD commands.
To prevent users or applications from being authenticated by Kerberos, use MULTINET KERBEROS DATABASE EDIT to change their passwords.
Use the MULTINET KERBEROS DATABASE EDIT utility to add entries for servers. When adding servers, the principal name is the service class; for example, the "rcmd" class of service is used by TELNET and all of the "R" services.
The instance name is the host name of the server on which the service runs. The password is RANDOM. See the Adding Users and Servers to the Principal Database section for an example of adding a service.
When you add a new application server to a Kerberos system, and after adding a principal to the database, run the MULTINET KERBEROS DATABASE SRVTAB utility to create a server password file for the remote system. You must move this file to the remote system so users can log into the server.
For details about using MULTINET KERBEROS DATABASE EDIT, see the Adding Users and Servers to the Principal Database section and the Creating Protected Key Files section.
Note! The transfer of the file created by MULTINET KERBEROS DATABASE SRVTAB must be kept secure and protected. For example, the file should not be transferred over the network in unencrypted form, but rather by tape or floppy disk.
The MULTINET KERBEROS DATABASE DUMP and MULTINET KERBEROS DATABASE LOAD utilities are provided for maintaining the database.
These utilities dump the contents of the Kerberos database into an ASCII text file and reload it. Once the Kerberos database is configured and all user and server information is added, the entire database can be written as an ASCII text file for transfer to another system and for backup. See the Configuring Secondary KDCs section for more information about the DUMP and LOAD commands.
Cross-realm authentication permits users to log into hosts in a foreign realm even though their initial tickets are from the local realm. This is accomplished by cooperation between the KDCs in the local and remote realms. Cross-realm authentication depends on realm administrators maintaining a password for mutual access to the respective realms. An entry is added to the Kerberos database at each realm.
To configure cross-realm authentication:
1. Create a Kerberos ticket-granting ticket by running MULTINET KERBEROS DATABASE EDIT to add principal entries to the database.
a. At the Principal name prompt, enter krbtgt and press RETURN.
b. At the Instance prompt, enter the name of the other realm. The password you enter should be previously agreed to by the administrators at each realm on which authentication occurs.
2. Add an entry for each foreign realm to the MULTINET:KERBEROS.CONFIGURATION file
3. Have each user who needs to access the other realm create a .KLOGIN file in the user's login directory on the remote host. An administrator in the remote realm may have to create this file if the local user cannot initially log into the remote host. A .KLOGIN file contains entries of the form:
username.@local_realm_name
This entry indicates to the RLOGIN, RSHELL, and TELNET servers that the user is authorized to log into an account on the remote host once the user's identity has been verified through cross-realm authentication.
Note! The existence of a .KLOGIN file prevents the user from logging into an account in the user's local realm if the user name on the account is the same as the user's principal name.
The cooperating KDCs must have a pair of krbtgt entries with the same password. The administrators of the two realms decide on this password and both must know it. If a pair of KDCs in different realms have exchanged passwords for their ticket-getting ticket principals, the KDCs can prove their identities to one another. When a client has proved its identity to the local KDC, the client can prove its identity to the remote KDC through the chain of trust the KDCs have established.
The following example shows the simplicity of cross-realm authentication.
· EXAMPLE.COM and PROCESS.COM want to allow cross-realm authentication between their realms. The administrators of the two realms decide to use "yayajohn" as the password.
· At EXAMPLE.COM, the krbtgt principal, instance PROCESS.COM, is added to the KDC database, using the "yayajohn" password. The KERBEROS.CONFIGURATION file contains this entry which identifies the KDC in the foreign realm PROCESS.COM:
PROCESS.COM buckaroo.process.com admin server
· At PROCESS.COM, the krbtgt principal, instance EXAMPLE.COM, is added to the KDC database, using the "yayajohn" password. The KERBEROS.CONFIGURATION file contains this entry which identifies the KDC in the foreign realm EXAMPLE.COM:
EXAMPLE.COM holmes.example.com admin server
· John at EXAMPLE.COM needs to log into the host Buckaroo at PROCESS.COM. An account with user name JOHN is created on Buckaroo, and the following .KLOGIN file is created in JOHN's home directory on Buckaroo: john.@EXAMPLE.COM
This entry indicates to the RLOGIN server on Buckaroo that John (who, through cross-realm authentication, has proven himself to be the user JOHN in the realm EXAMPLE.COM) is allowed to log into the account JOHN on Buckaroo. This .KLOGIN entry is required because JOHN in the realm EXAMPLE.COM is not necessarily the same person as JOHN in the realm PROCESS.COM, so permission must be explicitly granted for JOHN to log into the account in the PROCESS.COM realm.
A secondary KDC provides a backup if the primary KDC becomes unavailable for any reason. Clients can be configured so that if no reply is obtained from the primary KDC, a secondary KDC is consulted.
The secondary KDC is initialized like a primary KDC (using MULTINET KERBEROS DATABASE INITIALIZE), but instead of populating the database with the MULTINET KERBEROS DATABASE EDIT command, the database is copied from the primary KDC.
On the primary KDC, store the database by entering:
$ MULTINET KERBEROS DATABASE DUMP filename
Note! Even though passwords are not recognizable without the master key, unencrypted transmission of the dump file (using FTP, for example) can compromise network security. Knowledge of the names of principals is, in itself, sensitive information that would be valuable to an intruder.
If the main intent of using Kerberos is to protect the internal system from outside intruders, it may be reasonably safe to transfer the dump file on the local network without encryption.
For the highest level of security, you should store the dump file on a removable disk or tape and physically transport the media to the other host or use encrypted file transfer (not supported by MultiNet).
On the secondary KDC, reload the ASCII text file and create a new database by entering:
$ MULTINET KERBEROS DATABASE LOAD filename
On hosts running the UNIX Operating System, log in as root and enter:
# kdb_util load filename
Each host that can act as a client (for utilities like TELNET) should add have a line in its KERBEROS.CONFIGURATION file that lists the secondary as a KDC for the local realm, but does not include "admin server" because that should only be included for primary KDCs. An example of an entry in the configuration file is:
EXAMPLE.COM
EXAMPLE.COM john.example.com admin server
EXAMPLE.COM johnjohn.example.com
You can add the following DCL commands to the SYS$SYLOGIN.COM file to determine if a user has logged in using Kerberos:
$ VIAKERB = F$GETDVI("TT","TT_ACCPORNAM")
$ IF F$LOCATE("/Auth",VIAKERB) .NE. F$LENGTH(VIAKERB) THEN -
_$ WRITE SYS$OUTPUT "Logged-in with strong authentication."
These commands display the message in the last line if the user logs in using Kerberized TELNET or RLOGIN.
Note! All quoted text in these commands is case-sensitive.
The TT_ACCPORNAM variable only includes the /AUTH indicator if the INCLUDE-AUTHENTICATION-INDICATION parameter is set on the TELNET and RLOGIN services. To set it:
$ MULTINET CONFIGURE /SERVER
MultiNet Server Configuration Utility 5.5(nnn)
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>SEL TELNET
[The Selected SERVER entry is now TELNET]
SERVER-CONFIG>SET PARAMETER
Delete parameter "include-port-number" ? [NO] RETURN
Delete parameter "include-authentication-indication" ? [NO] RETURN
You can now add new parameters for TELNET. An empty line terminates.
Add Parameter: INCLUDE-AUTHENTICATION-INDICATION
Add Parameter: RETURN
[Service specific parameters for TELNET changed]
SERVER-CONFIG>EXIT
After adding the parameter, restart the MultiNet Server:
$ @MULTINET:START_SERVER