doc/rst_source/krb_admins/appl_servers.rst

   1 Application servers
   2 ===================
   3
   4 If you need to install the Kerberos V5 programs on an application
   5 server, please refer to the Kerberos V5 Installation Guide.  Once you
   6 have installed the software, you need to add that host to the Kerberos
   7 database (see :ref:`add_mod_del_princs`), and generate a keytab for
   8 that host, that contains the host's key.  You also need to make sure
   9 the host's clock is within your maximum clock skew of the KDCs.
  10
  11
  12 Keytabs
  13 -------
  14
  15 A keytab is a host's copy of its own keylist, which is analogous to a
  16 user's password.  An application server that needs to authenticate
  17 itself to the KDC has to have a keytab that contains its own principal
  18 and key.  Just as it is important for users to protect their
  19 passwords, it is equally important for hosts to protect their keytabs.
  20 You should always store keytab files on local disk, and make them
  21 readable only by root, and you should never send a keytab file over a
  22 network in the clear.  Ideally, you should run the :ref:`kadmin(1)`
  23 command to extract a keytab on the host on which the keytab is to
  24 reside.
  25
  26
  27 .. _add_princ_kt:
  28
  29 Adding principals to keytabs
  30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  31
  32 To generate a keytab, or to add a principal to an existing keytab, use
  33 the **ktadd** command from kadmin.
  34
  35 .. include:: admin_commands/kadmin_local.rst
  36    :start-after:  _ktadd:
  37    :end-before: _ktadd_end:
  38
  39 .. note:: Alternatively, the keytab can be generated using
  40           :ref:`ktutil(1)` **add_entry -password** and **write_kt**
  41           commands.
  42
  43
  44 Examples
  45 ########
  46
  47 Here is a sample session, using configuration files that enable only
  48 *des-cbc-crc* encryption::
  49
  50     kadmin: ktadd host/daffodil.mit.edu@ATHENA.MIT.EDU
  51     kadmin: Entry for principal host/daffodil.mit.edu@ATHENA.MIT.EDU with kvno 2, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5.keytab.
  52     kadmin:
  53
  54     kadmin: ktadd -k /usr/local/var/krb5kdc/kadmind.keytab kadmin/admin kadmin/changepw
  55     kadmin: Entry for principal kadmin/admin@ATHENA.MIT.EDU with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/usr/local/var/krb5kdc/kadmind.keytab.
  56     kadmin:
  57
  58
  59 Removing principals from keytabs
  60 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  61
  62 To remove a principal from an existing keytab, use the kadmin
  63 **ktremove** command.
  64
  65 .. include:: admin_commands/kadmin_local.rst
  66    :start-after:  _ktremove:
  67    :end-before: _ktremove_end:
  68
  69
  70 Clock Skew
  71 ----------
  72
  73 In order to prevent intruders from resetting their system clocks in
  74 order to continue to use expired tickets, Kerberos V5 is set up to
  75 reject ticket requests from any host whose clock is not within the
  76 specified maximum clock skew of the KDC (as specified in the KDC's
  77 :ref:`krb5.conf(5)` file).  Similarly, hosts are configured to reject
  78 responses from any KDC whose clock is not within the specified maximum
  79 clock skew of the host (as specified in the :ref:`krb5.conf(5)` file).
  80 The default value for maximum clock skew is 300 seconds, or five
  81 minutes.  MIT suggests that you add a line to client machines'
  82 ``/etc/rc`` files to synchronize the machine's clock to your KDC at
  83 boot time. On UNIX hosts, assuming you had a kdc called kerberos in
  84 your realm, this would be::
  85
  86     gettime -s kerberos
  87
  88 If the host is not likely to be rebooted frequently, you may also want
  89 to set up a cron job that adjusts the time on a regular basis.
  90
  91
  92 Getting DNS information correct
  93 -------------------------------
  94
  95 Several aspects of Kerberos rely on name service.  In order for
  96 Kerberos to provide its high level of security, it is less forgiving
  97 of name service problems than some other parts of your network.  It is
  98 important that your Domain Name System (DNS) entries and your hosts
  99 have the correct information.
 100
 101 Each host's canonical name must be the fully-qualified host name
 102 (including the domain), and each host's IP address must
 103 reverse-resolve to the canonical name.
 104
 105 Other than the localhost entry, make all entries in each machine's
 106 /etc/hosts file in the following form::
 107
 108     IP address      fully-qualified hostname        aliases
 109
 110 Here is a sample ``/etc/hosts`` file::
 111
 112     # this is a comment
 113     127.0.0.1      localhost localhost@mit.edu
 114     10.0.0.6       daffodil.mit.edu trillium wake-robin
 115
 116 Additionally, on Solaris machines, you need to be sure the ``hosts``
 117 entry in the file ``/etc/nsswitch.conf`` includes the source ``dns``
 118 as well as ``file``.
 119
 120 Finally, each host's keytab file must include a host/key pair for the
 121 host's canonical name.  You can list the keys in a keytab file by
 122 issuing the command ``klist -k``. For example::
 123
 124     viola# klist -k
 125     Keytab name: /etc/krb5.keytab
 126     KVNO Principal
 127     ---- ------------------------------------------------------------
 128        1 host/daffodil.mit.edu@ATHENA.MIT.EDU
 129
 130 If you telnet to the host with a fresh credentials cache (ticket
 131 file), and then :ref:`klist(1)`, the host's service principal should
 132 be::
 133
 134     host/fully-qualified-hostname@REALM_NAME.
 135
 136
 137 .. _conf_firewall:
 138
 139 Configuring your firewall to work with Kerberos V5
 140 --------------------------------------------------
 141
 142 If you need off-site users to be able to get Kerberos tickets in your
 143 realm, they must be able to get to your KDC.  This requires either
 144 that you have a slave KDC outside your firewall, or you configure your
 145 firewall to allow UDP requests into at least one of your KDCs, on
 146 whichever port the KDC is running.  (The default is port 88; other
 147 ports may be specified in the KDC's :ref:`kdc.conf(5)` file.)
 148 Similarly, if you need off-site users to be able to change their
 149 passwords in your realm, they must be able to get to your Kerberos
 150 admin server.  The default port for the admin server is 749.
 151
 152 If your on-site users inside your firewall will need to get to KDCs in
 153 other realms, you will also need to configure your firewall to allow
 154 outgoing TCP and UDP requests to port 88.  Additionally, if they will
 155 need to get to any Kerberos V4 KDCs, you may also need to allow TCP
 156 and UDP requests to port 750.  If your on-site users inside your
 157 firewall will need to get to Kerberos admin servers in other realms,
 158 you will also need to allow outgoing TCP and UDP requests to port 749.
 159
 160 If any of your KDCs are outside your firewall, you will need to allow
 161 kprop requests to get through to the remote KDC.  :ref:`kprop(8)` uses
 162 the ``krb5_prop`` service on port 754 (tcp).
 163
 164 If you need your off-site users to have access to machines inside your
 165 firewall, you need to allow TCP connections from their off-site hosts
 166 on the appropriate ports for the programs they will be using. The
 167 following lines from ``/etc/services`` show the default port numbers
 168 for the Kerberos V5 programs::
 169
 170     ftp           21/tcp           # Kerberos ftp and telnet use the
 171     telnet        23/tcp           # default ports
 172     kerberos      88/udp    kdc    # Kerberos V5 KDC
 173     kerberos      88/tcp    kdc    # Kerberos V5 KDC
 174     klogin        543/tcp          # Kerberos authenticated rlogin
 175     kshell        544/tcp   cmd    # and remote shell
 176     kerberos-adm  749/tcp          # Kerberos 5 admin/changepw
 177     kerberos-adm  749/udp          # Kerberos 5 admin/changepw
 178     krb5_prop     754/tcp          # Kerberos slave propagation
 179     eklogin       2105/tcp         # Kerberos auth. & encrypted rlogin
 180
 181 By default, Kerberos V5 telnet and ftp use the same ports as the
 182 standard telnet and ftp programs, so if you already allow telnet and
 183 ftp connections through your firewall, the Kerberos V5 versions will
 184 get through as well.  If you do not already allow telnet and ftp
 185 connections through your firewall, but need your users to be able to
 186 use Kerberos V5 telnet and ftp, you can either allow ftp and telnet
 187 connections on the standard ports, or switch these programs to
 188 non-default port numbers and allow ftp and telnet connections on those
 189 ports to get through.  Kerberos V5 rlogin uses the ``klogin`` service,
 190 which by default uses port 543.  Encrypted Kerberos V5 rlogin uses the
 191 ``eklogin`` service, which by default uses port 2105.  Kerberos V5 rsh
 192 uses the kshell service, which by default uses port 544.  However, the
 193 server must be able to make a TCP connection from the kshell port to
 194 an arbitrary port on the client, so if your users are to be able to
 195 use rsh from outside your firewall, the server they connect to must be
 196 able to send outgoing packets to arbitrary port numbers.  Similarly,
 197 if your users need to run rsh from inside your firewall to hosts
 198 outside your firewall, the outside server needs to be able to connect
 199 to an arbitrary port on the machine inside your firewall.  Because
 200 Kerberos V5 rcp uses rsh, the same issues apply.  If you need to use
 201 rsh (or rcp) through your firewall and are concerned with the security
 202 implications of allowing connections to arbitrary ports, MIT suggests
 203 that you have rules that specifically name these applications and, if
 204 possible, list the allowed hosts.
 205
 206 The book UNIX System Security, by David Curry, is a good starting
 207 point for learning to configure firewalls.
 208
 209
 210 Feedback
 211 --------
 212
 213 Please, provide your feedback at
 214 krb5-bugs@mit.edu?subject=Documentation___appl_servers