kerberos5.html

FreeBSD安装说明概述 FreeBSD 提供了一个以文字为主

Password: <kbd class="USERINPUT">xxxxxxxx</kbd>
Verifying password - Password: <kbd class="USERINPUT">xxxxxxxx</kbd>
</pre>

<p>Now it is time to start up the <acronym class="ACRONYM">KDC</acronym> services. Run
<tt class="COMMAND">/etc/rc.d/kerberos start</tt> and <tt
class="COMMAND">/etc/rc.d/kadmind start</tt> to bring up the services. Note that you
won't have any kerberized daemons running at this point but you should be able to confirm
the that the <acronym class="ACRONYM">KDC</acronym> is functioning by obtaining and
listing a ticket for the principal (user) that you just created from the command-line of
the <acronym class="ACRONYM">KDC</acronym> itself:</p>

<pre class="SCREEN">
<samp class="PROMPT">%</samp> <kbd class="USERINPUT">k5init <var
class="REPLACEABLE">tillman</var></kbd>
[e-mail]'s Password:

<samp class="PROMPT">%</samp> <kbd class="USERINPUT">k5list</kbd>
Credentials cache: FILE:<tt class="FILENAME">/tmp/krb5cc_500</tt>
    Principal: [e-mail]

  Issued           Expires          Principal
Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/[e-mail]
</pre>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN11672" name="AEN11672">10.7.3. <b
class="APPLICATION">Kerberos</b> enabling a server with Heimdal services</a></h2>

