This is Info file install.info, produced by Makeinfo-1.55 from the input file install.texi. This file documents how to build and install the Kerberos V5 distribution. Copyright (C) 1995, 1996 Massachusetts Institute of Technology. All Rights Reserved. Export of this software from the United States of America may require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain any necessary licenses before exporting. WITHIN THAT CONSTRAINT, permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of M.I.T. not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. M.I.T. makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. Athena(r), Hesiod(r), Moira(r), and Discuss(r) are registered trademarks of the Massachusetts Institute of Technology (MIT). Project Athena, Athena Dashboard, Athena MUSE, Kerberos, X Window System, and Zephyr are trademarks of MIT. No commercial use of these trademarks may be made without prior written permission of MIT. All other product names are trademarks of their respective companies.  File: install.info, Node: kdc.conf, Next: Initializing the KDB, Prev: Installing the KDC, Up: Installing the KDC The optional `kdc.conf' profile ------------------------------- There is an optional configuration file `kdc.conf' that allows one to specify per-realm configuration data to be used by the Kerberos V5 Authentication Service and Key Distribution Center. This information includes database locations, key and per-realm defaults, port numbers, ticket life times, etc. The location of the configuration file is `/usr/local/lib/krb5kdc/kdc.conf'. See the man page or `[SOURCEDIR]/config-files/kdc.conf.M' for more details. This document assumes that you do not have the `kdc.conf' configuration file installed. Note also that `[logging]' subsection to `/etc/krb5.conf' can be used to specify where to syslog messages regarding server activity.  File: install.info, Node: Initializing the KDB, Next: Storing the Master Password, Prev: kdc.conf, Up: Installing the KDC Initializing the Kerberos Database ---------------------------------- Login to the Kerberos KDC, and use the `su' command to become root. If you installed the Kerberos administration tools with the `make install' command and the default pathnames, they should be in the `/usr/local/admin' directory. If you installed the tools in a different directory, hopefully you know what it is. From now on, we will refer to this directory as [ADMIN_DIR]. The default database will be located in the directory `/usr/local/lib/krb5kdc' unless changed in the configuration process. From now on, we will call this [DB_DIR]. The `kdb5_create' command creates and initializes the master database. It asks you to the database's master password. Do not forget this password. If you do, the database becomes useless. (Your realm name should be substituted for [REALMNAME] below.) Because the install process does not create [DB_DIR] you need to do so yourself. Use `kdb5_create' as follows: # mkdir [DB_DIR] # [ADMIN_DIR]/kdb5_create Initializing database '[DB_DIR]/principal' for realm '[REALMNAME]', master key name 'K/M@[REALMNAME]' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <-- [Enter the master password.] Re-enter KDC database master key to verify: <-- [Re-enter it.]  File: install.info, Node: Storing the Master Password, Next: Adding Users to the Database, Prev: Initializing the KDB, Up: Installing the KDC Storing the Master Password --------------------------- The `kdb5_stash' command "stashes" the master password in the file `[DB_DIR]/.k5.[REALM.NAME]' so that the Kerberos server can be started automatically during an unattended reboot of the master server. Other administrative programs use this hidden password so that they can access the master database without someone having to manually provide the master password. This command is an optional one; if you'd rather enter the master password each time you start the Kerberos server, don't use `kdb5_stash'. On the one hand, if you use `kdb5_stash', a copy of the master key will reside on a disk, which may not be acceptable; on the other hand, if you don't use `kdb5_stash', the server cannot be started unless someone is around to type the password manually. The command merely prompts for the master password: # [ADMIN_DIR]/kdb5_stash Enter KDC database master key: <-- [Enter the master password.] WARNING: If your Kerberos database master key is compromised and the database is obtained, the security of your entire authentication system is compromised. (If this happens you all of your user's passwords must be set to new values manually -- i.e., not using Kerberos.) The master key must be a carefully kept secret. If you keep backups, you must guard all the master keys you use, in case someone has stolen an old backup and wants to attack users' whose passwords haven't changed since the backup was stolen. This is why we provide the option not to store it on disk.  File: install.info, Node: Adding Users to the Database, Next: Starting the Kerberos Server, Prev: Storing the Master Password, Up: Installing the KDC Adding Users to the Database ---------------------------- The `kdb5_edit' program is used to add new users and services to the master database, and to modify existing database information. For example, to add yourself to the newly created database: (replace `[USERNAME]' with your username with. # [ADMIN_DIR]/kdb5_edit kdb5_edit: ank [USERNAME] Enter password: <-- [Enter your password.] Re-enter password for verification: <-- [Re-enter it.] kdb5_edit: quit The `ank' command is short for "add_new_key"; this command adds a new user to the database. To see what other commands which `kdb5_edit' supports, type `? RET' at the `kdb5_edit' prompt.  File: install.info, Node: Starting the Kerberos Server, Next: Setting up Slave Kerberos Servers, Prev: Adding Users to the Database, Up: Installing the KDC Starting the Kerberos Server ---------------------------- Assuming that you didn't use the `--prefix' argument to `configure', then [K_SERVER] refers to `/usr/local/sbin'. In order to start the Kerberos server, simply run it. It will fork and disassociate from the terminal unless the `-n' argument is used. # [K_SERVER]/krb5kdc If you have used the `kdb5_stash' command to store the master database password, the server will start automatically. If you did not use `kdb5_stash', use the following command: # [K_SERVER]/krb5kdc -m The server will prompt you to enter the master password before actually starting itself.  File: install.info, Node: Setting up Slave Kerberos Servers, Next: Inter-realm Kerberos Operation, Prev: Starting the Kerberos Server, Up: Installing the KDC Setting up Slave Kerberos Servers --------------------------------- Slave Kerberos servers allow clients to be able to get Kerberos tickets even when the Master server is not available. Users will not be able to change their passwords -- changes can only be made to database on the Master server; however, users will be able to authenticate to application servers, which is critically important in a distributed client-server environment. * Menu: * Kerberos Slave Database Propagation:: * Installing a Slave Server::  File: install.info, Node: Kerberos Slave Database Propagation, Next: Installing a Slave Server, Prev: Setting up Slave Kerberos Servers, Up: Setting up Slave Kerberos Servers Kerberos Slave Database Propagation ................................... In order to propagate the Kerberos database from the Master server to the slaves, the `kprop' and `kpropd' client/server programs are used. Periodically, the Master server will dump the Kerberos database out into an ASCII format, using the `kdb5_edit' program. The master server will then run `kprop' to propagate the dumped database file to each slave server. On the slave server, the `kpropd' program is invoked out of `/etc/inetd' server. After `kprop' and `kpropd' have mutually authenticated with one another, and `kpropd' is satisfied with the identity of the Master server, then the dumped ASCII database is transferred to the slave server in an encrypted fashion. After the database is transfered, `kpropd' will then run `kdb5_edit' with the appropriate arguments in order to undump the database into a usable form by the KDC on the slave server.  File: install.info, Node: Installing a Slave Server, Prev: Kerberos Slave Database Propagation, Up: Setting up Slave Kerberos Servers Installing a Slave Server ......................... To be written.  File: install.info, Node: Inter-realm Kerberos Operation, Next: The Administration Server, Prev: Setting up Slave Kerberos Servers, Up: Installing the KDC Inter-realm Kerberos Operation ------------------------------ To be written.  File: install.info, Node: The Administration Server, Next: Testing the Kerberos Server, Prev: Inter-realm Kerberos Operation, Up: Installing the KDC The Administration Server ------------------------- There is currently an administration server in the Kerberos source tree. It is, however, very rough, and it will likely be significantly changed or replaced before the 1.0 release. Hence, this manual does not document the current administration server. Changes to the database can be made by logging in to the KDC directly, and using the `kdb5_edit' program; see *Note Adding Users to the Database::.  File: install.info, Node: Testing the Kerberos Server, Prev: The Administration Server, Up: Installing the KDC Testing the Kerberos Server --------------------------- Use the `kinit' command to obtain Kerberos credentials. This command creates your credentials cache and stores your credentials in it. If you used the default `make install' command and directories to install the Kerberos user utilities, `kinit' will be in the `/usr/local/bin' directory. From now on, we'll refer to the Kerberos user commands directory as [K_USER]. Use `kinit' as follows: # [K_USER]/kinit [USERNAME] Password for [USERNAME]@[REALMNAME]: <-- enter your password Use the `klist' program to list the contents of your ticket file. # [K_USER]/klist Ticket cache: /tmp/krb5cc_15806 Default principal: [USERNAME]@[REALMNAME] Valid starting Expires Service principal 31-Jan-95 21:58:32 1-Feb-95 05:57:39 krbtgt/[REALMMNAME]@[REALMNAME]  File: install.info, Node: Migrating from V4 to V5 Kerberos, Next: A Sample Application, Prev: Installing the KDC, Up: Installation Migrating from V4 to V5 Kerberos ================================ To be written.  File: install.info, Node: A Sample Application, Next: Installing Kerberos Applications, Prev: Migrating from V4 to V5 Kerberos, Up: Installation A Sample Application ==================== This release of Kerberos comes with a sample application server and a corresponding client program. You will find this software `[K_SERVER]/sserver' and `[K_USER]/sclient', which is the server's executable, and the client program's executable, respectively. The programs are rudimentary. When they have been installed (the installation procedure is described in detail later), they work as follows: 1. The user starts `sclient' and provides as arguments to the command the name of the server machine and an optional port on which to contact the server. 2. `sclient' contacts the server machine and authenticates the user to `sserver'. 3. `sserver' authenticates itself to `sclient' (thus performing mutual authentication), and then returns a message to the client program. This message contains the name of the Kerberos principal that was used to authenticate to `sserver'. 4. `sclient' displays the server's message on the user's terminal screen. * Menu: * Installing the Sample Application:: * Testing the Sample Server::  File: install.info, Node: Installing the Sample Application, Next: Testing the Sample Server, Prev: A Sample Application, Up: A Sample Application Installing the Sample Application --------------------------------- In general, you use the following procedure to install a Kerberos-authenticated server-client system. 1. Add the appropriate entry to the Kerberos database using `kdb_edit' 2. Create a `/etc/v5srvtab' file for the server machine. 3. Install the service program and the `/etc/v5srvtab' file on the server machine. 4. Install the client program on the client machine. 5. Update the `/etc/services' file on the client and server machines. We will use the sample application as an example, although programs which do not take requests via the `inetd' program may have slightly different installation procedures. `Inetd' starts `sserver' each time a client process contacts the server machine. `sserver' processes the request, terminates, then is restarted when `inetd' receives another `sserver' request. When you install the program on the server, you must add a `sample' entry to the server machine's `/etc/inetd.conf' file. The following description assumes that you are installing `sserver' on the machine `jimi.mit.edu'. Here's the process, step by step: 1. Login as root or `su' to root on the Kerberos server machine. Use the `kdb5_edit' program to create an entry for `sample' in the Kerberos database: # [ADMIN_DIR]/kdb5_edit kdb5_edit: add_random_key sample/jimi.mit.edu kdb5_edit: quit (Note: `add_random_key' may be abbreviated as `ark'.) 2. Use `kdb5_edit' to create a `srvtab' file for `sserver''s host machine: # [ADMIN_DIR]/kdb5_edit kdb5_edit: extract_srvtab jimi.mit.edu sample 'sample/jimi.mit.edu@ATHENA.MIT.EDU' added to keytab 'WRFILE:jimi.mit.edu-new-srvtab' kdb5_edit: quit (Note: `extract_srvtab' may be abbreviated as `xst'.) Transfer the `jimi.mit.edu-new-srvtab' file to `jimi.mit.edu' and install it as `/etc/v5srvtab'. WARNING: Note that this file is equivalent to the service's password and should be treated with care. For example, it could be transferred by removable media, but should not be sent over an open network in the clear. This file should installed such that only the root user can read it. 3. Add the following line to the `/etc/services' file on `jimi.mit.edu', and on all machines that will run the `sample_client' program: sample 906/tcp # Kerberos sample app server 4. Add a line similar to the following line to the `/etc/inetd.conf' file on `sample_server''s machine: sample stream tcp nowait switched root [K_SERVER]/sserver sample_server where [K_SERVER] should be substituted with the path to the `sserver' program. (This `inetd.conf' information should be placed on one line.) You should examine existing lines in `/etc/inetd.conf' and use the same format used by other entries (e.g. for telnet). Most systems do not have a column for the `switched' keyword, and some do not have a column for the username (usually `root', as above). 5. Restart `inetd' by sending the current `inetd' process a hangup signal: # kill -HUP process_id_number 6. The `sserver' is now ready to take `sclient' requests.  File: install.info, Node: Testing the Sample Server, Prev: Installing the Sample Application, Up: A Sample Application Testing the Sample Server ------------------------- Assume that you have installed `sserver' on `jimi.mit.edu'. Login to your workstation and use the `kinit' command to obtain a Kerberos ticket-granting ticket: % [K_USER]/kinit [USERNAME] Password for [USERNAME]@[REALMNAME]: <--- Enter your password Now use the `sclient' program as follows: % [K_USER]/sclient jimi The command should display something like the following: sendauth succeeded, reply is: reply len 29, contents: You are [USERNAME]@[REALMNAME]  File: install.info, Node: Installing Kerberos Applications, Next: Common Kerberos Service Names, Prev: A Sample Application, Up: Installation Installing Kerberos Applications ================================ In addition to the sample application, Kerberos comes with several servers that can be installed on workstations to provide secure network services such as FTP, Telnet, and Rlogin. This section describes these services and how to install them. First, a general procedure is outlined for configuring a workstation to run Kerberos application servers. Then, details of the particular configuration options required by each server are presented. * Menu: * Levels of Security:: * Preparing a Workstation for Kerberos Application Servers:: * BSD Utilities:: * Telnet and FTP::  File: install.info, Node: Levels of Security, Next: Preparing a Workstation for Kerberos Application Servers, Prev: Installing Kerberos Applications, Up: Installing Kerberos Applications Levels of Security ------------------ Before installing Kerberized servers, it is a good idea to decide on a security policy for your workstation. While developing a comprehensive security policy is beyond the scope of these instructions, there are several interactions between Kerberos servers and non-Kerberos servers, as well as different modes in which Kerberos servers can run that should be considered. In general, there are three levels of connections: 1. Encrypted Kerberos connections are the most secure services provided by the Kerberos environment. Only encrypted services provide confidentiality--encryption is required to make sure a passive eavesdropper does not collect sensitive data, such as passwords, typed over connections. Besides providing confidentiality, encryption provides protection against active attacks. Without encryption or some other form of integrity, an attacker may be able to insert commands or change data in an authenticated session.l 2. The next level of security is Kerberos-authenticated services without encryption. Without encryption, there is no confidentiality, and some active attacks are possible. However, unencrypted services are faster and are available commercially outside the United States. In addition, the window of exposure to attack is generally limited to the lifetime of a session--it is difficult to start a new session if a Kerberos authentication exchange must take place at the beginning of every session. 3. Passworded services provide the next lower level of security. Unfortunately, it is all-to-easy for a passive attacker to use software such as a packet sniffer to find passwords traveling over a network. Additionally, once an attacker knows a password, they can start additional sessions at future times until the password is changed from a secure location. Despite the disadvantages of password-based network services, there are some common reasons for enabling them. First, most clients only support password-based services; not everyone has Kerberos or other cryptographically-secure network services. Second, in some environments, where the network is secure, passwords may be a reasonable solution. Also, particularly on public-access systems, it is common to enable password-based services for normal users, while using more-secure services such as Kerberos for root logins by administrators. 4. The least secure common category of services are trust or host-based services.These services use an IP address or client-supplied assertion to provide authentication. Examples of host-based services include `rlogin', `rsh', and the `on' or `rexd' service. It is generally sufficient to know that a user exists on a target system, and to know that a host-based or trust-based service is enabled in order to exploit the service. Whenever possible, these services should be disabled; there are few situations in which an a security policy is both compatible with Kerberos and host-based services. Next, decide whether Kerberos4 compatibility is necessary. Unencrypted Kerberos4 services suffer from all the problems of unencrypted Kerberos V5 services: lack of confidentiality and susceptibility to active attack. In addition, the lack of a replay cache in Kerberos4makes these active attacks much easier. Also, design bugs in the Kerberos4 BSD utilities such as `rlogin', `rsh' and `rcp' cause the availability of an unencrypted service to significantly decrease the security of a system, even if only the encrypted service is ever used. For example, a system that runs both encrypted and unencrypted Kerberos4 `rlogin' servers is less secure than a system only running the encrypted service, even if users only ever connect to the encrypted service. Therefore, if Kerberos4 interoperability is desired or required, try to avoid running unencrypted Kerberos4 services wherever possible. In particular, only enable encrypted `rlogin' if at all possible. Naturally, some environments will require additional Kerberos4 functionality, like `rsh'.The Kerberos V5 versions of these services, with Kerberos4 interoperability enabled are not any weaker than their Kerberos4 counterparts. So, if the existing Kerberos4 security policy allows these services, then enabling them under the Kerberos V5 security policy should not be a problem. Finally, the issue of compatibility with older Kerberos V5 clients must be considered. For the most part, this compatibility is automatic, and has few security implications. The major exception to this is the BSD utilities. Until Kerberos V5 Beta6, these utilities inherited a few design defects from the Kerberos V4 BSD utilities. In particular, the presence of an unencrypted service that was never used adversely effected the security of an encrypted service. The solution that was adopted preserves compatibility with Kerberos V5 Beta5 clients. Unfortunately, older clients are incompatible with this scheme. If interoperability with older clients is necessary, then the new scheme for checksums can be disabled on the server. This results in slightly less secure operation, but allows for compatibility with the older clients. Alternatively, sites wishing to enable all security features may wish to disable compatibility with Kerberos V5 Beta5 BSD utilities. *Note Checksums::, for full details. In conclusion, as you prepare to install Kerberos clients, you should have answers to the following questions: 1. What levels of services are appropriate for your security policy: encrypted services, authenticated but not encrypted services, password-based services, or host-based services? 2. Do you wish to enable Kerberos V4 compatibility? If so, do you need to enable unencrypted services? 3. Do you need compatibility with Kerberos V5 clients before Beta5 (released in May, 1995)? Do you wish to disable compatibility with Beta5 clients for slightly enhanced security?  File: install.info, Node: Preparing a Workstation for Kerberos Application Servers, Next: BSD Utilities, Prev: Levels of Security, Up: Installing Kerberos Applications Preparing a Workstation for Kerberos Application Servers -------------------------------------------------------- The following procedure is very similar to the installation procedure for the sample Kerberos server. *Note Installing the Sample Application::. However, instead of using the sample service, this configuration is designed to set up host-based services. The following description assumes that you are installing `sserver' on the machine `jimi.mit.edu'. Repeat these steps for each workstation that will be running host-based servers. Note that it is not necessary to run these procedures on client machines-machines used only to connect to secure network services, but that do not run any servers of their own. Here's the process, step by step: 1. Login as root or `su' to root on the Kerberos server machine. Use the `kdb5_edit' program to create a service entry for `host' in the Kerberos database: # [ADMIN_DIR]/kdb5_edit kdb5_edit: add_random_key host/jimi.mit.edu kdb5_edit: quit (Note: `add_random_key' may be abbreviated as `ark'.) 2. Use `kdb5_edit' to create a `srvtab' file for `sserver''s host machine: # [ADMIN_DIR]/kdb5_edit kdb5_edit: extract_srvtab jimi.mit.edu host 'host/jimi.mit.edu@ATHENA.MIT.EDU' added to keytab 'WRFILE:jimi.mit.edu-new-srvtab' kdb5_edit: quit (Note: `extract_srvtab' may be abbreviated as `xst'. Also, additional services can be listed after `host' on the `extract_srvtab' line; for example if the host jimi also runs the sample server, the `sample' service might have been listed after host.) Transfer the `jimi.mit.edu-new-srvtab' file to `jimi.mit.edu' and install it as `/etc/v5srvtab'. WARNING: Note that this file is equivalent to the service's password and should be treated with care. For example, it could be transferred by removable media, but should not be sent over an open network in the clear. This file should be installed such that only the root user can read it. 3. Make sure that the `/etc/services' file has been updated to include Kerberos services. In particular, look for `klogin', `eklogin', and `kshell'. 4. For each server you plan to run, add a line to `/etc/inetd.conf'. The following sections will give details on what this line should look like for each Kerberos application service. 5. Consider removing non-Kerberized services like `rlogin', `rsh', `rexd', and others, in accordance with the security policy you decided on in the last section. 6. Restart `inetd'. On most systems, this is done by sending the current `inetd' process a hangup signal: # kill -HUP process_id_number 7. Try using the Kerberos applications to connect to the host.  File: install.info, Node: BSD Utilities, Next: Telnet and FTP, Prev: Preparing a Workstation for Kerberos Application Servers, Up: Installing Kerberos Applications BSD Utilities ------------- This section describes installing servers for the BSD utilities: `kshd' and `klogind'.The `klogind' server implementsthe protocol used by the Kerberized `rlogin' client. The `kshd' server implements the protocol used by the `rsh' and `rcp' clients. These daemons take a common set of options to enable support for different versions of Kerberos. The `-5' option enables Kerberos V5 support, and the `-4' option enables Kerberos V4 support. At least one of these options must be supplied or the server will refuse all connections. Both options can be supplied if compatibility with both versions of Kerberos is desired. Both the `klogind' and `kshd' take an `-e' option to control encryption; because of the design of the servers, it works slightly differently. The Kerberos login service listens on two different ports, one for encrypted connections, and one for unencrypted connections. Because `klogind' is started by `inetd', it needs to know whether it is servicing an encrypted or unencrypted connection. Thus, the `-e' option tells `klogind' that it is listening to the encrypted port. Typically, systems that allow both encrypted and unencrypted logins have two lines in `inetd.conf', one for the `klogin' service and one for the `eklogin' service. The line for the `eklogin' service uses the `-e' option, while the line for the `klogin' service does not. Systems only supporting encrypted logins simply have the `eklogin' line. On the other hand, `kshd' listens to encrypted and unencrypted requests on the same port; information from the client identifies the connection's encryption status. So, `kshd' interprets the `-e' option to mean that encryption is required. If this option is specified, unencrypted connections are dropped. Thus, specifying `-e' to `kshd' is like only having a line for `eklogin'. * Menu: * Checksums:: Checksum facility for dealing with active attacks. * BSD Utility Configuration Example:: Sample `inetd.conf' entries for BSD utilities.  File: install.info, Node: Checksums, Next: BSD Utility Configuration Example, Prev: BSD Utilities, Up: BSD Utilities Checksums ......... Under previous versions of Kerberos, it was possible for an active attacker to change certain information in the initial authentication exchange without this change being detected. Starting with Kerberos V5, Beta6, this information is protected by a checksum passed in the Kerberos authenticator. Ideally, the server could detect the presence of this checksum and use it if it were present. This way, administrators could be sure to use new clients that produced the checksum, while users who were not as concerned about security could use a wider range of clients. This is how the checksum feature works by default. Unfortunately, clients previous to Kerberos V5, Beta5 used the checksum field to incorporate semi-random data into the Kerberos authentication exchange. It is impossible to distinguish these bogus checksums from checksums that have been produced by modern clients, but modified by an active attacker. Thus, the checksum feature is incompatible with previous releases of Kerberos V5. Three modes of operation are provided to meet the configuration needs of different sites: 1. The `-c' option to both `kshd' and `klogind' requires that checksums be present and valid. This only works with clients more recent than Kerberos V5, Beta6. An error will be given when an older client tries to connect. This option is incompatible with Kerberos V4, Kerberos V4 clients do not include a checksum. If this option is used in conjunction with the `-4' option for Kerberos V4 compatibility, a warning about the configuration error will be logged on each connection. 2. If no checksum-related option is specified, then checksums will be validated if they are present, but not required.This is compatible with Kerberos V4 and Kerberos V5 clients as early as Kerberos V5, Beta5. 3. If the `-i' option is provided, then checksums are ignored, even if present. This option is required to maintain compatibility with clients older than Kerberos V5 Beta5. Site should upgrade to newer clients so this option is not required.  File: install.info, Node: BSD Utility Configuration Example, Prev: Checksums, Up: BSD Utilities BSD Utility Configuration Example ................................. This section includes sample entries for `/etc/inetd.conf'. Sample configuration are presented for three systems. Note that while the examples stretch over multiple lines, an entry for a single service should be placed on only one line in `inetd.conf'. Also, not all systems have all of the columns shown in the example. *Note Installing the Sample Application::, for details on adding services to `inetd.conf'. The first system enables all security features. Only Kerberos V5 encrypted connections are enabled, and checksums are required. eklogin stream tcp nowait root [K_SERVER]/klogind klogind -5 -e -c kshell stream tcp nowait root [K_SERVER]/kshd kshd -5 -e -c The second system enables encrypted services for both Kerberos V5 and Kerberos V4. Checksums are not required, but since no V5 clients earlier than Beta5 are used, they are not ignored. eklogin stream tcp nowait root [K_SERVER]/klogind klogind -5 -4 -e kshell stream tcp nowait root [K_SERVER]/kshd kshd -5 -4 -e The final example has both encrypted and unencrypted services enabled for both Kerberos V5 and Kerberos V4. Checksums are disabled to preserve compatability with older V5 clients. eklogin stream tcp nowait root [K_SERVER]/klogind klogind -5 -4 -i -e klogin stream tcp nowait root [K_SERVER]/klogind klogind -5 -4 -i kshell stream tcp nowait root [K_SERVER]/kshd kshd -5 -4 -i  File: install.info, Node: Telnet and FTP, Prev: BSD Utilities, Up: Installing Kerberos Applications Telnet and FTP -------------- The following are example entries for `inetd.conf' for the `telnetd' and `ftpd' servers. *Note Installing the Sample Application::, for details on adding services to `inetd.conf'. Note that unlike other `inetd.conf' examples in this document, these line should replace existing lines for password-based services of the same name. The first example only allows encrypted or authenticated connections. telnet stream tcp nowait root [K_SERVER]/telnetd telnetd -a user ftp stream tcp nowait root [K_server]/ftpd ftpd -a The second example also allows password-based connections to be made. telnet stream tcp nowait root [K_SERVER]/telnetd telnetd ftp stream tcp nowait root [K_server]/ftpd ftpd  File: install.info, Node: Common Kerberos Service Names, Prev: Installing Kerberos Applications, Up: Installation Common Kerberos Service Names ============================= The following service names are used by Kerberos client/server applications. `host' Used by `telnet', `rlogin', `rsh', `rcp', `ftp'and other services which generally give login access to the host. `pop' Used by the Post Office Protocol. `sample' Used by the Kerberos sample applications. These service names are used as the first component of the server's principal name, with the second component being the server's fully qualified domain name, in lower case.  File: install.info, Node: Troubleshooting, Prev: Installation, Up: Top Troubleshooting *************** To be written.