diff options
Diffstat (limited to 'doc/html/_sources/admin/appl_servers.txt')
| -rw-r--r-- | doc/html/_sources/admin/appl_servers.txt | 147 |
1 files changed, 0 insertions, 147 deletions
diff --git a/doc/html/_sources/admin/appl_servers.txt b/doc/html/_sources/admin/appl_servers.txt deleted file mode 100644 index f6474cdbdebc..000000000000 --- a/doc/html/_sources/admin/appl_servers.txt +++ /dev/null @@ -1,147 +0,0 @@ -Application servers -=================== - -If you need to install the Kerberos V5 programs on an application -server, please refer to the Kerberos V5 Installation Guide. Once you -have installed the software, you need to add that host to the Kerberos -database (see :ref:`add_mod_del_princs`), and generate a keytab for -that host, that contains the host's key. You also need to make sure -the host's clock is within your maximum clock skew of the KDCs. - - -Keytabs -------- - -A keytab is a host's copy of its own keylist, which is analogous to a -user's password. An application server that needs to authenticate -itself to the KDC has to have a keytab that contains its own principal -and key. Just as it is important for users to protect their -passwords, it is equally important for hosts to protect their keytabs. -You should always store keytab files on local disk, and make them -readable only by root, and you should never send a keytab file over a -network in the clear. Ideally, you should run the :ref:`kadmin(1)` -command to extract a keytab on the host on which the keytab is to -reside. - - -.. _add_princ_kt: - -Adding principals to keytabs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To generate a keytab, or to add a principal to an existing keytab, use -the **ktadd** command from kadmin. - -.. include:: admin_commands/kadmin_local.rst - :start-after: _ktadd: - :end-before: _ktadd_end: - - -Examples -######## - -Here is a sample session, using configuration files that enable only -AES encryption:: - - kadmin: ktadd host/daffodil.mit.edu@ATHENA.MIT.EDU - Entry for principal host/daffodil.mit.edu with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab - Entry for principal host/daffodil.mit.edu with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab - kadmin: - - -Removing principals from keytabs -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To remove a principal from an existing keytab, use the kadmin -**ktremove** command. - -.. include:: admin_commands/kadmin_local.rst - :start-after: _ktremove: - :end-before: _ktremove_end: - - -Clock Skew ----------- - -A Kerberos application server host must keep its clock synchronized or -it will reject authentication requests from clients. Modern operating -systems typically provide a facility to maintain the correct time; -make sure it is enabled. This is especially important on virtual -machines, where clocks tend to drift more rapidly than normal machine -clocks. - -The default allowable clock skew is controlled by the **clockskew** -variable in :ref:`libdefaults`. - - -Getting DNS information correct -------------------------------- - -Several aspects of Kerberos rely on name service. When a hostname is -used to name a service, the Kerberos library canonicalizes the -hostname using forward and reverse name resolution. (The reverse name -resolution step can be turned off using the **rdns** variable in -:ref:`libdefaults`.) The result of this canonicalization must match -the principal entry in the host's keytab, or authentication will fail. - -Each host's canonical name must be the fully-qualified host name -(including the domain), and each host's IP address must -reverse-resolve to the canonical name. - -Configuration of hostnames varies by operating system. On the -application server itself, canonicalization will typically use the -``/etc/hosts`` file rather than the DNS. Ensure that the line for the -server's hostname is in the following form:: - - IP address fully-qualified hostname aliases - -Here is a sample ``/etc/hosts`` file:: - - # this is a comment - 127.0.0.1 localhost localhost.mit.edu - 10.0.0.6 daffodil.mit.edu daffodil trillium wake-robin - -The output of ``klist -k`` for this example host should look like:: - - viola# klist -k - Keytab name: /etc/krb5.keytab - KVNO Principal - ---- ------------------------------------------------------------ - 2 host/daffodil.mit.edu@ATHENA.MIT.EDU - -If you were to ssh to this host with a fresh credentials cache (ticket -file), and then :ref:`klist(1)`, the output should list a service -principal of ``host/daffodil.mit.edu@ATHENA.MIT.EDU``. - - -.. _conf_firewall: - -Configuring your firewall to work with Kerberos V5 --------------------------------------------------- - -If you need off-site users to be able to get Kerberos tickets in your -realm, they must be able to get to your KDC. This requires either -that you have a slave KDC outside your firewall, or that you configure -your firewall to allow UDP requests into at least one of your KDCs, on -whichever port the KDC is running. (The default is port 88; other -ports may be specified in the KDC's :ref:`kdc.conf(5)` file.) -Similarly, if you need off-site users to be able to change their -passwords in your realm, they must be able to get to your Kerberos -admin server on the kpasswd port (which defaults to 464). If you need -off-site users to be able to administer your Kerberos realm, they must -be able to get to your Kerberos admin server on the administrative -port (which defaults to 749). - -If your on-site users inside your firewall will need to get to KDCs in -other realms, you will also need to configure your firewall to allow -outgoing TCP and UDP requests to port 88, and to port 464 to allow -password changes. If your on-site users inside your firewall will -need to get to Kerberos admin servers in other realms, you will also -need to allow outgoing TCP and UDP requests to port 749. - -If any of your KDCs are outside your firewall, you will need to allow -kprop requests to get through to the remote KDC. :ref:`kprop(8)` uses -the ``krb5_prop`` service on port 754 (tcp). - -The book *UNIX System Security*, by David Curry, is a good starting -point for learning to configure firewalls. |