<p>First, we need a copy of the <b class="APPLICATION">Kerberos</b> configuration file,
<tt class="FILENAME">/etc/krb5.conf</tt>. To do so, simply copy it over to the client
computer from the <acronym class="ACRONYM">KDC</acronym> in a secure fashion (using
network utilities, such as <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">scp</span>(1)</span>, or physically via a floppy disk).</p>

<p>Next you need a <tt class="FILENAME">/etc/krb5.keytab</tt> file. This is the major
difference between a server providing <b class="APPLICATION">Kerberos</b> enabled daemons
and a workstation -- the server must have a <tt class="FILENAME">keytab</tt> file. This
file contains the servers host key, which allows it and the <acronym
class="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. This explicitly means that transferring it via a clear text channel, such as
<acronym class="ACRONYM">FTP</acronym>, is a very bad idea.</p>

<p>Typically, you transfer to the <tt class="FILENAME">keytab</tt> to the server using
the <tt class="COMMAND">kadmin</tt> program. This is handy because you also need to
create the host principal (the <acronym class="ACRONYM">KDC</acronym> end of the <tt
class="FILENAME">krb5.keytab</tt>) using <tt class="COMMAND">kadmin</tt>.</p>

<p>Note that you must have already obtained a ticket and that this ticket must be allowed
to use the <tt class="COMMAND">kadmin</tt> interface in the <tt
class="FILENAME">kadmind.acl</tt>. See the section titled ``Remote administration'' in
the Heimdal info pages (<tt class="COMMAND">info heimdal</tt>) for details on designing
access control lists. If you do not want to enable remote <tt class="COMMAND">kadmin</tt>
access, you can simply securely connect to the <acronym class="ACRONYM">KDC</acronym>
(via local console, <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">ssh</span>(1)</span> or <b class="APPLICATION">Kerberos</b> <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">telnet</span>(1)</span>) and perform
administration locally using <tt class="COMMAND">kadmin -l</tt>.</p>

<p>After installing the <tt class="FILENAME">/etc/krb5.conf</tt> file, you can use <tt
class="COMMAND">kadmin</tt> from the <b class="APPLICATION">Kerberos</b> server. The <tt
class="COMMAND">add --random-key</tt> command will let you add the servers host
principal, and the <tt class="COMMAND">ext</tt> command will allow you to extract the
servers host principal to its own keytab. For example:</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">kadmin</kbd>
kadmin&#62; <kbd class="USERINPUT">add --random-key host/myserver.example.org</kbd>
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin&#62; <kbd class="USERINPUT">ext host/myserver.example.org</kbd>
kadmin&#62; <kbd class="USERINPUT">exit</kbd>
</pre>

<p>Note that the <tt class="COMMAND">ext</tt> command (short for ``extract'') stores the
extracted key in <tt class="FILENAME">/etc/krb5.keytab</tt> by default.</p>

<p>If you do not have <tt class="COMMAND">kadmind</tt> running on the <acronym
class="ACRONYM">KDC</acronym> (possibly for security reasons) and thus do not have access
to <tt class="COMMAND">kadmin</tt> remotely, you can add the host principal (<tt
class="USERNAME">host/myserver.EXAMPLE.ORG</tt>) directly on the <acronym
class="ACRONYM">KDC</acronym> and then extract it to a temporary file (to avoid
over-writing the <tt class="FILENAME">/etc/krb5.keytab</tt> on the <acronym
class="ACRONYM">KDC</acronym>) using something like this:</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">kadmin</kbd>
kadmin&#62; <kbd
class="USERINPUT">ext --keytab=/tmp/example.keytab host/myserver.example.org</kbd>
kadmin&#62; <kbd class="USERINPUT">exit</kbd>
</pre>

<p>You can then securely copy the keytab to the server computer (using <tt
class="COMMAND">scp</tt> or a floppy, for example). Be sure to specify a non-default
keytab name to avoid over-writing the keytab on the <acronym
class="ACRONYM">KDC</acronym>.</p>

<p>At this point your server can communicate with the <acronym
class="ACRONYM">KDC</acronym> (due to its <tt class="FILENAME">krb5.conf</tt> file) and
it can prove its own identity (due to the <tt class="FILENAME">krb5.keytab</tt> file). It
is now ready for you to enable some <b class="APPLICATION">Kerberos</b> services. For
this example we will enable the <tt class="COMMAND">telnet</tt> service by putting a line
like this into your <tt class="FILENAME">/etc/inetd.conf</tt> and then restarting the
<span class="CITEREFENTRY"><span class="REFENTRYTITLE">inetd</span>(8)</span> service
with <tt class="COMMAND">/etc/rc.d/inetd restart</tt>:</p>

<pre class="PROGRAMLISTING">
telnet    stream  tcp     nowait  root    /usr/libexec/telnetd  telnetd -a user
</pre>

<p>The critical bit is that the <tt class="COMMAND">-a</tt> (for authentication) type is
set to user. Consult the <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">telnetd</span>(8)</span> manual page for more details.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN11761" name="AEN11761">10.7.4. <b
class="APPLICATION">Kerberos</b> enabling a client with Heimdal</a></h2>

<p>Setting up a client computer is almost trivially easy. As far as <b
class="APPLICATION">Kerberos</b> configuration goes, you only need the <b
class="APPLICATION">Kerberos</b> configuration file, located at <tt
class="FILENAME">/etc/krb5.conf</tt>. Simply securely copy it over to the client computer
from the <acronym class="ACRONYM">KDC</acronym>.</p>

<p>Test your client computer by attempting to use <tt class="COMMAND">kinit</tt>, <tt
class="COMMAND">klist</tt>, and <tt class="COMMAND">kdestroy</tt> from the client to
obtain, show, and then delete a ticket for the principal you created above. You should
also be able to use <b class="APPLICATION">Kerberos</b> applications to connect to <b
class="APPLICATION">Kerberos</b> enabled servers, though if that does not work and
obtaining a ticket does the problem is likely with the server and not with the client or
the <acronym class="ACRONYM">KDC</acronym>.</p>

<p>When testing an application like <tt class="COMMAND">telnet</tt>, try using a packet
sniffer (such as <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">tcpdump</span>(1)</span>) to confirm that your password is not sent
in the clear. Try using <tt class="COMMAND">telnet</tt> with the <var
class="LITERAL">-x</var> option, which encrypts the entire data stream (similar to <tt
class="COMMAND">ssh</tt>).</p>

<p>The core <b class="APPLICATION">Kerberos</b> client applications (traditionally named
<tt class="COMMAND">kinit</tt>, <tt class="COMMAND">klist</tt>, <tt
class="COMMAND">kdestroy</tt>, and <tt class="COMMAND">kpasswd</tt>) are installed in the
base FreeBSD install. Note that FreeBSD versions prior to 5.0 renamed them to <tt
class="COMMAND">k5init</tt>, <tt class="COMMAND">k5list</tt>, <tt
class="COMMAND">k5destroy</tt>, <tt class="COMMAND">k5passwd</tt>, and <tt
class="COMMAND">k5stash</tt> (though it is typically only used once).</p>

<p>Various non-core <b class="APPLICATION">Kerberos</b> client applications are also
installed by default. This is where the ``minimal'' nature of the base Heimdal
installation is felt: <tt class="COMMAND">telnet</tt> is the only <b
class="APPLICATION">Kerberos</b> enabled service.</p>

<p>The Heimdal port adds some of the missing client applications: <b
class="APPLICATION">Kerberos</b> enabled versions of <tt class="COMMAND">ftp</tt>, <tt
class="COMMAND">rsh</tt>, <tt class="COMMAND">rcp</tt>, <tt class="COMMAND">rlogin</tt>,
and a few other less common programs. The <acronym class="ACRONYM">MIT</acronym> port
also contains a full suite of <b class="APPLICATION">Kerberos</b> client
applications.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN11811" name="AEN11811">10.7.5. User configuration files: <tt
class="FILENAME">.k5login</tt> and <tt class="FILENAME">.k5users</tt></a></h2>

<p>Users within a realm typically have their <b class="APPLICATION">Kerberos</b>
principal (such as <tt class="USERNAME">[e-mail]</tt>) mapped to a local user
account (such as a local account named <tt class="USERNAME">tillman</tt>). Client
applications such as <tt class="COMMAND">telnet</tt> usually do not require a user name
or a principal.</p>

<p>Occasionally, however, you want to grant access to a local user account to someone who
does not have a matching <b class="APPLICATION">Kerberos</b> principal. For example, <tt
class="USERNAME">[e-mail]</tt> may need access to the local user account <tt
class="USERNAME">webdevelopers</tt>. Other principals may also need access to that local
account.</p>

<p>The <tt class="FILENAME">.k5login</tt> and <tt class="FILENAME">.k5users</tt> files,
placed in a users home directory, can be used similar to a powerful combination of <tt
class="FILENAME">.hosts</tt> and <tt class="FILENAME">.rhosts</tt>, solving this problem.
For example, if a <tt class="FILENAME">.k5login</tt> with the following contents:</p>

<pre class="SCREEN">
[e-mail]
[e-mail]
</pre>

<p>Were to be placed into the home directory of the local user <tt
class="USERNAME">webdevelopers</tt> then both principals listed would have access to that
account without requiring a shared password.</p>

<p>Reading the man pages for these commands is recommended. Note that the <tt
class="COMMAND">ksu</tt> man page covers <tt class="FILENAME">.k5users</tt>.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN11839" name="AEN11839">10.7.6. <b
class="APPLICATION">Kerberos</b> Tips, Tricks, and Troubleshooting</a></h2>

<ul>
<li>
<p>When using either the Heimdal or <acronym class="ACRONYM">MIT</acronym> <b
class="APPLICATION">Kerberos</b> ports ensure that your <tt class="ENVAR">PATH</tt>
environment variable lists the <b class="APPLICATION">Kerberos</b> versions of the client
applications before the system versions.</p>
</li>

<li>
<p>Is your time in sync? Are you sure? If the time is not in sync (typically within five
minutes) authentication will fail.</p>
</li>

<li>
<p><acronym class="ACRONYM">MIT</acronym> and Heimdal inter-operate nicely. Except for
<tt class="COMMAND">kadmin</tt>, the protocol for which is not standardized.</p>
</li>

<li>
<p>If you change your hostname, you also need to change your <tt
class="USERNAME">host/</tt> principal and update your keytab. This also applies to
special keytab entries like the <tt class="USERNAME">www/</tt> principal used for
Apache's <a
href="http://www.FreeBSD.org/cgi/url.cgi?ports/www/mod_auth_kerb/pkg-descr"><tt
class="FILENAME">www/mod_auth_kerb</tt></a>.</p>
</li>

<li>
<p>All hosts in your realm must be resolvable (both forwards and reverse) in <acronym
class="ACRONYM">DNS</acronym> (or <tt class="FILENAME">/etc/hosts</tt> as a minimum).
CNAMEs will work, but the A and PTR records must be correct and in place. The error
message isn't very intuitive: ``<tt class="ERRORNAME">Kerberos5 refuses authentication
because Read req failed: Key table entry not found</tt>''.</p>
</li>

<li>
<p>Some operating systems that may being acting as clients to your <acronym
class="ACRONYM">KDC</acronym> do not set the permissions for <tt class="COMMAND">ksu</tt>
to be setuid <tt class="USERNAME">root</tt>. This means that <tt class="COMMAND">ksu</tt>
does not work, which is a good security idea but annoying. This is not a <acronym