Kerberos5 chapter [was: Your message to freebsd-doc awaits moderator approval]
Simon L. Nielsen
simon at FreeBSD.org
Sat Aug 23 15:23:25 UTC 2003
On 2003.08.23 09:48:17 -0400, Tom Rhodes wrote:
> We can't send plain text emails anymore??
It normally works fine for me. Perhaps the spam filters have been set
to be a bit more aggressive due to all the worm bounce mails lately
(just a guess).
> Here I bring the kerberos5 handbook section to everyone for review.
> A few tidbits of pre-review information:
>
> This was done under the theory that KerberosIV is gone from 5.1 and
> post releases. Thus there is a history part, and some extra information;
> this was done so that we can fade away the other chapter with ease.
> If it is desired for some unknown reason, I would like to commit the
> entire part and then in a seperate commit: remove the
> history/introduction. This method would allow myself, or another
> doc hacker to restore that information when the old version is
> dissolved.
I'm not really sure exactly which part you are talking about, but it's a
part that should be enabled later, perhaps it could just be committed
and "hidden" inside an SGML comment (<!-- -->)?
--- chapter.old Sat Aug 23 08:11:30 2003
+++ chapter.sgml Sat Aug 23 09:21:11 2003
@@ -1919,6 +1919,740 @@
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
</sect2>
</sect1>
+
+
+
+
+
+ <sect1 id="kerberos5">
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Tillman</firstname>
+ <surname>Hodgson</surname>
+ <contrib>Contributed by </contrib>
+ </author>
+ </authorgroup>
+ <authorgroup>
+ <author>
+ <firstname>Mark</firstname>
+ <surname>Murray</surname>
+ <contrib>Based on a contribution by </contrib>
+ </author>
+ </authorgroup>
+ </sect1info>
+
+ <title><application>Kerberos5</application></title>
+
+ <para>Every &os; release beyond &os;-5.1 includes support
+ only for <application>Kerberos5</application>. Hence
+ <application>Kerberos5</application> is the only version
+ included, and its configuration is similar in many aspects
The first sentence and the first part of the second sentence seems to
say the same?
Perhaps a note about KerberosIV being available as a port for FreeBSD
5.1? (I think the the port is security/krb4).
+ to that of <application>KerberosIV</application>. The following
+ information should only apply to
+ <application>Kerberos5</application> in post &os;-5.0
+ releases.</para>
+
+ <para><application>Kerberos</application> is a network add-on
+ system/protocol that allows users to authenticate themselves
+ through the services of a secure server. Services such as remote
+ login, remote copy, secure inter-system file copying and other
+ high-risk tasks are made considerably safer and more
+ controllable.</para>
+
+ <para><application>Kerberos</application> can be described as an
+ identity-verifying proxy system. It can also be described as a
+ trusted third-party authentication system.</para>
+
+ <para>Note that <application>Kerberos</application> provides only
+ authentication services and nothing more. Therefore it is highly
+ recommended that <application>Kerberos</application> be used with
+ other security methods which authorization and audit services.</para>
How about moving the note about what authorization and audit is to this
paragraph since this is the first time the distinction is mentioned.
+ <para>The following instructions can be used as a guide on how to set
+ up <application>Kerberos</application> as distributed for &os;.
+ However, you should refer to the relevant manual pages for a complete
+ description.</para>
+
+ <para>For purposes of demonstrating a <application>Kerberos</application>
+ installation, the various namespaceswill be handled as follows:</para>
+
+ <itemizedList>
+ <listitem>
+ <para>The DNS domain (<quote>zone</quote>) will be example.prv.</para>
Perhaps 'example.prv' should be marked up with <hostid
role="domainname"> ?
+ </listitem>
+
+ <listitem>
+ <para>The <application>Kerberos</application> realm will be
+ EXAMPLE.PRV.</para>
+ </listitem>
+ </itemizedList>
+
+ <para>Please refrain from the use of these namespaces in the real
+ world. Not only will it not be optimal for your network and
+ <acronym>DNS</acronym> server, it will make interoperating with other
+ <application>Kerberos</application> realms more difficult.</para>
+
+ <sect2>
+ <title>Background: History</title>
+
+ <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> provides only one
+ function -- the secure authentication of users on the network. It
+ does not provide authorization functions (what those users are
+ able to perform) or auditing fuctions (what those users did).
I meant these notes about authorization and auditing which I think
should be moved up in the document.
+ After a client and server have used
+ <application>Kerberos</application> to prove their identity, they
+ can also encrypt all of their communications to assure privacy
+ and data integrity as they go about their business.</para>
+
+ <para><application>Kerberos</application> is both the name of a
+ network authentication protocol and an adjective to describe
+ programs that implement the program
+ (<application>Kerberos</application> telnet, for example). The
+ current version of the protocol is version 5, described in
+ <acronym>RFC</acronym> 1510. <application>Kerberos</application>
+ was designed to provide strong authentication for client/server
+ applications (such as traditional Internet services like
+ <acronym>FTP</acronym> and telnet) by using secret-key
+ cryptography.</para>
+
+ <para>Several free implementations of this protocol are available,
+ covering a wide range of operating systems. The Massachusetts
+ Institute of Technology, where <application>Kerberos</application>
Perhaps insert ^ "(<acronym>MIT</acronym>)"
I think it's a good idea to introduce acronyms, so there is no doubt what
is meant when using them later.
+ was originally developed, continues to develop their
+ <application>Kerberos</application> package and it is commonly used
+ in the <acronym>US</acronym> (as a cryptography product, it has
+ historically been affected by <acronym>US</acronym> export
+ regulations). The <acronym>MIT</acronym>
+ <application>Kerberos</application> is available as a port
+ (<filename role="package">security/krb5</filename>). Heimdal
+ <application>Kerberos</application> is another version 5
+ implementation, and was explicitly developed outside of the
+ <acronym>US</acronym> to avoid export
+ regulations (and is thus often included in non-commercial Unix
+ variants). The Heimdal <application>Kerberos</application>
+ distribution is available as a port
+ (<filename role="package">security/heimdal</filename>), and a
+ minimal installation of it is included in the base &os;
+ install.</para>
+
+ <para>In order to reach the widest audience, these instructions assume
+ the use of the Heimdal distribution included in &os;.</para>
+
+ </sect2>
+
+ <sect2>
+ <title>Background: <application>KerberosIV</application> and
+ <application>Kerberos</application> 5</title>
+
+ <para>Older versions of <application>Kerberos</application> included both
+ <application>KerberosIV</application> (eBones) and
+ <application>Kerberos 5</application> (Heimdal). Support for
+ <application>KerberosIV</application> has been dropped as of &os;
+ 5.0.</para>
+
+ </sect2>
+
+ <sect2>
+ <title>Setting up a Heimdal <acronym>KDC</acronym></title>
+
+ <para>The <acronym>KDC</acronym>, or Key Distribution Center, is the
+ centralized authentication service that
+ <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 <acronym>Kerberos</acronym> realm, and thus
+ has heightened security concerns.</para>
+
+ <para>Note that while running the <application>Kerberos</application>
+ server requires very 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 your
+ <filename>/etc/rc.conf</filename> file contains the correct
+ settings to act as a <acronym>KDC</acronym> (you may need to adjust
+ paths to reflect your own system):</para>
+
+ <programlisting>Kerberos5_server_enable="YES"
+kadmind5_server_enable="YES"
+Kerberos_stash="YES"</programlisting>
+
+ <para>Next we'll set up your <application>Kerberos</application>
+ config file, <filename>/etc/krb5.conf</filename>:</para>
+
+ <programlisting>[libdefaults]
+ default_realm = EXAMPLE.PRV
+[realms]
+ EXAMPLE.PRV = {
+ kdc = <application>Kerberos</application>.example.prv
+ }
+[domain_realm]
+ .example.prv = EXAMPLE.PRV</programlisting>
+
+ <para>Note that this <filename>/etc/krb5.conf</filename> file implies
+ that your <acronym>KDC</acronym> will have the fully-qualified
+ hostname of <hostid>Kerberos.example.prv</hostid>. You will need
For <hostid> the role defaults to 'hostname', so I think role="fqdn"
should be added above.
+ to add a CNAME (alias) entry to your zone file to accomplish this
+ if your <acronym>KDC</acronym> has a different hostname.</para>
+
+ <para>Next we will create the <application>Kerberos</application>
+ database. The keys of all the principals are stored in this
+ database in encrypted form with a master password. You are not
+ required to remember this password, it will be stored in a file
+ (<filename>/var/heimdal/m-key</filename>). To create the master
+ key, run <command>kstash</command> and enter a password.</para>
+
+ <para>Once the master key has been created, you can initialize the
+ database using the <command>kadmin</command> program with the
Use &man.kadmin.8; ? (Since the manual page webinterface is broken for
crypto pages right now the link will probably be bogus at the moment,
but I think this will be fixed at some point).
+ <command>-l</command> option (standing for <quote>local</quote>).
<paramenter>-l</parameter> ?
+ This option instructs <command>kadmin</command> to modify the
+ database files directly rather than going through the
+ <command>kadmind</command> network service. This handles the
+ chicken-and-egg problem of trying to connect to the database
+ before it is created. Once you have the <literal>kadmin></literal>
Typo: ^
+ prompt, use the <command>init</command> command to create your
+ realms initial database.</para>
+
+ <para>Lastly, while still in <command>kadmin</command>, create your
+ first principal using the <command>add</command> command. Stick
+ to the defaults options for the principal for now, you can always
+ change them later with the <command>modify</command> command.
+ Note that you can use the <command>?</command> command at any
+ prompt to see the available options are.</para>
+
+ <para>A sample database creation session is shown below:</para>
How about marking up all occurrences of tillman with <replaceable> ?
I haven't tried it; it might look silly, I'm not really sure...
+
+ <programlisting>&prompt.root;kstash
+Master key: xxxxxxxx
+Verifying password - Master key: xxxxxxxx
+
+&prompt.root;kadmin -l
+kadmin> init EXAMPLE.PRV
+Realm max ticket life [unlimited]:
+kadmin> add tillman
+Max ticket life [unlimited]:
+Max renewable life [unlimited]:
+Attributes []:
+Password: xxxxxxxx
+Verifying password - Password: xxxxxxxx</programlisting>
+
+ <para>Now it's time to start up the <acronym>KDC</acronym> services.
+ Run <command>/etc/rc.d/Kerberos start</command> and
Typo ? ^
+ <command>/etc/rc.d/kadmind start</command> 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>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>KDC</acronym> itself:</para>
+
+ <programlisting>&prompt.user;k5init tillman
+tillman at EXAMPLE.PRV's Password:
+
+&prompt.user;k5list
+Credentials cache: FILE:/tmp/krb5cc_500
+ Principal: tillman at EXAMPLE.PRV
+
+ Issued Expires Principal
+Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV at EXAMPLE.PRV
+Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV at EXAMPLE.PRV
+
+v4-ticket file: /tmp/tkt500
+k5list: No ticket file (tf_util)</programlisting>
+
+ </sect2>
+
+ <sect2>
+ <title><application>Kerberos</application> enabling a server with
+ Heimdal services</title>
+
+ <para>First, we need a copy of the <application>Kerberos</application>
+ configuration file, <filename>/etc/krb5.conf</filename>. To do
+ so, simply copy it over to the client computer from the
+ <acronym>KDC</acronym> in a secure fashion (using the network,
+ such as <command>scp</command>, or physically via a
&man.scp.1; ?
+ floppy).</para>
+
+ <para>Next you need a <filename>/etc/krb5.keytab</filename> file.
+ This is the major difference between a server provide
+ <application>Kerberos</application> enabled daemons and a
+ workstation -- the server must have a keytab file. This file
+ contains the servers host key, which allows it and the
+ <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>FTP</acronym>, is a very bad idea.</para>
+
+ <para>Typically, you transfer to the keytab to the server using the
+ <command>kadmin</command> program. This is handy because you also
+ need to create the host principal (the <acronym>KDC</acronym> end
+ of the <filename>krb5.keytab</filename>) using
+ <command>kadmin</command>.</para>
+
+ <para>Note that you must have already obtained a ticket and that 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 the Heimdal info
+ pages (<command>info heimdal</command>) for details on designing
+ access control lists. If you do not want to enable remote
+ <command>kadmin</command> access, you can simply securely connect
+ to the <acronym>KDC</acronym> (via local console,
+ <command>ssh</command> or <application>Kerberos</application>
&man.ssh.1; ?
+ <command>telnet</command>) and perform administration locally
&man.telnet.1; ?
+ using <command>kadmin -l</command>.</para>
+
+ <para>After installing the <filename>/etc/krb5.conf</filename> file,
+ you can use <command>kadmin</command> from the
+ <application>Kerberos</application> server. The
+ <command>add --random-key</command> command will let you add the
+ servers host principal, and the <command>ext</command> command
+ will allow you to extract the servers host principal to its own
+ keytab. For example:</para>
+
+ <programlisting>&prompt.root;kadmin
+kadmin> add --random-key host/myserver.example.prv
+Max ticket life [unlimited]:
+Max renewable life [unlimited]:
+Attributes []:
+kadmin> ext host/myserver.example.prv
+kadmin> exit</programlisting>
+
+ <para>Note that the <command>ext</command> command (short for
+ <quote>extract</quote>) stores the extracted key in
+ <filename>/etc/krb5.keytab</filename> by default, which is
+ handy.</para>
+
+ <para>If you do not have <command>kadmind</command> running on the
+ <acronym>KDC</acronym> (possibly for security reasons) and thus
+ do not have access to <command>kadmin</command> remotely, you
+ can add the host principal
+ (<username>host/myserver.example.prv</username>) directly on the
+ <acronym>KDC</acronym> and then extract it to a temporary file
+ (to avoid over-writing the <filename>/etc/krb5.keytab</filename>
+ on the <acronym>KDC</acronym>) using something like this:</para>
+
+ <programlisting>&prompt.root;kadmin
+kadmin> ext --keytab=/tmp/example.keytab host/myserver.smithclan.prv
+kadmin> exit</programlisting>
+
+ <para>You can then securely copy the keytab to the server
+ computer (using <command>scp</command> or a floppy, for
+ example). Be sure to specify a non-default keytab name
+ to avoid over-writing the keytab on the
+ <acronym>KDC</acronym></para>
+
+ <para>At this point your server can communicate with the
+ <acronym>KDC</acronym> (due to it's <filename>krb5.conf</filename>
+ file) and it can prove it's own identity (due to the
+ <filename>krb5.keytab</filename> file). It's now ready for
+ you to enable some <application>Kerberos</application> services.
+ For this example we will enable the <command>telnet</command>
+ service by putting a line like this into your
+ <filename>/etc/inetd.conf</filename> and then restarting the
+ <command>inetd</command> service with
&man.inetd.1; ?
+ <command>/etc/rc.d inetd restart</command>:</para>
^
Missing /
+
+ <programlisting>telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user</programlisting>
+
+ <para>The critical bit is that the <command>-a</command>
+ (for authentication) type is set to user. Consult for the
+ <command>telnetd</command> man page for more details.</para>
+
+ </sect2>
+
+ <sect2>
+ <title><application>Kerberos</application> enabling a client with Heimdal</title>
+
+ <para>Setting up a client computer is almost trivially easy. As
+ far as <application>Kerberos</application> configuration goes,
+ you only need the <application>Kerberos</application>
+ configuration file, located at <filename>/etc/krb5.conf</filename>.
+ Simply securely copy it over to the client computer from the
+ <acronym>KDC</acronym>.</para>
+
+ <para>Test your client computer by attempting to use
+ <command>kinit</command>, <command>klist</command> and
+ <command>kdestroy</command> from the client to obtain, show, and
+ then delete a ticket for the principal you created above. You
+ should also be to use <application>Kerberos</application>
+ applications to connect to <application>Kerberos</application>
+ enabled servers, though if that doesn't work and obtaining a
+ ticket does the problem is likely with the server and not with
+ the client or the <acronym>KDC</acronym>.</para>
+
+ <para>When testing an application like <command>telnet</command>,
+ try using a packet sniffer (such as <command>tcpdump</command>)
&man.tcpdump.1;
+ to confirm that your password is not sent in the clear. Try
+ using <command>telnet</command> with the <command>-x</command>
^^
<parameter>-x</parameter>
+ option, which encrypts the entire data stream (similar to
+ <command>ssh</command>).</para>
+
+ <para>The core <application>Kerberos</application> client applications
+ (traditionally named <command>kinit</command>,
+ <command>klist</command>, <command>kdestroy</command> and
+ <command>kpasswd</command>) are installed in
Manual page references for the above commands?
+ the base &os; install. Note that &os; versions prior to 5.0
+ renamed them to <command>k5init</command>,
+ <command>k5list</command>, <command>k5destroy</command>,
+ <command>k5passwd</command>, and <command>kstash</command>
+ (though it's typically only used once).</para>
+
+ <para>Various non-core <application>Kerberos</application> client
+ applications are also installed by default. This is where the
+ <quote>minimal</quote> nature of the base Heimdal installation is
+ felt: <command>telnet</command> is the only
+ <application>Kerberos</application> enabled service.</para>
+
+ <para>The Heimdal port adds some of the missing client applications:
+ <application>Kerberos</application> enabled versions of
+ <command>ftp</command>, <command>rsh</command>,
+ <command>rcp</command>, <command>rlogin</command>, and a few
+ other less common programs. The <acronym>MIT</acronym> port also
+ contains a full suite of <application>Kerberos</application>
+ client applications.</para>
+
+ </sect2>
+
+ <sect2>
+ <title>User config file: .k5login and .k5users</title>
Perhaps <filename> for the above files? I don't know if that's normally
done in titles..
+
+ <para>Users within a realm typically have their
+ <application>Kerberos</application> principal (such as
+ <username>tillman at EXAMPLE.PRV</username>) mapped to a local
+ user account (such as a local account named
+ <username>tillman</username>). This well as the user account
+ usually does not have to be specified when using a client
+ application such as <command>telnet</command>.</para>
+
+ <para>Occasionally, however, you want to grant access to a local
+ user account to someone who does not have a matching
+ <application>Kerberos</application> principal. For example,
+ <username>tillman at EXAMPLE.PRV</username> may need access to the
+ local user account <username>webdevelopers</username>. Other
+ principals may also need access to that local account.</para>
+
+ <para>The <filename>.k5login</filename> and
+ <filename>.k5users</filename> files, placed in a users home
+ directory, can be used similar to a powerful combination of
+ <filename>.hosts</filename> and <command>sudo</command>, solving
+ this problem. For example, if a <filename>.k5login</filename>
+ with the following contents:</para>
+
+ <programlisting>tillman at EXAMPLE.PRV
+jdoe at EXAMPLE.PRV</programlisting>
+
+ <para>Were to be placed into the home directory of the local user
+ <username>webdevelopers</username> then both principals listed
+ would have access to that account without requiring a shared
+ password.</para>
+
+ <para>Reading the man pages for these commands is recommended.
+ Note that the <command>ksu</command> man page covers
Hmm, I don't have a ksu manual page.. Perhaps it's only in MIT Kerberos?
+ <filename>.k5users</filename>.</para>
+
+ </sect2>
+
+ <sect2>
+ <title>Troubleshooting</title>
+
+ <itemizedlist>
+ <listitem>
+ <para>When using either the Heimdal or <acronym>MIT</acronym>
+ <application>Kerberos</application> ports ensure that your
+ <literal>PATH</literal> environment variable lists the
I think this should be <envar>PATH</envar>
+ <application>Kerberos</application> versions of the client
+ applications before the system versions.</para>
+ </listitem>
+
+ <listitem>
+ <para>Is your time in sync? Are you sure? If the time is not in
+ sync (typically within five minutes) authentication often
+ fails.</para>
+ </listitem>
+
+ <listitem>
+ <para><acronym>MIT</acronym>and Heimdal interoperate nicely.
+ Except for <command>kadmin</command>, the protocol for
+ which is not standardized.</para>
+ </listitem>
+
+ <listitem>
+ <para>If you change your hostname, you also need to change your
+ <username>host/</username> principal and update your keytab.
+ This also applies to special keytab entries like the
+ <username>www/</username> principal used for Apache's
+ <application>mod_auth_kerb</application>.</para>
Perhaps a reference to the port www/mod_auth_kerb ?
+ </listitem>
+
+ <listitem>
+ <para>All hosts in your realm must be resolvable (both forwards
+ and reverse) in <acronym>DNS</acronym> (or
+ <filename>/etc/hosts</filename> 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:
+ <quote>KerberosV5 refuses authentication because Read req
+ failed: Key table entry not found</quote>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Some operating systems that may being acting as clients
+ to your <acronym>KDC</acronym> do not set the permissions
+ for <command>ksu</command> to be setuid
+ <username>root</username>. This means that
+ <command>ksu</command> does not work, which is a good
+ security idea but annoying. This is not a
+ <acronym>KDC</acronym> error.</para>
+ </listitem>
+
+ <listitem>
+ <para>With <acronym>MIT</acronym>
+ <application>Kerberos</application>, if you want to allow a
+ principal to have a ticket life longer than the default ten
+ hours, you must use <command>modify_prinicpal</command> in
+ <command>kadmin</command> to change the maxlife of both the
+ principal in question and the <username>krbtgt</username>
+ principal. Then the principal can use the
+ <option>-l</option> option with <command>kinit</command>
Hmm, here you use <option>... I don't really know when to use <option>
and when to use <parameter> (which I suggested earlier). Perhaps you
should also use <option> where I suggested <parameter>.
+ to request a ticket with a longer life.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>Note: If you run a packet sniffer on your
+ <acronym>KDC</acronym> to add in troubleshooting and then run
+ <command>kinit</command> from a workstation, you will notice
+ that your <acronym>TGT</acronym> is sent immediately upon
Hmm, I don't remeber TGT being mentioned before?
+ running <command>kinit</command> -- even before you type your
+ password! The explanation is that the
+ <application>Kerberos</application> server freely transmits a
+ <acronym>TGT</acronym> to any unauthorized request ... however,
+ every <acronym>TGT</acronym> is encrypted in a key derived from
+ the user's password. Therefore, when a user types their
+ password it is not being sent to the <acronym>KDC</acronym>,
+ it's being used to decrypt 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.
+ These credentials include a session key for establishing secure
+ communications with the <application>Kerberos</application>
+ server in the future, as well as the actual ticket-granting
+ ticket, which is actually encrypted with the
+ <application>Kerberos</application> server's own key. This
+ second layer of encryption is unknown to the user, but it's what
+ allows the <application>Kerberos</application> server to verify
+ the authenticity of each <acronym>TGT</acronym>.</para>
+
+ </sect2>
+
+ <sect2>
+ <title><application>Kerberos</application> Tips</title>
+
+ <itemizedlist>
+
+ <listitem>
+ <para>You have to keep the time in sync between all the
+ computers in your realm. <acronym>NTP</acronym> is
+ perfect for this.</para>
+ </listitem>
Perhaps a reference to section 19.11 which describes NTP.
+
+ <listitem>
+ <para>If you want to use long ticket lifetimes (a week, for
+ example) and you are using <application>OpenSSH</application>
+ to connect to the machine where your ticket is stored, make
+ sure that <application>Kerberos</application>
+ <option>TicketCleanup</option> is set to <literal>no</literal>
+ in your <filename>sshd_config</filename> or else your tickets
+ will be deleted when you log out.</para>
+ </listitem>
+
+ <listitem>
+ <para>Remember that host principals can have a longer ticket
+ life as well. If your user principal has a lifetime of a
+ week but the host you're connecting to has a lifetime of nine
+ hours, you will have an expired host principal in your cache
+ and the ticket cache will not work as expected.</para>
+ </listitem>
+
+ <listitem>
+ <para>When setting up a <filename>krb5.dict</filename> file to
+ prevent specific bad passwords from being used (the man page for
+ <command>kadmind</command> covers this briefly), remember that
+ it only applies to principals that have a password policy
+ assigned to them. The <filename>krb5.dict</filename> files
+ format is simple: one string per line. Creating a symlink to
+ <filename>/usr/share/dict/words</filename> might be
+ useful.</para>
+ </listitem>
+ </itemizedlist>
+
+ </sect2>
+
+ <sect2>
+ <title>Differences with the MIT port</title>
<acronym> around MIT here?
+
+ <para>The major differences between the <acronym>MIT</acronym>
+ and Heimdal installs relates to the <command>kadmin</command>
+ program which has a different (but equivalent) set of commands
+ and uses a different protocol. This has a large implications
+ if your <acronym>KDC</acronym> is <acronym>MIT</acronym> as you
+ will not be able to use the Heimdal <command>kadmin</command>
+ program to administer your <acronym>KDC</acronym> remotely
+ (or vice versa, for that matter).</para>
+
+ <para>The client applications may also take slightly different
+ command line options to accomplish the same tasks. Following
+ the instructions on the <acronym>MIT</acronym>
+ <application>Kerberos</application> web site (<ulink url="http://web.mit.edu/Kerberos/www/"></ulink>)
+ 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 may be run instead
+ of <acronym>MIT</acronym> if your <literal>PATH</literal>
<envar>PATH</envar>
+ environment variable lists the system directories first.</para>
+
+ <para>Important note: With the <acronym>MIT</acronym> krb5 port
+ that is provided by &os;, be sure and read the
+ <filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
+ file installed by the port if you want to understand why logins
+ via <command>telnetd</command> and <command>klogind</command>
+ behave somewhat oddly. Most importantly, 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 chown the forwarded
+ credentials.</para>
+
+ </sect2>
+
+ <sect2>
+ <title>Mitigating limitations found in <application>Kerberos</application></title>
+
+ <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 users credentials
+ could be stolen and re-used. An example of this would be
+ <application>Kerberos</application> enabling all remote shells
+ (via <command>rsh</command> and <command>telnet</command>, for
+ example) but not converting the <acronym>POP3</acronym> mail
+ server ... which sends passwords in plaintext.</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 the global
+ <filename>/tmp</filename> directory, which is readable by all
+ users. If a user is sharing a computer with several other
+ people simultaneously (i.e. multi-user), it is possible that
+ the user's tickets can be stolen (copied) by another
+ user.</para>
+
+ <para>This can be overcome with the <command>-c</command>
<option> or <parameter> for -c IMO.
+ filename command-line option or (preferably) the
+ <literal>KRB5CCNAME</literal> environment variable, but this
<envar>KRB5CCNAME</envar>
[END/no more comments]
Use at will..
--
Simon L. Nielsen
FreeBSD Documentation Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-doc/attachments/20030823/c71aae9a/attachment.sig>
More information about the freebsd-doc
mailing list