Finish editorial review of Kerberos chapter.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
02988bb656
commit
7b95d324c8
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44444
1 changed files with 115 additions and 147 deletions
|
|
@ -1366,23 +1366,24 @@ kadmin><userinput> exit</userinput></screen>
|
|||
</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></screen>
|
|||
<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></screen>
|
|||
<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
|
||||
|
|
@ -1446,16 +1442,64 @@ jdoe@example.org</screen>
|
|||
<filename>.k5users</filename>.</para>
|
||||
</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>
|
||||
|
|
@ -1467,12 +1511,6 @@ jdoe@example.org</screen>
|
|||
clocks using <acronym>NTP</acronym>.</para>
|
||||
</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
|
||||
|
|
@ -1485,7 +1523,7 @@ jdoe@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@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@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@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@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"</programlisting>
|
|||
<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
|
||||
|
|
|
|||
Loading…
Reference in a new issue