os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Editorial review of first 1/2 of Kerberos chapter.

Browse source 
Sponsored by:	iXsystems
This commit is contained in:
Dru Lavigne 2014-04-04 14:30:07 +00:00
parent 676959834e
commit 02988bb656
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44442
1 changed files with 103 additions and 133 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

236
en_US.ISO8859-1/books/handbook/security/chapter.xml
View file

@ -303,7 +303,7 @@
time, all network logins should avoid the use of passwords in time, all network logins should avoid the use of passwords in
exchange for this two factor authentication method. For exchange for this two factor authentication method. For
more information see the <xref linkend="openssh"/> section of more information see the <xref linkend="openssh"/> section of
the handbook. Kerberose users may need to make additional the handbook. Kerberos users may need to make additional
changes to implement <application>OpenSSH</application> in changes to implement <application>OpenSSH</application> in
their network.</para> their network.</para>
@ -1050,7 +1050,7 @@ sendmail : PARANOID : deny</programlisting>
<sect1 xml:id="kerberos5"> <sect1 xml:id="kerberos5">
<info> <info>
<title><application>Kerberos5</application></title> <title><application>Kerberos</application></title>
<authorgroup> <authorgroup>
<author><personname><firstname>Tillman</firstname><surname>Hodgson</surname></personname><contrib>Contributed <author><personname><firstname>Tillman</firstname><surname>Hodgson</surname></personname><contrib>Contributed
@ -1062,11 +1062,15 @@ sendmail : PARANOID : deny</programlisting>
</authorgroup> </authorgroup>
</info> </info>
<para><application>Kerberos</application> is a network add-on <para><application>Kerberos</application> is a network
system/protocol that allows users to authenticate themselves authentication protocol which was originally created by the
through the services of a secure server. Massachusetts Institute of Technology
(<acronym>MIT</acronym>) as a solution to network security
problems. The <application>Kerberos</application> protocol uses
strong cryptography so that both a client and server can prove
their identity over an insecure network.
<application>Kerberos</application> can be described as an <application>Kerberos</application> can be described as an
identity-verifying proxy system. It can also be described as a identity-verifying proxy system and as a
trusted third-party authentication system. After a user trusted third-party authentication system. After a user
authenticates with <application>Kerberos</application>, their authenticates with <application>Kerberos</application>, their
communications can be encrypted to assure privacy and data communications can be encrypted to assure privacy and data
@ -1074,24 +1078,42 @@ sendmail : PARANOID : deny</programlisting>
<para>The only function of <application>Kerberos</application> is <para>The only function of <application>Kerberos</application> is
to provide the secure authentication of users on the network. to provide the secure authentication of users on the network.
It does not provide authorization functions (what users are It does not provide authorization
allowed to do) or auditing functions (what those users did). It or auditing functions. It
is recommended that <application>Kerberos</application> be used is recommended that <application>Kerberos</application> be used
with other security methods which provide authorization and with other security methods which provide authorization and
audit services.</para> audit services.</para>
<para>The current version of the protocol is version 5, described
in <acronym>RFC</acronym>&nbsp;1510. Several free
implementations of this protocol are
available, covering a wide range of operating systems.
<acronym>MIT</acronym>
continues to develop their <application>Kerberos</application>
package. It is commonly used in the <acronym>US</acronym> as
a cryptography product, and has historically been affected by
<acronym>US</acronym> export regulations. In &os;,
<acronym>MIT</acronym> <application>Kerberos</application> is
available as the <package>security/krb5</package> package or
port. Heimdal <application>Kerberos</application>
was explicitly developed outside
of the <acronym>US</acronym> to avoid export regulations. The
Heimdal <application>Kerberos</application> distribution is
available as the <package>security/heimdal</package> package
or port, and a minimal installation is included in the base
&os; install.</para>
<para>This section provides a guide on how to set up <para>This section provides a guide on how to set up
<application>Kerberos</application> as distributed for &os;. <application>Kerberos</application> using the Heimdal
Refer to the relevant manual pages for more complete distribution included in &os;.</para>
descriptions.</para>
<para>For purposes of demonstrating a <para>For purposes of demonstrating a
<application>Kerberos</application> installation, the various <application>Kerberos</application> installation, the
name spaces will be as follows:</para> name spaces will be as follows:</para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>The <acronym>DNS</acronym> domain (<quote>zone</quote>) <para>The <acronym>DNS</acronym> domain (zone)
will be <systemitem will be <systemitem
class="fqdomainname">example.org</systemitem>.</para> class="fqdomainname">example.org</systemitem>.</para>
</listitem> </listitem>
@ -1104,57 +1126,12 @@ sendmail : PARANOID : deny</programlisting>
<note> <note>
<para>Use real domain names when setting up <para>Use real domain names when setting up
<application>Kerberos</application> even if it will run <application>Kerberos</application>, even if it will run
internally. This avoids <acronym>DNS</acronym> problems internally. This avoids <acronym>DNS</acronym> problems
and assures inter-operation with other and assures inter-operation with other
<application>Kerberos</application> realms.</para> <application>Kerberos</application> realms.</para>
</note> </note>
<sect2>
<title>History</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>history</secondary>
</indexterm>
<para><application>Kerberos</application> was created by
<acronym>MIT</acronym> as a solution to network security
problems. The <application>Kerberos</application> protocol
uses strong cryptography so that a client can prove its
identity to a server (and vice versa) across an insecure
network connection.</para>
<para><application>Kerberos</application> is both the name of a
network authentication protocol and an adjective to describe
programs that implement it, such as
<application>Kerberos</application> telnet. The current
version of the protocol is version 5, described in
<acronym>RFC</acronym>&nbsp;1510.</para>
<para>Several free implementations of this protocol are
available, covering a wide range of operating systems. The
Massachusetts Institute of Technology
(<acronym>MIT</acronym>), where
<application>Kerberos</application> was originally developed,
continues to develop their <application>Kerberos</application>
package. It is commonly used in the <acronym>US</acronym> as
a cryptography product, and has historically been affected by
<acronym>US</acronym> export regulations. The
<acronym>MIT</acronym> <application>Kerberos</application> is
available as the <package>security/krb5</package> package or
port. Heimdal <application>Kerberos</application> is another
version 5 implementation, and was explicitly developed outside
of the <acronym>US</acronym> to avoid export regulations. The
Heimdal <application>Kerberos</application> distribution is
available as a the <package>security/heimdal</package> package
or port, and a minimal installation is included in the base
&os; install.</para>
<para>These instructions assume the use of the Heimdal
distribution included in &os;.</para>
</sect2>
<sect2> <sect2>
<title>Setting up a Heimdal <acronym>KDC</acronym></title> <title>Setting up a Heimdal <acronym>KDC</acronym></title>
@ -1168,19 +1145,17 @@ sendmail : PARANOID : deny</programlisting>
<application>Kerberos</application> provides. It is the <application>Kerberos</application> provides. It is the
computer that issues <application>Kerberos</application> computer that issues <application>Kerberos</application>
tickets. The <acronym>KDC</acronym> is considered tickets. The <acronym>KDC</acronym> is considered
<quote>trusted</quote> by all other computers in the trusted by all other computers in the
<application>Kerberos</application> realm, and thus has <application>Kerberos</application> realm, and thus has
heightened security concerns.</para> heightened security concerns.</para>
<para>While running the <application>Kerberos</application> <para>While running a <acronym>KDC</acronym>
server requires very few computing resources, a dedicated requires few computing resources, a dedicated
machine acting only as a <acronym>KDC</acronym> is recommended machine acting only as a <acronym>KDC</acronym> is recommended
for security reasons.</para> for security reasons.</para>
<para>To begin setting up a <acronym>KDC</acronym>, ensure that <para>To begin setting up a <acronym>KDC</acronym>, add these lines to
<filename>/etc/rc.conf</filename> contains the correct <filename>/etc/rc.conf</filename>:</para>
settings to act as a <acronym>KDC</acronym>. As required,
adjust paths to reflect the system:</para>
<programlisting>kerberos5_server_enable="YES" <programlisting>kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting> kadmind5_server_enable="YES"</programlisting>
@ -1189,132 +1164,131 @@ kadmind5_server_enable="YES"</programlisting>
follows:</para> follows:</para>
<programlisting>[libdefaults] <programlisting>[libdefaults]
default_realm = EXAMPLE.ORG default_realm = <replaceable>EXAMPLE.ORG</replaceable>
[realms] [realms]
EXAMPLE.ORG = { <replaceable>EXAMPLE.ORG</replaceable> = {
kdc = kerberos.example.org kdc = <replaceable>kerberos.example.org</replaceable>
admin_server = kerberos.example.org admin_server = <replaceable>kerberos.example.org</replaceable>
} }
[domain_realm] [domain_realm]
.example.org = EXAMPLE.ORG</programlisting> <replaceable>.example.org</replaceable> = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
<para>This <filename>/etc/krb5.conf</filename> implies that the <para>In this example, the
<acronym>KDC</acronym> will use the fully-qualified hostname <acronym>KDC</acronym> will use the fully-qualified hostname
<systemitem <systemitem
class="fqdomainname">kerberos.example.org</systemitem>. Add class="fqdomainname">kerberos.example.org</systemitem>. Add
a CNAME (alias) entry to the zone file to accomplish this a <acronym>CNAME</acronym> entry to the <acronym>DNS</acronym> zone file
if the <acronym>KDC</acronym> has a different hostname.</para> if the <acronym>KDC</acronym> has a different hostname than
that specified in <filename>/etc/krb5.conf</filename>.</para>
<note>
<para>For large networks with a properly configured <para>For large networks with a properly configured
<acronym>DNS</acronym> server, the above example could be <acronym>DNS</acronym> server, the above example could be
trimmed to:</para> trimmed to:</para>
<programlisting>[libdefaults] <programlisting>[libdefaults]
default_realm = EXAMPLE.ORG</programlisting> default_realm = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
<para>With the following lines being appended to the <para>With the following lines being appended to the
<systemitem <systemitem
class="fqdomainname">example.org</systemitem> zone class="fqdomainname">example.org</systemitem> zone
file:</para> file:</para>
<programlisting>_kerberos._udp IN SRV 01 00 88 kerberos.example.org. <programlisting>_kerberos._udp IN SRV 01 00 88 <replaceable>kerberos.example.org</replaceable>.
_kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 <replaceable>kerberos.example.org</replaceable>.
_kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 <replaceable>kerberos.example.org</replaceable>.
_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 <replaceable>kerberos.example.org</replaceable>.
_kerberos IN TXT EXAMPLE.ORG</programlisting> _kerberos IN TXT <replaceable>EXAMPLE.ORG</replaceable></programlisting>
</note>
<note> <note>
<para>For clients to be able to find the <para>In order for clients to be able to find the
<application>Kerberos</application> services, it <application>Kerberos</application> services, the <acronym>KDC</acronym>
<emphasis>must</emphasis> have either a fully configured <emphasis>must</emphasis> have either a fully configured
<filename>/etc/krb5.conf</filename> or a minimally <filename>/etc/krb5.conf</filename> or a minimally
configured <filename>/etc/krb5.conf</filename> configured <filename>/etc/krb5.conf</filename>
<emphasis>and</emphasis> a properly configured DNS <emphasis>and</emphasis> a properly configured <acronym>DNS</acronym>
server.</para> server.</para>
</note> </note>
<para>Next, create the <application>Kerberos</application> <para>Next, create the <application>Kerberos</application>
database which contains the keys of all principals encrypted database which contains the keys of all principals (users and hosts) encrypted
with a master password. It is not required to remember this with a master password. It is not required to remember this
password as it will be stored in password as it will be stored in
<filename>/var/heimdal/m-key</filename>. To create the <filename>/var/heimdal/m-key</filename>. To create the
master key, run &man.kstash.8; and enter a password.</para> master key, run <command>kstash</command> and enter a password:</para>
<screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput>
Verifying password - Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput></screen>
<para>Once the master key has been created, initialize the <para>Once the master key has been created, initialize the
database using <command>kadmin -l</command>. This option database using <command>kadmin -l</command>. This option
instructs &man.kadmin.8; to modify the local database files instructs <command>kadmin</command> to modify the local database files
directly rather than going through the &man.kadmind.8; network directly rather than going through the &man.kadmind.8; network
service. This handles the chicken-and-egg problem of trying service. This handles the chicken-and-egg problem of trying
to connect to the database before it is created. At the to connect to the database before it is created. At the
&man.kadmin.8; prompt, use <command>init</command> to create <command>kadmin</command> prompt, use <command>init</command> to create
the realm's initial database.</para> the realm's initial database:</para>
<para>Lastly, while still in &man.kadmin.8;, create the first <screen>&prompt.root; <userinput>kadmin -l</userinput>
kadmin&gt; <userinput>init <replaceable>EXAMPLE.ORG</replaceable></userinput>
Realm max ticket life [unlimited]:</screen>
<para>Lastly, while still in <command>kadmin</command>, create the first
principal using <command>add</command>. Stick to the default principal using <command>add</command>. Stick to the default
options for the principal for now, as these can be changed options for the principal for now, as these can be changed
later with <command>modify</command>. Type later with <command>modify</command>. Type
<literal>?</literal> at the &man.kadmin.8; prompt to see the <literal>?</literal> at the prompt to see the
available options.</para> available options.</para>
<para>A sample database creation session is shown below:</para> <screen>kadmin&gt; <userinput>add <replaceable>tillman</replaceable></userinput>
<screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput>xxxxxxxx</userinput>
Verifying password - Master key: <userinput>xxxxxxxx</userinput>
&prompt.root; <userinput>kadmin -l</userinput>
kadmin&gt; <userinput>init EXAMPLE.ORG</userinput>
Realm max ticket life [unlimited]:
kadmin&gt; <userinput>add tillman</userinput>
Max ticket life [unlimited]: Max ticket life [unlimited]:
Max renewable life [unlimited]: Max renewable life [unlimited]:
Attributes []: Attributes []:
Password: <userinput>xxxxxxxx</userinput> Password: <userinput><replaceable>xxxxxxxx</replaceable></userinput>
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen> Verifying password - Password: <userinput><replaceable>xxxxxxxx</replaceable></userinput></screen>
<para>Next, start the <acronym>KDC</acronym> services. Run <para>Next, start the <acronym>KDC</acronym> services by running
<command>service kerberos start</command> and <command>service kerberos start</command> and
<command>service kadmind start</command> to bring up the <command>service kadmind start</command>.
services. While there will not be any kerberized daemons While there will not be any kerberized daemons
running at this point, it is possible to confirm that the running at this point, it is possible to confirm that the
<acronym>KDC</acronym> is functioning by obtaining and <acronym>KDC</acronym> is functioning by obtaining and
listing a ticket for the principal (user) that was just listing a ticket for the principal that was just
created from the command-line of the <acronym>KDC</acronym> created from the command-line of the <acronym>KDC</acronym>:</para>
itself:</para>
<screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput> <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
tillman@EXAMPLE.ORG's Password: tillman@EXAMPLE.ORG's Password:
&prompt.user; <userinput>klist</userinput> &prompt.user; <userinput>klist</userinput>
Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename> Credentials cache: FILE:/tmp/krb5cc_500
Principal: tillman@EXAMPLE.ORG Principal: tillman@EXAMPLE.ORG
Issued Expires Principal Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen> Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
<para>The ticket can then be revoked when finished:</para> <para>The temporary ticket can be revoked when the test is finished:</para>
<screen>&prompt.user; <userinput>kdestroy</userinput></screen> <screen>&prompt.user; <userinput>kdestroy</userinput></screen>
</sect2> </sect2>
<sect2> <sect2>
<title><application>Kerberos</application> Enabling a Server <title>Configuring a Server to use
with Heimdal Services</title> <application>Kerberos</application></title>
<indexterm> <indexterm>
<primary>Kerberos5</primary> <primary>Kerberos5</primary>
<secondary>enabling services</secondary> <secondary>enabling services</secondary>
</indexterm> </indexterm>
<para>First, copy <para>To configure a server to use
<application>Kerberos</application> authentication, copy
<filename>/etc/krb5.conf</filename> from the <filename>/etc/krb5.conf</filename> from the
<acronym>KDC</acronym> to the client computer in a secure <acronym>KDC</acronym> to the server in a secure
fashion, such as &man.scp.1;, or physically via removable fashion, such as &man.scp.1;, or physically via removable
media.</para> media.</para>
<para>Next, create <filename>/etc/krb5.keytab</filename>. <para>Next, create <filename>/etc/krb5.keytab</filename> on the
server.
This is the major difference between a server providing This is the major difference between a server providing
<application>Kerberos</application> enabled daemons and a <application>Kerberos</application> enabled daemons and a
workstation: the server must have a workstation: the server must have a
@ -1323,20 +1297,18 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
<acronym>KDC</acronym> to verify each others identity. It <acronym>KDC</acronym> to verify each others identity. It
must be transmitted to the server in a secure fashion, as must be transmitted to the server in a secure fashion, as
the security of the server can be broken if the key is made the security of the server can be broken if the key is made
public.</para> public. Typically, the <filename>keytab</filename> is transferred
to the server using <command>kadmin</command>. This is handy because the
<para>Typically, the <filename>keytab</filename> is transferred
to the server using &man.kadmin.8;. This is handy because the
host principal, the <acronym>KDC</acronym> end of the host principal, the <acronym>KDC</acronym> end of the
<filename>krb5.keytab</filename>, is also created using <filename>krb5.keytab</filename>, is also created using
&man.kadmin.8;.</para> <command>kadmin</command>.</para>
<para>A ticket must already be obtained and this ticket must be <para>A ticket must first be obtained and this ticket must be
allowed to use the &man.kadmin.8; interface in the allowed to use the <command>kadmin</command> interface in the
<filename>kadmind.acl</filename>. See the section titled <filename>kadmind.acl</filename>. See the section titled
<quote>Remote administration</quote> in<command>info <quote>Remote administration</quote> in <command>info
heimdal</command> for details on designing access control heimdal</command> for details on designing access control
lists. Instead of enabling remote &man.kadmin.8; access, the lists. Instead of enabling remote <command>kadmin</command> access, the
administrator can securely connect to the administrator can securely connect to the
<acronym>KDC</acronym> via the local console or &man.ssh.1;, <acronym>KDC</acronym> via the local console or &man.ssh.1;,
and perform administration locally using and perform administration locally using
@ -1346,15 +1318,14 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
use <command>add --random-key</command> from the use <command>add --random-key</command> from the
<application>Kerberos</application> server. This adds <application>Kerberos</application> server. This adds
the server's host principal. Then, use <command>ext</command> the server's host principal. Then, use <command>ext</command>
to extract the server's host principal to its own keytab. For to extract the server's host principal to its own keytab:</para>
example:</para>
<screen>&prompt.root; <userinput>kadmin</userinput> <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput> kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput>
Max ticket life [unlimited]: Max ticket life [unlimited]:
Max renewable life [unlimited]: Max renewable life [unlimited]:
Attributes []: Attributes []:
kadmin&gt;<userinput> ext host/myserver.example.org</userinput> kadmin&gt;<userinput> ext <replaceable>host/myserver.example.org</replaceable></userinput>
kadmin&gt;<userinput> exit</userinput></screen> kadmin&gt;<userinput> exit</userinput></screen>
<para>Note that <command>ext</command> stores the extracted key <para>Note that <command>ext</command> stores the extracted key
@ -1362,15 +1333,14 @@ kadmin&gt;<userinput> exit</userinput></screen>
<para>If &man.kadmind.8; is not running on the <para>If &man.kadmind.8; is not running on the
<acronym>KDC</acronym> and there is no access to <acronym>KDC</acronym> and there is no access to
&man.kadmin.8; remotely, add the host principal (<systemitem &man.kadmin.8; remotely, add the server's host principal
class="username">host/myserver.EXAMPLE.ORG</systemitem>)
directly on the <acronym>KDC</acronym> and then extract it to directly on the <acronym>KDC</acronym> and then extract it to
a temporary file to avoid overwriting the a temporary file to avoid overwriting the
<filename>/etc/krb5.keytab</filename> on the <filename>/etc/krb5.keytab</filename> on the
<acronym>KDC</acronym>, using something like this:</para> <acronym>KDC</acronym>:</para>
<screen>&prompt.root; <userinput>kadmin</userinput> <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin&gt;<userinput> ext --keytab=/tmp/example.keytab host/myserver.example.org</userinput> kadmin&gt;<userinput> ext --keytab=/tmp/example.keytab <replaceable>host/myserver.example.org</replaceable></userinput>
kadmin&gt;<userinput> exit</userinput></screen> kadmin&gt;<userinput> exit</userinput></screen>
<para>The keytab can then be securely copied to the server <para>The keytab can then be securely copied to the server