svn commit: r44444 - head/en_US.ISO8859-1/books/handbook/security
Dru Lavigne
dru at FreeBSD.org
Fri Apr 4 15:21:37 UTC 2014
Author: dru
Date: Fri Apr 4 15:21:36 2014
New Revision: 44444
URL: http://svnweb.freebsd.org/changeset/doc/44444
Log:
Finish editorial review of Kerberos chapter.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/security/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri Apr 4 15:16:08 2014 (r44443)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri Apr 4 15:21:36 2014 (r44444)
@@ -1366,23 +1366,24 @@ kadmin><userinput> exit</userinput></
</sect2>
<sect2>
- <title><application>Kerberos</application> Enabling a Client
- with Heimdal</title>
+ <title>Configuring a Client to use
+ <application>Kerberos</application></title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>configure clients</secondary>
</indexterm>
- <para>Setting up a client computer is easy as only
- <filename>/etc/krb5.conf</filename> is needed. Securely copy
- this file over to the client computer from the
+ <para>To configure a client to use
+ <application>Kerberos</application>, securely copy
+ <filename>/etc/krb5.conf</filename>
+ to the client computer from the
<acronym>KDC</acronym>.</para>
- <para>Test the client by attempting to use &man.kinit.1;,
- &man.klist.1;, and &man.kdestroy.1; from the client to obtain,
- show, and then delete a ticket for the principal created
- above. <application>Kerberos</application> applications
+ <para>Test the client by using <command>kinit</command>,
+ <command>klist</command>, and <command>kdestroy</command> from the client to obtain,
+ show, and then delete an existing ticket for the principal.
+ <application>Kerberos</application> applications
should also be able to connect to
<application>Kerberos</application> enabled servers. If that
does not work but obtaining a ticket does, the problem is
@@ -1390,26 +1391,21 @@ kadmin><userinput> exit</userinput></
<acronym>KDC</acronym>.</para>
<para>When testing a Kerberized application, try using a packet
- sniffer such as &man.tcpdump.1; to confirm that the password
+ sniffer such as <command>tcpdump</command> to confirm that the password
is not sent in the clear.</para>
- <para>Various non-core <application>Kerberos</application>
- client applications are available. The <quote>minimal</quote>
- installation in &os; installs &man.telnetd.8; as the only
- <application>Kerberos</application> enabled service.</para>
-
- <para>The Heimdal port installs
+ <para>Various <application>Kerberos</application>
+ client applications are available.
+ &os; installs <command>telnetd</command> as the only
+ <application>Kerberos</application> enabled service. The
+ Heimdal package or port installs
<application>Kerberos</application> enabled versions of
- &man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;, and
+ <command>ftpd</command>, <command>rshd</command>,
+ <command>rcp</command>, <command>rlogind</command>, and
a few other less common programs. The <acronym>MIT</acronym>
- port also contains a full suite of
+ port contains a full suite of
<application>Kerberos</application> client
applications.</para>
- </sect2>
-
- <sect2>
- <title>User Configuration Files: <filename>.k5login</filename>
- and <filename>.k5users</filename></title>
<indexterm>
<primary><filename>.k5login</filename></primary>
@@ -1433,7 +1429,7 @@ kadmin><userinput> exit</userinput></
<para>The <filename>.k5login</filename> and
<filename>.k5users</filename> files, placed in a user's home
directory, can be used to solve this problem. For example, if
- <filename>.k5login</filename> with the following contents is
+ the following <filename>.k5login</filename> is
placed in the home directory of <systemitem
class="username">webdevelopers</systemitem>, both principals
listed will have access to that account without requiring a
@@ -1447,15 +1443,63 @@ jdoe at example.org</screen>
</sect2>
<sect2>
+ <title><acronym>MIT</acronym> Differences</title>
+
+ <para>The major difference between the <acronym>MIT</acronym> and
+ Heimdal implementations is that <command>kadmin</command> has a different, but
+ equivalent, set of commands and uses a different protocol.
+ If the <acronym>KDC</acronym> is <acronym>MIT</acronym>, the
+ Heimdal version of <command>kadmin</command> cannot be used to administer
+ the <acronym>KDC</acronym> remotely, and vice versa.</para>
+
+ <para>Client applications may also use slightly different
+ command line options to accomplish the same tasks.
+ Following the instructions at
+ <application>Kerberos</application> <link
+ xlink:href="http://web.mit.edu/Kerberos/www/">http://web.mit.edu/Kerberos/www/</link>
+ is recommended. Be careful of path issues: the
+ <acronym>MIT</acronym> port installs into
+ <filename>/usr/local/</filename> by default, and the
+ &os; system applications run instead of the
+ <acronym>MIT</acronym> versions if <envar>PATH</envar> lists
+ the system directories first.</para>
+
+ <note>
+ <para>With the &os; <acronym>MIT</acronym>
+ <package>security/krb5</package> port, be sure to read
+ <filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
+ installed by the port to understand why logins via
+ <command>telnetd</command> and <command>klogind</command> behave
+ somewhat oddly. Correcting the <quote>incorrect permissions
+ on cache file</quote> behavior requires that the
+ <command>login.krb5</command> binary be used for
+ authentication so that it can properly change ownership for
+ the forwarded credentials.</para>
+ </note>
+
+ <para>The following edits should also be made to
+ <filename>rc.conf</filename>:</para>
+
+ <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
+kadmind5_server="/usr/local/sbin/kadmind"
+kerberos5_server_flags=""
+kerberos5_server_enable="YES"
+kadmind5_server_enable="YES"</programlisting>
+ </sect2>
+
+ <sect2>
<title><application>Kerberos</application> Tips, Tricks, and
Troubleshooting</title>
+ <para>When configuring and troubleshooting
+ <application>Kerberos</application>, keep the following points
+ in mind:</para>
+
<itemizedlist>
<listitem>
- <para>When using either the Heimdal or
+ <para>When using either Heimdal or
<acronym>MIT</acronym>
- <application>Kerberos</application><indexterm><primary>Kerberos5</primary><secondary>troubleshooting</secondary></indexterm>
- ports, ensure that the <envar>PATH</envar> lists the
+ <application>Kerberos</application>, ensure that the <envar>PATH</envar> lists the
<application>Kerberos</application> versions of the
client applications before the system versions.</para>
</listitem>
@@ -1468,12 +1512,6 @@ jdoe at example.org</screen>
</listitem>
<listitem>
- <para><acronym>MIT</acronym> and Heimdal interoperate
- except for &man.kadmin.8;, which is not
- standardized.</para>
- </listitem>
-
- <listitem>
<para>If the hostname is changed, the <systemitem
class="username">host/</systemitem> principal must be
changed and the keytab updated. This also applies to
@@ -1485,7 +1523,7 @@ jdoe at example.org</screen>
<listitem>
<para>All hosts in the realm must be both forward and
reverse resolvable in <acronym>DNS</acronym> or, at a
- minimum, in <filename>/etc/hosts</filename>. CNAMEs
+ minimum, exist in <filename>/etc/hosts</filename>. CNAMEs
will work, but the A and PTR records must be correct and
in place. The error message for unresolvable hosts is not
intuitive: <errorname>Kerberos5 refuses authentication
@@ -1496,31 +1534,30 @@ jdoe at example.org</screen>
<listitem>
<para>Some operating systems that act as clients to the
<acronym>KDC</acronym> do not set the permissions for
- &man.ksu.1; to be setuid <systemitem
+ <command>ksu</command> to be setuid <systemitem
class="username">root</systemitem>. This means that
- &man.ksu.1; does not work. This is not a
+ <command>ksu</command> does not work. This is a permissions problem, not a
<acronym>KDC</acronym> error.</para>
</listitem>
<listitem>
<para>With <acronym>MIT</acronym>
- <application>Kerberos</application>, in order to allow a
+ <application>Kerberos</application>, to allow a
principal to have a ticket life longer than the default
ten hours, use <command>modify_principal</command> at the
- &man.kadmin.8; prompt to change the maxlife of both the
+ &man.kadmin.8; prompt to change the <literal>maxlife</literal> of both the
principal in question and the <systemitem
- class="username">krbtgt</systemitem> principal. Then
- the principal can use <command>kinit -l</command> to
+ class="username">krbtgt</systemitem> principal. The
+ principal can then use <command>kinit -l</command> to
request a ticket with a longer lifetime.</para>
</listitem>
<listitem>
- <note>
<para>When running a packet sniffer on the
<acronym>KDC</acronym> to aid in troubleshooting while
- running &man.kinit.1; from a workstation, the Ticket
+ running <command>kinit</command> from a workstation, the Ticket
Granting Ticket (<acronym>TGT</acronym>) is sent
- immediately upon running &man.kinit.1;, even before the
+ immediately, even before the
password is typed. This is because the
<application>Kerberos</application> server freely
transmits a <acronym>TGT</acronym> to any unauthorized
@@ -1528,7 +1565,7 @@ jdoe at example.org</screen>
encrypted in a key derived from the user's password.
When a user types their password, it is not sent to the
<acronym>KDC</acronym>, it is instead used to decrypt
- the <acronym>TGT</acronym> that &man.kinit.1; already
+ the <acronym>TGT</acronym> that <command>kinit</command> already
obtained. If the decryption process results in a valid
ticket with a valid time stamp, the user has valid
<application>Kerberos</application> credentials.
@@ -1541,17 +1578,16 @@ jdoe at example.org</screen>
This second layer of encryption allows the
<application>Kerberos</application> server to verify
the authenticity of each <acronym>TGT</acronym>.</para>
- </note>
</listitem>
<listitem>
- <para>To use long ticket lifetimes, such as a week, when
+ <para>To use long ticket lifetimes when
using <application>OpenSSH</application> to connect to the
machine where the ticket is stored, make sure that
<application>Kerberos</application>
<option>TicketCleanup</option> is set to
<literal>no</literal> in
- <filename>sshd_config</filename> or else tickets will be
+ <filename>/etc/ssh/sshd_config</filename>. Otherwise, tickets will be
deleted at log out.</para>
</listitem>
@@ -1578,106 +1614,45 @@ jdoe at example.org</screen>
</sect2>
<sect2>
- <title>Differences with the <acronym>MIT</acronym>
- Port</title>
-
- <para>The major difference between <acronym>MIT</acronym> and
- Heimdal relates to &man.kadmin.8; which has a different, but
- equivalent, set of commands and uses a different protocol.
- If the <acronym>KDC</acronym> is <acronym>MIT</acronym>, the
- Heimdal version of &man.kadmin.8; cannot be used to administer
- the <acronym>KDC</acronym> remotely, and vice versa.</para>
-
- <para>The client applications may also use slightly different
- command line options to accomplish the same tasks.
- Following the instructions on the <acronym>MIT</acronym>
- <application>Kerberos</application> <link
- xlink:href="http://web.mit.edu/Kerberos/www/">web
- site</link> is recommended. Be careful of path issues: the
- <acronym>MIT</acronym> port installs into
- <filename>/usr/local/</filename> by default, and the
- <quote>normal</quote> system applications run instead of
- <acronym>MIT</acronym> versions if <envar>PATH</envar> lists
- the system directories first.</para>
-
- <note>
- <para>With the &os; <acronym>MIT</acronym>
- <package>security/krb5</package> port, be sure to read
- <filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
- installed by the port to understand why logins via
- &man.telnetd.8; and <command>klogind</command> behave
- somewhat oddly. Correcting the <quote>incorrect permissions
- on cache file</quote> behavior requires that the
- <command>login.krb5</command> binary be used for
- authentication so that it can properly change ownership for
- the forwarded credentials.</para>
- </note>
-
- <para>The following edits should also be made to
- <filename>rc.conf</filename>:</para>
-
- <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
-kadmind5_server="/usr/local/sbin/kadmind"
-kerberos5_server_flags=""
-kerberos5_server_enable="YES"
-kadmind5_server_enable="YES"</programlisting>
-
- <para>This is done because the applications for
- <acronym>MIT</acronym> Kerberos installs binaries in the
- <filename>/usr/local</filename> hierarchy.</para>
- </sect2>
-
- <sect2>
- <title>Mitigating Limitations Found in
- <application>Kerberos</application></title>
+ <title>Mitigating <application>Kerberos</application> Limitations</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>limitations and shortcomings</secondary>
</indexterm>
- <sect3>
- <title><application>Kerberos</application> is an All or
- Nothing Approach</title>
-
- <para>Every service enabled on the network must be modified
- to work with <application>Kerberos</application>, or be
- otherwise secured against network attacks, or else the
- user's credentials could be stolen and re-used. An example
- of this would be <application>Kerberos</application>
- enabling all remote shells but not converting the
- <acronym>POP3</acronym> mail server which sends passwords in
+ <para>Since <application>Kerberos</application> is an all or
+ nothing approach, every service enabled on the network must either be modified
+ to work with <application>Kerberos</application> or be
+ otherwise secured against network attacks. This is to prevent
+ user credentials from being stolen and re-used. An example is when
+ <application>Kerberos</application> is
+ enabled on all remote shells but the non-Kerberized
+ <acronym>POP3</acronym> mail server sends passwords in
plain text.</para>
- </sect3>
-
- <sect3>
- <title><application>Kerberos</application> is Intended for
- Single-User Workstations</title>
- <para>In a multi-user environment,
- <application>Kerberos</application> is less secure. This is
- because it stores the tickets in <filename>/tmp</filename>,
+ <para><application>Kerberos</application> is intended for
+ single-user workstations. In a multi-user environment,
+ <application>Kerberos</application> is less secure as it
+ stores the tickets in <filename>/tmp</filename>,
which is readable by all users. If a user is sharing a
- computer with other users, it is possible that the user's
+ computer, it is possible that the user's
tickets can be stolen or copied by another user.</para>
- <para>This can be overcome with the <literal>-c</literal>
- command-line option or, preferably, the
+ <para>This can be overcome with <command>kinit -c</command>
+ or, preferably, the
<envar>KRB5CCNAME</envar> environment variable. Storing
the ticket in the user's home directory and using file
permissions are commonly used to mitigate this
problem.</para>
- </sect3>
- <sect3>
- <title>The KDC is a Single Point of Failure</title>
-
- <para>By design, the <acronym>KDC</acronym> must be as secure
+ <para>The <acronym>KDC</acronym> is a single point of failure. By design, the
+ <acronym>KDC</acronym> must be as secure
as its master password database. The <acronym>KDC</acronym>
should have absolutely no other services running on it and
should be physically secure. The danger is high because
<application>Kerberos</application> stores all passwords
- encrypted with the same <quote>master</quote> key which is
+ encrypted with the same master key which is
stored as a file on the <acronym>KDC</acronym>.</para>
<para>A compromised master key is not quite as bad as one
@@ -1687,56 +1662,49 @@ kadmind5_server_enable="YES"</programlis
<acronym>KDC</acronym> is secure, an attacker cannot do much
with the master key.</para>
- <para>Additionally, if the <acronym>KDC</acronym> is
+ <para>If the <acronym>KDC</acronym> is
unavailable, network services are unusable as authentication
cannot be performed. This can be alleviated with a single
master <acronym>KDC</acronym> and one or more slaves, and
with careful implementation of secondary or fall-back
authentication using <acronym>PAM</acronym>.</para>
- </sect3>
-
- <sect3>
- <title><application>Kerberos</application>
- Shortcomings</title>
<para><application>Kerberos</application> allows users, hosts
and services to authenticate between themselves. It does
not have a mechanism to authenticate the
- <acronym>KDC</acronym> to the users, hosts or services.
- This means that a trojanned &man.kinit.1; could record all
+ <acronym>KDC</acronym> to the users, hosts, or services.
+ This means that a trojanned <command>kinit</command> could record all
user names and passwords. File system integrity checking
tools like <package>security/tripwire</package> can
alleviate this.</para>
- </sect3>
</sect2>
<sect2>
- <title>Access Issues with Kerberos and &man.ssh.1;</title>
+ <title>Access Issues with Kerberos and <command>ssh</command></title>
<indexterm><primary>&man.ssh.1;</primary></indexterm>
- <para>There are a few issues with both Kerberos and &man.ssh.1;
- that need to be addressed if they are used. Kerberos is an
+ <para>Kerberos is an
excellent authentication protocol, but there are bugs in the
- kerberized versions of &man.telnet.1; and &man.rlogin.1; that
+ kerberized versions of <command>telnet</command> and <command>rlogin</command> that
make them unsuitable for dealing with binary streams. By
default, Kerberos does not encrypt a session unless
- <option>-x</option> is used whereas &man.ssh.1; encrypts
+ <option>-x</option> is used, whereas <command>ssh</command> encrypts
everything.</para>
- <para>While &man.ssh.1; works well, it forwards encryption keys
+ <para>While <command>ssh</command> works well, it forwards encryption keys
by default. This introduces a security risk to a user who
- uses &man.ssh.1; to access an insecure machine from a secure
+ uses <command>ssh</command> to access an insecure machine from a secure
workstation. The keys themselves are not exposed, but
- &man.ssh.1; installs a forwarding port for the duration of the
+ <command>ssh</command> installs a forwarding port for the duration of the
login. If an attacker has broken
<systemitem class="username">root</systemitem> on
the insecure machine, he can utilize that port to gain access
to any other machine that those keys unlock.</para>
- <para>It is recommended that &man.ssh.1; is used in combination
- with Kerberos whenever possible for staff logins and
- &man.ssh.1; can be compiled with Kerberos support. This
+ <para>It is recommended that <command>ssh</command> is used in combination
+ with Kerberos whenever possible for staff logins as it
+ can be compiled with Kerberos support. This
reduces reliance on potentially exposed <acronym>SSH</acronym>
keys while protecting passwords via Kerberos. Keys should
only be used for automated tasks from secure machines as this
More information about the svn-doc-all
mailing list