Editorial review of first 1/2 of Kerberos chapter.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
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
|
|
@ -303,7 +303,7 @@
|
|||
time, all network logins should avoid the use of passwords in
|
||||
exchange for this two factor authentication method. For
|
||||
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
|
||||
their network.</para>
|
||||
|
||||
|
|
@ -1050,7 +1050,7 @@ sendmail : PARANOID : deny</programlisting>
|
|||
|
||||
<sect1 xml:id="kerberos5">
|
||||
<info>
|
||||
<title><application>Kerberos5</application></title>
|
||||
<title><application>Kerberos</application></title>
|
||||
|
||||
<authorgroup>
|
||||
<author><personname><firstname>Tillman</firstname><surname>Hodgson</surname></personname><contrib>Contributed
|
||||
|
|
@ -1062,11 +1062,15 @@ sendmail : PARANOID : deny</programlisting>
|
|||
</authorgroup>
|
||||
</info>
|
||||
|
||||
<para><application>Kerberos</application> is a network add-on
|
||||
system/protocol that allows users to authenticate themselves
|
||||
through the services of a secure server.
|
||||
<para><application>Kerberos</application> is a network
|
||||
authentication protocol which was originally created by the
|
||||
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
|
||||
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
|
||||
authenticates with <application>Kerberos</application>, their
|
||||
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
|
||||
to provide the secure authentication of users on the network.
|
||||
It does not provide authorization functions (what users are
|
||||
allowed to do) or auditing functions (what those users did). It
|
||||
It does not provide authorization
|
||||
or auditing functions. It
|
||||
is recommended that <application>Kerberos</application> be used
|
||||
with other security methods which provide authorization and
|
||||
audit services.</para>
|
||||
|
||||
<para>The current version of the protocol is version 5, described
|
||||
in <acronym>RFC</acronym> 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
|
||||
<application>Kerberos</application> as distributed for &os;.
|
||||
Refer to the relevant manual pages for more complete
|
||||
descriptions.</para>
|
||||
<application>Kerberos</application> using the Heimdal
|
||||
distribution included in &os;.</para>
|
||||
|
||||
<para>For purposes of demonstrating a
|
||||
<application>Kerberos</application> installation, the various
|
||||
<application>Kerberos</application> installation, the
|
||||
name spaces will be as follows:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>The <acronym>DNS</acronym> domain (<quote>zone</quote>)
|
||||
<para>The <acronym>DNS</acronym> domain (zone)
|
||||
will be <systemitem
|
||||
class="fqdomainname">example.org</systemitem>.</para>
|
||||
</listitem>
|
||||
|
|
@ -1104,57 +1126,12 @@ sendmail : PARANOID : deny</programlisting>
|
|||
|
||||
<note>
|
||||
<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
|
||||
and assures inter-operation with other
|
||||
<application>Kerberos</application> realms.</para>
|
||||
</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> 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>
|
||||
<title>Setting up a Heimdal <acronym>KDC</acronym></title>
|
||||
|
||||
|
|
@ -1168,19 +1145,17 @@ sendmail : PARANOID : deny</programlisting>
|
|||
<application>Kerberos</application> provides. It is the
|
||||
computer that issues <application>Kerberos</application>
|
||||
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
|
||||
heightened security concerns.</para>
|
||||
|
||||
<para>While running the <application>Kerberos</application>
|
||||
server requires very few computing resources, a dedicated
|
||||
<para>While running a <acronym>KDC</acronym>
|
||||
requires few computing resources, a dedicated
|
||||
machine acting only as a <acronym>KDC</acronym> is recommended
|
||||
for security reasons.</para>
|
||||
|
||||
<para>To begin setting up a <acronym>KDC</acronym>, ensure that
|
||||
<filename>/etc/rc.conf</filename> contains the correct
|
||||
settings to act as a <acronym>KDC</acronym>. As required,
|
||||
adjust paths to reflect the system:</para>
|
||||
<para>To begin setting up a <acronym>KDC</acronym>, add these lines to
|
||||
<filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>kerberos5_server_enable="YES"
|
||||
kadmind5_server_enable="YES"</programlisting>
|
||||
|
|
@ -1189,132 +1164,131 @@ kadmind5_server_enable="YES"</programlisting>
|
|||
follows:</para>
|
||||
|
||||
<programlisting>[libdefaults]
|
||||
default_realm = EXAMPLE.ORG
|
||||
default_realm = <replaceable>EXAMPLE.ORG</replaceable>
|
||||
[realms]
|
||||
EXAMPLE.ORG = {
|
||||
kdc = kerberos.example.org
|
||||
admin_server = kerberos.example.org
|
||||
<replaceable>EXAMPLE.ORG</replaceable> = {
|
||||
kdc = <replaceable>kerberos.example.org</replaceable>
|
||||
admin_server = <replaceable>kerberos.example.org</replaceable>
|
||||
}
|
||||
[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
|
||||
<systemitem
|
||||
class="fqdomainname">kerberos.example.org</systemitem>. Add
|
||||
a CNAME (alias) entry to the zone file to accomplish this
|
||||
if the <acronym>KDC</acronym> has a different hostname.</para>
|
||||
a <acronym>CNAME</acronym> entry to the <acronym>DNS</acronym> zone file
|
||||
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
|
||||
<acronym>DNS</acronym> server, the above example could be
|
||||
trimmed to:</para>
|
||||
|
||||
<programlisting>[libdefaults]
|
||||
default_realm = EXAMPLE.ORG</programlisting>
|
||||
default_realm = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
|
||||
|
||||
<para>With the following lines being appended to the
|
||||
<systemitem
|
||||
class="fqdomainname">example.org</systemitem> zone
|
||||
file:</para>
|
||||
|
||||
<programlisting>_kerberos._udp IN SRV 01 00 88 kerberos.example.org.
|
||||
_kerberos._tcp IN SRV 01 00 88 kerberos.example.org.
|
||||
_kpasswd._udp IN SRV 01 00 464 kerberos.example.org.
|
||||
_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org.
|
||||
_kerberos IN TXT EXAMPLE.ORG</programlisting>
|
||||
</note>
|
||||
<programlisting>_kerberos._udp IN SRV 01 00 88 <replaceable>kerberos.example.org</replaceable>.
|
||||
_kerberos._tcp IN SRV 01 00 88 <replaceable>kerberos.example.org</replaceable>.
|
||||
_kpasswd._udp IN SRV 01 00 464 <replaceable>kerberos.example.org</replaceable>.
|
||||
_kerberos-adm._tcp IN SRV 01 00 749 <replaceable>kerberos.example.org</replaceable>.
|
||||
_kerberos IN TXT <replaceable>EXAMPLE.ORG</replaceable></programlisting>
|
||||
|
||||
<note>
|
||||
<para>For clients to be able to find the
|
||||
<application>Kerberos</application> services, it
|
||||
<para>In order for clients to be able to find the
|
||||
<application>Kerberos</application> services, the <acronym>KDC</acronym>
|
||||
<emphasis>must</emphasis> have either a fully configured
|
||||
<filename>/etc/krb5.conf</filename> or a minimally
|
||||
configured <filename>/etc/krb5.conf</filename>
|
||||
<emphasis>and</emphasis> a properly configured DNS
|
||||
<emphasis>and</emphasis> a properly configured <acronym>DNS</acronym>
|
||||
server.</para>
|
||||
</note>
|
||||
|
||||
<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
|
||||
password as it will be stored in
|
||||
<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
|
||||
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
|
||||
service. This handles the chicken-and-egg problem of trying
|
||||
to connect to the database before it is created. At the
|
||||
&man.kadmin.8; prompt, use <command>init</command> to create
|
||||
the realm's initial database.</para>
|
||||
<command>kadmin</command> prompt, use <command>init</command> to create
|
||||
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> <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
|
||||
options for the principal for now, as these can be changed
|
||||
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>
|
||||
|
||||
<para>A sample database creation session is shown below:</para>
|
||||
|
||||
<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> <userinput>init EXAMPLE.ORG</userinput>
|
||||
Realm max ticket life [unlimited]:
|
||||
kadmin> <userinput>add tillman</userinput>
|
||||
<screen>kadmin> <userinput>add <replaceable>tillman</replaceable></userinput>
|
||||
Max ticket life [unlimited]:
|
||||
Max renewable life [unlimited]:
|
||||
Attributes []:
|
||||
Password: <userinput>xxxxxxxx</userinput>
|
||||
Verifying password - Password: <userinput>xxxxxxxx</userinput></screen>
|
||||
Password: <userinput><replaceable>xxxxxxxx</replaceable></userinput>
|
||||
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 kadmind start</command> to bring up the
|
||||
services. While there will not be any kerberized daemons
|
||||
<command>service kadmind start</command>.
|
||||
While there will not be any kerberized daemons
|
||||
running at this point, it is possible to confirm that the
|
||||
<acronym>KDC</acronym> is functioning by obtaining and
|
||||
listing a ticket for the principal (user) that was just
|
||||
created from the command-line of the <acronym>KDC</acronym>
|
||||
itself:</para>
|
||||
listing a ticket for the principal that was just
|
||||
created from the command-line of the <acronym>KDC</acronym>:</para>
|
||||
|
||||
<screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
|
||||
tillman@EXAMPLE.ORG's Password:
|
||||
|
||||
&prompt.user; <userinput>klist</userinput>
|
||||
Credentials cache: FILE:<filename>/tmp/krb5cc_500</filename>
|
||||
Credentials cache: FILE:/tmp/krb5cc_500
|
||||
Principal: tillman@EXAMPLE.ORG
|
||||
|
||||
Issued Expires Principal
|
||||
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>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title><application>Kerberos</application> Enabling a Server
|
||||
with Heimdal Services</title>
|
||||
<title>Configuring a Server to use
|
||||
<application>Kerberos</application></title>
|
||||
|
||||
<indexterm>
|
||||
<primary>Kerberos5</primary>
|
||||
<secondary>enabling services</secondary>
|
||||
</indexterm>
|
||||
|
||||
<para>First, copy
|
||||
<para>To configure a server to use
|
||||
<application>Kerberos</application> authentication, copy
|
||||
<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
|
||||
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
|
||||
<application>Kerberos</application> enabled daemons and 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
|
||||
must be transmitted to the server in a secure fashion, as
|
||||
the security of the server can be broken if the key is made
|
||||
public.</para>
|
||||
|
||||
<para>Typically, the <filename>keytab</filename> is transferred
|
||||
to the server using &man.kadmin.8;. This is handy because the
|
||||
public. Typically, the <filename>keytab</filename> is transferred
|
||||
to the server using <command>kadmin</command>. This is handy because the
|
||||
host principal, the <acronym>KDC</acronym> end of the
|
||||
<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
|
||||
allowed to use the &man.kadmin.8; interface in the
|
||||
<para>A ticket must first be obtained and this ticket must be
|
||||
allowed to use the <command>kadmin</command> interface in the
|
||||
<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
|
||||
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
|
||||
<acronym>KDC</acronym> via the local console or &man.ssh.1;,
|
||||
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
|
||||
<application>Kerberos</application> server. This adds
|
||||
the server's host principal. Then, use <command>ext</command>
|
||||
to extract the server's host principal to its own keytab. For
|
||||
example:</para>
|
||||
to extract the server's host principal to its own keytab:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>kadmin</userinput>
|
||||
kadmin><userinput> add --random-key host/myserver.example.org</userinput>
|
||||
Max ticket life [unlimited]:
|
||||
Max renewable life [unlimited]:
|
||||
Attributes []:
|
||||
kadmin><userinput> ext host/myserver.example.org</userinput>
|
||||
kadmin><userinput> ext <replaceable>host/myserver.example.org</replaceable></userinput>
|
||||
kadmin><userinput> exit</userinput></screen>
|
||||
|
||||
<para>Note that <command>ext</command> stores the extracted key
|
||||
|
|
@ -1362,15 +1333,14 @@ kadmin><userinput> exit</userinput></screen>
|
|||
|
||||
<para>If &man.kadmind.8; is not running on the
|
||||
<acronym>KDC</acronym> and there is no access to
|
||||
&man.kadmin.8; remotely, add the host principal (<systemitem
|
||||
class="username">host/myserver.EXAMPLE.ORG</systemitem>)
|
||||
&man.kadmin.8; remotely, add the server's host principal
|
||||
directly on the <acronym>KDC</acronym> and then extract it to
|
||||
a temporary file to avoid overwriting 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>
|
||||
kadmin><userinput> ext --keytab=/tmp/example.keytab host/myserver.example.org</userinput>
|
||||
kadmin><userinput> ext --keytab=/tmp/example.keytab <replaceable>host/myserver.example.org</replaceable></userinput>
|
||||
kadmin><userinput> exit</userinput></screen>
|
||||
|
||||
<para>The keytab can then be securely copied to the server
|
||||
|
|
|
|||
Loading…
Reference in a new issue