Date: Sat, 23 Aug 2003 17:23:22 +0200 From: "Simon L. Nielsen" <simon@FreeBSD.org> To: Tom Rhodes <trhodes@FreeBSD.org> Cc: freebsd-doc@FreeBSD.org Subject: Re: Kerberos5 chapter [was: Your message to freebsd-doc awaits moderator approval] Message-ID: <20030823152320.GC391@FreeBSD.org> In-Reply-To: <20030823094817.76e3b847.trhodes@FreeBSD.org> References: <mailman.0.1061646779.19958.freebsd-doc@freebsd.org> <20030823094817.76e3b847.trhodes@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: >=20 > 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=3D"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</applicati= on> + installation, the various namespaceswill be handled as follows:</par= a> + + <itemizedList> + <listitem> + <para>The DNS domain (<quote>zone</quote>) will be example.prv.</para> Perhaps 'example.prv' should be marked up with <hostid role=3D"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=3D"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=3D"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 b= oth + <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=3D"YES" +kadmind5_server_enable=3D"YES" +Kerberos_stash=3D"YES"</programlisting> + + <para>Next we'll set up your <application>Kerberos</application> + config file, <filename>/etc/krb5.conf</filename>:</para> + + <programlisting>[libdefaults] + default_realm =3D EXAMPLE.PRV +[realms] + EXAMPLE.PRV =3D { + kdc =3D <application>Kerberos</application>.example.prv + } +[domain_realm] + .example.prv =3D 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=3D"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@EXAMPLE.PRV's Password: + +&prompt.user;k5list +Credentials cache: FILE:/tmp/krb5cc_500 + Principal: tillman@EXAMPLE.PRV + + Issued Expires Principal +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV@EXAMPLE.PRV +Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.PRV@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=3D/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/te= lnetd 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@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@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@EXAMPLE.PRV +jdoe@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=3D"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.. --=20 Simon L. Nielsen FreeBSD Documentation Team --s2ZSL+KKDSLx8OML Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/R4boh9pcDSc1mlERAvFhAJsG/cSOMeexfKSFJ59CFqAJthuBBwCfVby1 EoJ8QRf4UjjLwMUh53RBuWQ= =9krn -----END PGP SIGNATURE----- --s2ZSL+KKDSLx8OML--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030823152320.GC391>