diff --git a/handbook/authors.sgml b/handbook/authors.sgml index 336549c96b..c092cbc090 100644 --- a/handbook/authors.sgml +++ b/handbook/authors.sgml @@ -1,20 +1,21 @@ - + -<jkh@FreeBSD.org>"> -<jfieber@FreeBSD.org>"> -<phk@FreeBSD.org>"> +<asami@FreeBSD.org>"> <gclarkii@FreeBSD.org>"> <gena@NetVision.net.il>"> <ghelmer@alpha.dsu.edu>"> -<md@bsc.no>"> -<martin@innovus.com>"> <gpalmer@FreeBSD.org>"> +<jfieber@FreeBSD.org>"> +<jkh@FreeBSD.org>"> <john@starfire.MN.ORG>"> -<asami@FreeBSD.org>"> +<mark@grondar.za>"> +<martin@innovus.com>"> +<md@bsc.no>"> +<phk@FreeBSD.org>"> <wilko@yedi.iaf.nl>"> diff --git a/handbook/handbook.sgml b/handbook/handbook.sgml index c40bb74583..1083960ad7 100644 --- a/handbook/handbook.sgml +++ b/handbook/handbook.sgml @@ -1,200 +1,200 @@ - + %authors; ]> FreeBSD Handbook <author> <name>The FreeBSD Documentation Project</name> </author> - <date>May 6, 1995</date> + <date>May 11, 1995</date> <abstract>Welcome to FreeBSD! This handbook covers the installation and day to day use of FreeBSD. This manual is a <bf>work in progress</bf> and is the work of many individials. Many sections do not yet exist and some of those that do exist need to be updated. If you are interested in helping with this project, send email to &a.jfieber; or to the FreeBSD Documentantion Project mailing list <tt><doc@freebsd.org></tt>. </abstract> <toc> <!-- ************************************************************ --> <part><heading>Basics</heading> <chapt><heading>Introduction</heading> &nutshell; &history; <sect><heading>About this release</heading> <sect><heading>FreeBSD now and in the future</heading> <chapt><heading>Installing FreeBSD</heading> <sect><heading>Preparing for the installation</heading> <sect1><heading>Hardware checklist</heading> <sect2><heading>minimal requirements</heading> <sect2><heading>IRQs, IO Addresses, and DMA channels</heading> <sect1><heading>Software checklist</heading> <sect2><heading>Making the installation floppies</heading> <sect2><heading>CD-ROM</heading> <sect2><heading>Tape</heading> <sect2><heading>Disk</heading> <sect><heading>Installation</heading> <sect><heading>Set up a user account</heading> &basics; <chapt><heading>Installing applications</heading> <sect><heading>Installing packages</heading> &ports; &porting; <!-- ************************************************************ --> <part><heading>System Administration</heading> <chapt><heading>Reconfiguring the kernel</heading> <chapt><heading>Users, groups and security</heading> <sect><heading>DES, MD5 and Crypt</heading> &kerberos; <sect><heading>S/Key</heading> <sect><heading>Firewalls</heading> <chapt><heading>The X-Window System</heading> <chapt><heading>Printing</heading> <chapt><heading>Managing hardware</heading> &scsi; <sect><heading>adding/reconfiguring disks</heading> <sect><heading>tapes and backups</heading> <sect><heading>serial ports</heading> <sect><heading>sound cards</heading> <chapt><heading>PC Hardware compatibility</heading> <sect><heading>CORE/PROCESSING</heading> <sect1><heading>Motherboards</heading> <sect2><heading>ISA</heading> <sect2><heading>EISA</heading> <sect2><heading>VLB</heading> <sect2><heading>PCI</heading> <sect1><heading>CPUs/FPUs</heading> <sect1><heading>Memory</heading> <sect1><heading>BIOS</heading> <sect><heading>INPUT/OUTPUT</heading> <sect1><heading>Video cards</heading> <sect1><heading>Sound cards</heading> <sect1><heading>Serial ports (including multiport cards)</heading> <sect1><heading>Parallel ports</heading> <sect1><heading>Modems</heading> <sect1><heading>Etherenet cards</heading> <sect1><heading>Keyboards</heading> <sect1><heading>Mice</heading> <sect1><heading>Other (joysticks? tablets?)</heading> <sect><heading>STORAGE</heading> <sect1><heading>Disk/tape controllers</heading> <sect2><heading>SCSI</heading> <sect2><heading>IDE</heading> <sect2><heading>Floppy</heading> <sect1><heading>Hard drives</heading> <sect1><heading>Tape drives</heading> <sect1><heading>CD-ROM drives</heading> <sect1><heading>Other</heading> <sect><heading>OTHER</heading> <sect1><heading>PCMCIA</heading> <!-- ************************************************************ --> <part><heading>Network Communications</heading> <chapt><heading>Basic Networking</heading> <sect><heading>Ethernet basics</heading> <sect><heading>Serial basics</heading> <sect><heading>Hardwired Terminals</heading> &dialup; <chapt><heading>PPP and SLIP</heading> &ppp; &slipc; &slips; <chapt><heading>Advanced networking</heading> <sect><heading>Gateways and routing</heading> &nfs; <sect><heading>Yellow Pages/NIS</heading> &diskless; <sect><heading>ISDN</heading> <chapt><heading>Mail</heading> <!-- ************************************************************ --> <part><heading>Advanced topics</heading> &booting; ¤t; &ctm; ⊃ <chapt><heading>Kernel debugging</heading> &troubleshooting; &submitters; <part><heading>Additional resources</heading> &bibliography; &eresources; &glossary; </book> </linuxdoc> diff --git a/handbook/kerberos.sgml b/handbook/kerberos.sgml index 7eca30e497..bbe2dd5ff7 100644 --- a/handbook/kerberos.sgml +++ b/handbook/kerberos.sgml @@ -1,329 +1,480 @@ -<!-- $Id: kerberos.sgml,v 1.1.1.1 1995-04-28 16:19:59 jfieber Exp $ --> +<!-- $Id: kerberos.sgml,v 1.2 1995-05-11 22:31:28 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <sect><heading>Kerberos</heading> -<p><em>Contributed by &a.md;.</em> +<p><em>Contributed by &a.mark; (based on contribution by &a.md;).</em> - <p>The following instructions can be used as a quick - guide on how to set up kerberos as distributed in 4.4 - BSD. However, you should refer to the original Athena - documentation for a complete description. + Kerberos 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. - <sect1> - <heading>Creating the initial database</heading> + The following instructions can be used as a guide on how to + set up Kerberos as distributed for FreeBSD. However, you should refer + to the relevant manual pages for a complete description. - <p>First make sure that you don't have any old kerberos - databases around. You should change to the directory - <tt>/etc/kerberosIV</tt> and check that only the - following files are present: + In FreeBSD, the Kerberos is not that from the original 4.4 BSD, + distribution, but eBones, which had been previously ported to + FreeBSD 1.1.5.1, and was sourced from outside the USA/Canada, + and is thus available to system owners outside those countries. + + For those needing to get a legal foreign distribution of this + software, please <em>DO NOT</em> get it from a USA or Canada site. + You will get that site in <em>big</em> trouble! A legal copy of this is + available from <tt>skeleton.mikom.csir.co.za</tt>, which is in South + Africa. + + <sect1> + <heading>Creating the initial database</heading> + + <p>This is done on the Kerberos server only. First make sure that your + don't have any old Kerberos databases around. You should change to the + directory <tt>/etc/kerberosIV</tt> and check that only the following + files are present: <tscreen><verb> -mideon# cd /etc/kerberosIV -mideon# ls -README krb.conf krb.realms register_keys - </verb></tscreen> +grunt# cd /etc/kerberosIV +grunt# ls +README krb.conf krb.realms +</verb></tscreen> - If any additional files (such as <tt>principal.dir</tt>) exist, - then use the <tt>kdb_destroy</tt> command to destroy the - old kerberos database. + <p>If any additional files (such as <tt>principal.*</tt> or + <tt>master_key</tt>) exist, then use the <tt>kdb_destroy</tt> + command to destroy the old Kerberos database, of if Kerberos + is not running, simply delete the extra files with <tt>rm</tt>. - <p>You should now edit the <tt>krb.conf</tt> and - <tt>krb.realms</tt> files to define your kerberos realm. - In this case the realm will be <it>BSC.NO</it> and the - server is <it>mideon.bsc.no</it>. We would edit the - <tt>krb.conf</tt> file to be as follows: + You should now edit the <tt>krb.conf</tt> and <tt>krb.realms</tt> + files to define your Kerberos realm. In this case the realm will + be <it>GRONDAR.ZA</it> and the server is <it>grunt.grondar.za</it>. + We edit or create the <tt>krb.conf</tt> file: <tscreen><verb> -mideon# cat krb.conf -BSC.NO -BSC.NO mideon.bsc.no admin server +grunt# cat krb.conf +GRONDAR.ZA +GRONDAR.ZA grunt.grondar.za admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov - </verb></tscreen> +</verb></tscreen> + + <p>In this case, the other realms do not need to be there. + They are here as an example of how a machine may be made aware + of multiple realms. You may wish to not include them for simplicity. - <p>Now we have to add <it>mideon.bsc.no</it> to the - <it>BSC.NO</it> realm and also add an entry to put all - hosts in the <it>.bsc.no</it> domain in the - <it>BSC.NO</it> realm. The <tt>krb.realms</tt> file - would be updated as follows: + The first line names the realm in which this system works. The other + lines contain realm/host entries. The first item on a line is a realm, + and the second is a host in that realm that is acting as a ``key + distribution centre''. The words ``admin server'' following a hosts + name means that host also provides an administrative database server. + For further explanation of these terms, please consult the Kerberos + man pages. + + Now we have to add <it>grunt.grondar.za</it> to the <it>GRONDAR.ZA</it> + realm and also add an entry to put all hosts in the <it>.grondar.za</it> + domain in the <it>GRONDAR.ZA</it> realm. The <tt>krb.realms</tt> file + would be updated as follows: <tscreen><verb> - mideon# cat krb.realms - mideon.bsc.no BSC.NO - .bsc.no BSC.NO - .berkeley.edu CS.BERKELEY.EDU - .MIT.EDU ATHENA.MIT.EDU - .mit.edu ATHENA.MIT.EDU + grunt# cat krb.realms + grunt.grondar.za GRONDAR.ZA + .grondar.za GRONDAR.ZA + .berkeley.edu CS.BERKELEY.EDU + .MIT.EDU ATHENA.MIT.EDU + .mit.edu ATHENA.MIT.EDU </verb></tscreen> - <p>Now we're ready to create the database, issue the - <tt>kdb_init</tt> command to do this: + <p>Again, the other realms do not need to be there. + They are here as an example of how a machine may be made aware + of multiple realms. You may wish to remove them to simplify things. + + The first line puts the <it>specific</it> system into the named + realm. The rest of the lines show how to default systems of a + particular subdomain to a named realm. + + Now we're ready to create the database. This only needs to run on + the Kerberos server (or Key Distribution Centre). Issue the + <tt>kdb_init</tt> command to do this: <tscreen><verb> -mideon# kdb_init -Realm name [default CS.BERKELEY.EDU ]: BSC.NO +grunt# kdb_init +Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter Kerberos master key: - </verb></tscreen> +</verb></tscreen> - <p>Now we have to save the key so that servers on the local - machine can pick it up. Use the <tt>kstash</tt> command to - do this. + <p>Now we have to save the key so that servers on the local + machine can pick it up. Use the <tt>kstash</tt> command to + do this. <tscreen><verb> -mideon# kstash +grunt# kstash Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! - </verb></tscreen> +</verb></tscreen> + + <p>This saves the encrypted master password in + <tt>/etc/kerberosIV/master_key</tt>. - <sect1> - <heading>Populating the database</heading> + <sect1> + <heading>Making it all run</heading> - <p>We now have to add some entries into the database. - First lets create an entry for the user <it>md</it>. Use - the <tt>kdb_edit</tt> command to do this: + <p>Two principals need to be added to the database for <it>each</it> + system that will be secured with Kerberos. Their names are + <tt>kpasswd</tt> and <tt>rcmd</tt> These two principals are + made for each system, with the instance being the name of the + individual system. + + These daemons, <tt>kpasswd</tt> and <tt>rcmd</tt> allow other systems + to change Kerberos passwords and run commands like <tt>rcp</tt>, + <tt>rlogin</tt> and <tt>rsh</tt>. + + Now lets add these entries: <tscreen><verb> -mideon# kdb_edit +grunt# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. -Principal name: md -Instance: -md. not found, Create [y] ? -Principal: md, Instance: , kdc_key_ver: 1 -New Password: -New Password: +Principal name: passwd +Instance: grunt -Principal's new key version = 1 -Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? -Max ticket lifetime (*5 minutes) [ 255 ] ? 100 -Attributes [ 0 ] ? -Edit O.K. - </verb></tscreen> +<Not found>, Create [y] ? y - <p>Now lets add an entry for the password changing daemon, - <tt>kpasswd</tt>. The principal name must be <it>kpasswd</it> and - the instance must be the name of the local machine, - <it>mideon</it> in this case. Similarily, we must also - add an entry for the principal <it>rcmd</it> with an - instance equal to the hostname of the local machine. +Principal: passwd, Instance: grunt, kdc_key_ver: 1 +New Password: <---- enter RANDOM here +Verifying password -<tscreen><verb> -Principal name: kpasswd -Instance: mideon -kpasswd.mideon not found, Create [y] ? -Principal: kpasswd, Instance: mideon, kdc_key_ver: 1 -New Password: <---- enter RANDOM here -New Password: <---- and here -Random password [y] ? +New Password: <---- enter RANDOM here + +Random password [y] ? y Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. Principal name: rcmd -Instance: mideon -rcmd.mideon not found, Create [y] ? -Principal: rcmd, Instance: mideon, kdc_key_ver: 1 -New Password: <---- enter RANDOM here -New Password: <---- and here +Instance: grunt + +<Not found>, Create [y] ? + +Principal: rcmd, Instance: grunt, kdc_key_ver: 1 +New Password: <---- enter RANDOM here +Verifying password + +New Password: <---- enter RANDOM here + Random password [y] ? Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ? Attributes [ 0 ] ? Edit O.K. -Principal name: <---- null entry here will cause an exit - </verb></tscreen> +Principal name: <---- null entry here will cause an exit +</verb></tscreen> - <sect1> - <heading>Creating the server file</heading> + <sect1> + <heading>Creating the server file</heading> - <p>We now have to extract all the instances which define - the services on this machine. For this we use the - <tt>ext_srvtab</tt> command. + <p>We now have to extract all the instances which define the services + on each machine. For this we use the <tt>ext_srvtab</tt> command. + This will create a file which must be copied or moved <it>by secure + means</it> to each Kerberos client's /etc/kerberosIV directory. This + file must be present on each server and client, and is crucial to the + operation of Kerberos. <tscreen><verb> -mideon# ext_srvtab mideon +grunt# ext_srvtab grunt Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! -Generating 'mideon-new-srvtab'.... - </verb></tscreen> +Generating 'grunt-new-srvtab'.... +</verb></tscreen> + + <p>Now, this command only generates a temporary file + which must be renamed to <tt>srvtab</tt> so that all the + server can pick it up. Use the <tt>mv</tt> command to move it + into place on the original system: + +<tscreen><verb> +grunt# mv grunt-new-srvtab srvtab +</verb></tscreen> - <p>Now, this command only generates a temporary file - which must be renamed to <tt>srvtab</tt> so that all the - server can pick it up. Use the <tt>mv</tt> command to move it - into place: + <p>If the file is for a client system, and the network is not + deemed safe, then copy the <tt><client>-new-srvtab</tt> to + removeable media and transport it by secure physical means. Be + sure to rename it to <tt>srvtab</tt> in the client's + <tt>/etc/kerberosIV</tt> directory, and make sure it is mode 600: <tscreen><verb> -mideon# mv mideon-new-srvtab srvtab - </verb></tscreen> +grumble# mv grumble-new-srvtab srvtab +grumble# chmod 600 srvtab +</verb></tscreen> - <sect1> - <heading>Testing it all out</heading> + <sect1> + <heading>Populating the database</heading> - <p>First we have to start the kerberos daemon: + <p>We now have to add some user entries into the database. + First lets create an entry for the user <it>jane</it>. Use + the <tt>kdb_edit</tt> command to do this: <tscreen><verb> -mideon# kerberos & -[1] 774 -mideon# Kerberos server starting +grunt# kdb_edit +Opening database... + +Enter Kerberos master key: + +Current Kerberos master key version is 1. + +Master key entered. BEWARE! +Previous or default values are in [brackets] , +enter return to leave the same, or new value. + +Principal name: jane +Instance: + +<Not found>, Create [y] ? y + +Principal: jane, Instance: , kdc_key_ver: 1 +New Password: <---- enter a secure password here +Verifying password + +New Password: <---- re-enter the password here + +Principal's new key version = 1 +Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? +Max ticket lifetime (*5 minutes) [ 255 ] ? +Attributes [ 0 ] ? +Edit O.K. +Principal name: <---- null entry here will cause an exit +</verb></tscreen> + + <sect1> + <heading>Testing it all out</heading> + + <p>First we have to start the Kerberos daemons. NOTE that if you have + correctly edited your <tt>/etc/sysconfig</tt> then this will happen + automatically when you reboot. This is only necessary on the Kerberos + server. Kerberos clients will automagically get what they need from + the <tt>/etc/kerberosIV</tt> directory. + +<tscreen><verb> +grunt# kerberos & +grunt# Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 -Local realm: BSC.NO - </verb></tscreen> +Local realm: GRONDAR.ZA +grunt# kadmin -n & +grunt# KADM Server KADM0.0A initializing +Please do not use 'kill -9' to kill this job, use a +regular kill instead - Now we can try using the <tt>kinit</tt> command to get - tokens for the id <it>md</it> that we created above: +Current Kerberos master key version is 1. + +Master key entered. BEWARE! +</verb></tscreen> + + <p>Now we can try using the <tt>kinit</tt> command to get a ticket for + the id <it>jane</it> that we created above: <tscreen><verb> -mideon# kinit md -Kerberos Initialization for "md" -Kerberos Password: - </verb></tscreen> +grunt$ kinit jane +MIT Project Athena (grunt.grondar.za) +Kerberos Initialization for "jane" +Password: +</verb></tscreen> - Try listing the tokens using <tt>klist</tt> to see if we - really have them: + <p>Try listing the tokens using <tt>klist</tt> to see if we really have them: <tscreen><verb> -mideon# klist -Ticket file: /tmp/tkt0 -Principal: md@BSC.NO +grunt$ klist +Ticket file: /tmp/tkt245 +Principal: jane@GRONDAR.ZA Issued Expires Principal -Mar 23 21:06:52 Mar 24 05:06:52 krbtgt.BSC.NO@BSC.NO - </verb></tscreen> +Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA +</verb></tscreen> - And now try changing the password using <tt>passwd</tt> - to check if the kpasswd daemon can get authorisation to - the kerberos database: + <p>Now try changing the password using <tt>passwd</tt> to check if the + kpasswd daemon can get authorisation to the Kerberos database: <tscreen><verb> -mideon# passwd md -Changing Kerberos password for md.@BSC.NO. -Old Kerberos password: -New Kerberos password: -Retype new Kerberos password: -Update complete. - </verb></tscreen> - - <sect1> - <heading>Adding <tt>su</tt> priviledges</heading> - - <p>We should now add an id which is authorised to <tt>su</tt> to - <it>root</it>. This is controlled by having an instance of - <it>root</it> associated with a principal. Using - <tt>kdb_edit</tt> we can create the entry - <it>md.root</it> in the kerberos database: +grunt$ passwd +realm GRONDAR.ZA +Old password for jane: +New Password for jane: +Verifying password +New Password for jane: +Password changed. +</verb></tscreen> + + <sect1> + <heading>Adding <tt>su</tt> privileges</heading> + + <p>Kerberos allows us to give <it>each</it> user who needs root + privileges their own <it>separate</it> <tt>su</tt>password. We + could now add an id which is authorised to <tt>su</tt> to <it>root</it>. + This is controlled by having an instance of <it>root</it> associated + with a principal. Using <tt>kdb_edit</tt> we can create the entry + <it>jane.root</it> in the Kerberos database: <tscreen><verb> -mideon# kdb_edit +grunt# kdb_edit Opening database... Enter Kerberos master key: Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value. -Principal name: md +Principal name: jane Instance: root -md.admin not found, Create [y] ? -Principal: md, Instance: admin, kdc_key_ver: 1 -New Password: -New Password: + +<Not found>, Create [y] ? y + +Principal: jane, Instance: root, kdc_key_ver: 1 +New Password: <---- enter a SECURE password here +Verifying password + +New Password: <---- re-enter the password here Principal's new key version = 1 Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? -Max ticket lifetime (*5 minutes) [ 255 ] ? 12 +Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short! Attributes [ 0 ] ? Edit O.K. -Principal name: - </verb></tscreen> +Principal name: <---- null entry here will cause an exit +</verb></tscreen> + + <p>Now try getting tokens for it to make sure it works: + +<tscreen><verb> +grunt# kinit jane.root +MIT Project Athena (grunt.grondar.za) +Kerberos Initialization for "jane.root" +Password: + </verb></tscreen> - Now try getting tokens for it to make sure it works: + <p>Now we need to add the user to root's <tt>.klogin</tt> file: <tscreen><verb> -mideon# kinit md.root -Kerberos Initialization for "md.root" -Kerberos Password: - </verb></tscreen> +grunt# cat /root/.klogin +jane.root@GRONDAR.ZA +</verb></tscreen> - And list them to check expiry times: + <p>Now try doing the <tt>su</tt>: <tscreen><verb> -mideon# klist -Ticket file: /tmp/tkt0 -Principal: md.root@BSC.NO +[jane@grunt 10407] su +Password: +grunt# + </verb></tscreen> + + and take a look at what tokens we have: + +<tscreen><verb> +grunt# klist +Ticket file: /tmp/tkt_root_245 +Principal: jane.root@GRONDAR.ZA Issued Expires Principal -Mar 23 21:08:47 Mar 23 22:08:47 krbtgt.BSC.NO@BSC.NO -mideon# - </verb></tscreen> +May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA +</verb></tscreen> + + <sect1> + <heading>Using other commands</heading> + + <p>In an earlier example, we created a principal called <tt>jane</tt> + with an instance <tt>root</tt>. This was based on a user with the + same name as the principal, and this is a Kerberos default; that a + <em><principal>.<instance></em> of the form + <em><username>.</em><tt>root</tt> will allow that + <em><username></em> to <tt>su</tt> to root if the necessary + entries are in the <tt>.klogin</tt> file in <tt>root</tt>'s home + directory: - Now we need to add the user to root's <tt>.klogin</tt> file: +<tscreen><verb> +grunt# cat /root/.klogin +jane.root@GRONDAR.ZA +</verb></tscreen> + + <p>Likewise, if a user has in their own home directory lines of the + form: <tscreen><verb> -mideon# cat /root/.klogin -md.root@BSC.NO - </verb></tscreen> +[jane@grunt 10543] cat ~/.klogin +jane@GRONDAR.ZA +jack@GRONDAR.ZA +</verb></tscreen> + + <p>This allows anyone in the <em>GRONDAR.ZA</em> realm who has + authenticated themselves to <em>jane</em> or <em>jack</em> (via + <tt>kinit</tt>, see above) access to <tt>rlogin</tt> to <em>jane</em>'s + account or files on this system (<em>grunt</em>) via <tt>rlogin</tt>, + <tt>rsh</tt> or <tt>rcp</tt>. - Now try doing the <tt>su</tt>: + For example, Jane now logs into another system, using Kerberos: <tscreen><verb> -[md@mideon.bsc.no 10407] su -Kerberos Password: -Warning: tgt not verified. - </verb></tscreen> +[jane@grumble 573] kinit +MIT Project Athena (grunt.grondar.za) +Password: +[jane@grumble 574] rlogin grunt +Last login: Mon May 1 21:14:47 from grumble +Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 + The Regents of the University of California. All rights reserved. - and take a look at what tokens we have: +FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 + +[jane@grunt 10567] +</verb></tscreen> + + <p>Or Jack logs into Jane's account on the same machine (Jane having set up + the <tt>.klogin</tt> file as above, and the person in charge of Kerberos + having set up principal <em>jack</em> with a null instance: <tscreen><verb> -mideon# klist -Ticket file: /tmp/tkt_root_1250 -Principal: md.root@BSC.NO +[jack@grumble 573] kinit +[jack@grumble 574] rlogin grunt -l jane +MIT Project Athena (grunt.grondar.za) +Password: +Last login: Mon May 1 21:16:55 from grumble +Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 + The Regents of the University of California. All rights reserved. - Issued Expires Principal -Mar 23 22:09:59 Mar 23 22:19:59 krbtgt.BSC.NO@BSC.NO -mideon# - </verb></tscreen> - - Notice that with this setup each user has their own entry - for <tt>su</tt>'ing to root (the <it>user</it>.root entry - in kerberos). This can allow you to give root access to - multiple users without the need to share a common root - password. +FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995 + +[jane@grunt 10578] +</verb></tscreen>