diff options
Diffstat (limited to 'handbook')
| -rw-r--r-- | handbook/authors.sgml | 15 | ||||
| -rw-r--r-- | handbook/handbook.sgml | 4 | ||||
| -rw-r--r-- | handbook/kerberos.sgml | 523 |
3 files changed, 347 insertions, 195 deletions
diff --git a/handbook/authors.sgml b/handbook/authors.sgml index 336549c96b..c092cbc090 100644 --- a/handbook/authors.sgml +++ b/handbook/authors.sgml @@ -1,4 +1,4 @@ -<!-- $Id: authors.sgml,v 1.1.1.1 1995-04-28 16:19:59 jfieber Exp $ --> +<!-- $Id: authors.sgml,v 1.2 1995-05-11 22:31:19 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <!-- @@ -6,15 +6,16 @@ Names and email address of contributing authors. Use these entities when referencing people. --> -<!ENTITY a.jkh "Jordan Hubbard <tt><jkh@FreeBSD.org></tt>"> -<!ENTITY a.jfieber "John Fieber <tt><jfieber@FreeBSD.org></tt>"> -<!ENTITY a.phk "Poul-Henning Kamp <tt><phk@FreeBSD.org></tt>"> +<!ENTITY a.asami "Satoshi Asami <tt><asami@FreeBSD.org></tt>"> <!ENTITY a.gclarkii "Gary Clark II <tt><gclarkii@FreeBSD.org></tt>"> <!ENTITY a.gena "Gennady B. Sorokopud <tt><gena@NetVision.net.il></tt>"> <!ENTITY a.ghelmer "Guy Helmer <tt><ghelmer@alpha.dsu.edu></tt>"> -<!ENTITY a.md "Mark Dapoz <tt><md@bsc.no></tt>"> -<!ENTITY a.martin "Martin Renters <tt><martin@innovus.com></tt>"> <!ENTITY a.gpalmer "Gary Palmer <tt><gpalmer@FreeBSD.org></tt>"> +<!ENTITY a.jfieber "John Fieber <tt><jfieber@FreeBSD.org></tt>"> +<!ENTITY a.jkh "Jordan Hubbard <tt><jkh@FreeBSD.org></tt>"> <!ENTITY a.john "John Lind <tt><john@starfire.MN.ORG></tt>"> -<!ENTITY a.asami "Satoshi Asami <tt><asami@FreeBSD.org></tt>"> +<!ENTITY a.mark "Mark Murray <tt><mark@grondar.za></tt>"> +<!ENTITY a.martin "Martin Renters <tt><martin@innovus.com></tt>"> +<!ENTITY a.md "Mark Dapoz <tt><md@bsc.no></tt>"> +<!ENTITY a.phk "Poul-Henning Kamp <tt><phk@FreeBSD.org></tt>"> <!ENTITY a.wilko "Wilko Bulte <tt><wilko@yedi.iaf.nl></tt>"> diff --git a/handbook/handbook.sgml b/handbook/handbook.sgml index c40bb74583..1083960ad7 100644 --- a/handbook/handbook.sgml +++ b/handbook/handbook.sgml @@ -1,4 +1,4 @@ -<!-- $Id: handbook.sgml,v 1.5 1995-05-11 02:03:33 jfieber Exp $ --> +<!-- $Id: handbook.sgml,v 1.6 1995-05-11 22:31:23 jfieber Exp $ --> <!-- The FreeBSD Documentation Project --> <!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [ @@ -54,7 +54,7 @@ OUTLINE: <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. diff --git a/handbook/kerberos.sgml b/handbook/kerberos.sgml index 7eca30e497..bbe2dd5ff7 100644 --- a/handbook/kerberos.sgml +++ b/handbook/kerberos.sgml @@ -1,43 +1,59 @@ -<!-- $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 @@ -46,58 +62,89 @@ 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: @@ -108,35 +155,18 @@ 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 ] ? @@ -144,11 +174,16 @@ 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 @@ -156,45 +191,100 @@ 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. @@ -202,54 +292,63 @@ 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: @@ -260,70 +359,122 @@ 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> |