os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Update the kerberos section, add Mark Murray <mark@grondar.za> to

Browse source 
the authors section.
Submitted by:	Mark Murray <mark@grondar.za>
This commit is contained in:
John Fieber 1995-05-11 22:31:28 +00:00
parent 58dc09bfde
commit 011e134c45
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=10
3 changed files with 366 additions and 214 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
handbook/authors.sgml
View file

@ -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 --> <!-- The FreeBSD Documentation Project -->
<!-- <!--
@ -6,15 +6,16 @@ Names and email address of contributing authors. Use these
entities when referencing people. entities when referencing people.
--> -->
<!ENTITY a.jkh "Jordan Hubbard <tt>&lt;jkh@FreeBSD.org&gt;</tt>"> <!ENTITY a.asami "Satoshi Asami <tt>&lt;asami@FreeBSD.org&gt;</tt>">
<!ENTITY a.jfieber "John Fieber <tt>&lt;jfieber@FreeBSD.org&gt;</tt>">
<!ENTITY a.phk "Poul-Henning Kamp <tt>&lt;phk@FreeBSD.org&gt;</tt>">
<!ENTITY a.gclarkii "Gary Clark II <tt>&lt;gclarkii@FreeBSD.org&gt;</tt>"> <!ENTITY a.gclarkii "Gary Clark II <tt>&lt;gclarkii@FreeBSD.org&gt;</tt>">
<!ENTITY a.gena "Gennady B. Sorokopud <tt>&lt;gena@NetVision.net.il&gt;</tt>"> <!ENTITY a.gena "Gennady B. Sorokopud <tt>&lt;gena@NetVision.net.il&gt;</tt>">
<!ENTITY a.ghelmer "Guy Helmer <tt>&lt;ghelmer@alpha.dsu.edu&gt;</tt>"> <!ENTITY a.ghelmer "Guy Helmer <tt>&lt;ghelmer@alpha.dsu.edu&gt;</tt>">
<!ENTITY a.md "Mark Dapoz <tt>&lt;md@bsc.no&gt;</tt>">
<!ENTITY a.martin "Martin Renters <tt>&lt;martin@innovus.com&gt;</tt>">
<!ENTITY a.gpalmer "Gary Palmer <tt>&lt;gpalmer@FreeBSD.org&gt;</tt>"> <!ENTITY a.gpalmer "Gary Palmer <tt>&lt;gpalmer@FreeBSD.org&gt;</tt>">
<!ENTITY a.jfieber "John Fieber <tt>&lt;jfieber@FreeBSD.org&gt;</tt>">
<!ENTITY a.jkh "Jordan Hubbard <tt>&lt;jkh@FreeBSD.org&gt;</tt>">
<!ENTITY a.john "John Lind <tt>&lt;john@starfire.MN.ORG&gt;</tt>"> <!ENTITY a.john "John Lind <tt>&lt;john@starfire.MN.ORG&gt;</tt>">
<!ENTITY a.asami "Satoshi Asami <tt>&lt;asami@FreeBSD.org&gt;</tt>"> <!ENTITY a.mark "Mark Murray <tt>&lt;mark@grondar.za&gt;</tt>">
<!ENTITY a.martin "Martin Renters <tt>&lt;martin@innovus.com&gt;</tt>">
<!ENTITY a.md "Mark Dapoz <tt>&lt;md@bsc.no&gt;</tt>">
<!ENTITY a.phk "Poul-Henning Kamp <tt>&lt;phk@FreeBSD.org&gt;</tt>">
<!ENTITY a.wilko "Wilko Bulte <tt>&lt;wilko@yedi.iaf.nl&gt;</tt>"> <!ENTITY a.wilko "Wilko Bulte <tt>&lt;wilko@yedi.iaf.nl&gt;</tt>">

4
handbook/handbook.sgml
View file

@ -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 --> <!-- The FreeBSD Documentation Project -->
<!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [ <!DOCTYPE linuxdoc PUBLIC "-//FreeBSD//DTD linuxdoc//EN" [
@ -54,7 +54,7 @@ OUTLINE:
<author> <author>
<name>The FreeBSD Documentation Project</name> <name>The FreeBSD Documentation Project</name>
</author> </author>
<date>May 6, 1995</date> <date>May 11, 1995</date>
<abstract>Welcome to FreeBSD! This handbook covers the <abstract>Welcome to FreeBSD! This handbook covers the
installation and day to day use of FreeBSD. installation and day to day use of FreeBSD.

561
handbook/kerberos.sgml
View file

@ -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 --> <!-- The FreeBSD Documentation Project -->
<sect><heading>Kerberos</heading> <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 Kerberos is a network add-on system/protocol that allows users to
guide on how to set up kerberos as distributed in 4.4 authenticate themselves through the services of a secure server.
BSD. However, you should refer to the original Athena Services such as remote login, remote copy, secure inter-system
documentation for a complete description. file copying and other high-risk tasks are made considerably safer
and more controllable.
<sect1> The following instructions can be used as a guide on how to
<heading>Creating the initial database</heading> 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 In FreeBSD, the Kerberos is not that from the original 4.4 BSD,
databases around. You should change to the directory distribution, but eBones, which had been previously ported to
<tt>/etc/kerberosIV</tt> and check that only the FreeBSD 1.1.5.1, and was sourced from outside the USA/Canada,
following files are present: 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> <tscreen><verb>
mideon# cd /etc/kerberosIV grunt# cd /etc/kerberosIV
mideon# ls grunt# ls
README krb.conf krb.realms register_keys README krb.conf krb.realms
</verb></tscreen> </verb></tscreen>
If any additional files (such as <tt>principal.dir</tt>) exist, <p>If any additional files (such as <tt>principal.*</tt> or
then use the <tt>kdb_destroy</tt> command to destroy the <tt>master_key</tt>) exist, then use the <tt>kdb_destroy</tt>
old kerberos database. 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 You should now edit the <tt>krb.conf</tt> and <tt>krb.realms</tt>
<tt>krb.realms</tt> files to define your kerberos realm. files to define your Kerberos realm. In this case the realm will
In this case the realm will be <it>BSC.NO</it> and the be <it>GRONDAR.ZA</it> and the server is <it>grunt.grondar.za</it>.
server is <it>mideon.bsc.no</it>. We would edit the We edit or create the <tt>krb.conf</tt> file:
<tt>krb.conf</tt> file to be as follows:
<tscreen><verb> <tscreen><verb>
mideon# cat krb.conf grunt# cat krb.conf
BSC.NO GRONDAR.ZA
BSC.NO mideon.bsc.no admin server GRONDAR.ZA grunt.grondar.za admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.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 LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.gov ARC.NASA.GOV trident.arc.nasa.gov
</verb></tscreen>
<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:
<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
</verb></tscreen> </verb></tscreen>
<p>Now we're ready to create the database, issue the <p>In this case, the other realms do not need to be there.
<tt>kdb_init</tt> command to do this: 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.
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> <tscreen><verb>
mideon# kdb_init grunt# cat krb.realms
Realm name [default CS.BERKELEY.EDU ]: BSC.NO 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>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>
grunt# kdb_init
Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA
You will be prompted for the database Master Password. You will be prompted for the database Master Password.
It is important that you NOT FORGET this password. It is important that you NOT FORGET this password.
Enter Kerberos master key: Enter Kerberos master key:
</verb></tscreen> </verb></tscreen>
<p>Now we have to save the key so that servers on the local <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 machine can pick it up. Use the <tt>kstash</tt> command to
do this. do this.
<tscreen><verb> <tscreen><verb>
mideon# kstash grunt# kstash
Enter Kerberos master key: Enter Kerberos master key:
Current Kerberos master key version is 1. Current Kerberos master key version is 1.
Master key entered. BEWARE! Master key entered. BEWARE!
</verb></tscreen> </verb></tscreen>
<sect1> <p>This saves the encrypted master password in
<heading>Populating the database</heading> <tt>/etc/kerberosIV/master_key</tt>.
<p>We now have to add some entries into the database. <sect1>
First lets create an entry for the user <it>md</it>. Use <heading>Making it all run</heading>
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> <tscreen><verb>
mideon# kdb_edit grunt# kdb_edit
Opening database... Opening database...
Enter Kerberos master key: Enter Kerberos master key:
@ -108,35 +155,18 @@ Master key entered. BEWARE!
Previous or default values are in [brackets] , Previous or default values are in [brackets] ,
enter return to leave the same, or new value. enter return to leave the same, or new value.
Principal name: md Principal name: passwd
Instance: Instance: grunt
md. not found, Create [y] ?
Principal: md, Instance: , kdc_key_ver: 1
New Password:
New Password:
Principal's new key version = 1 <Not found>, Create [y] ? y
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? 100
Attributes [ 0 ] ?
Edit O.K.
</verb></tscreen>
<p>Now lets add an entry for the password changing daemon, Principal: passwd, Instance: grunt, kdc_key_ver: 1
<tt>kpasswd</tt>. The principal name must be <it>kpasswd</it> and New Password: <---- enter RANDOM here
the instance must be the name of the local machine, Verifying password
<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.
<tscreen><verb> New Password: <---- enter RANDOM here
Principal name: kpasswd
Instance: mideon Random password [y] ? y
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] ?
Principal's new key version = 1 Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
@ -144,11 +174,16 @@ Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ? Attributes [ 0 ] ?
Edit O.K. Edit O.K.
Principal name: rcmd Principal name: rcmd
Instance: mideon Instance: grunt
rcmd.mideon not found, Create [y] ?
Principal: rcmd, Instance: mideon, kdc_key_ver: 1 <Not found>, Create [y] ?
New Password: <---- enter RANDOM here
New Password: <---- and here Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
New Password: <---- enter RANDOM here
Random password [y] ? Random password [y] ?
Principal's new key version = 1 Principal's new key version = 1
@ -156,100 +191,59 @@ Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ? Attributes [ 0 ] ?
Edit O.K. Edit O.K.
Principal name: <---- null entry here will cause an exit Principal name: <---- null entry here will cause an exit
</verb></tscreen> </verb></tscreen>
<sect1> <sect1>
<heading>Creating the server file</heading> <heading>Creating the server file</heading>
<p>We now have to extract all the instances which define <p>We now have to extract all the instances which define the services
the services on this machine. For this we use the on each machine. For this we use the <tt>ext_srvtab</tt> command.
<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> <tscreen><verb>
mideon# ext_srvtab mideon grunt# ext_srvtab grunt
Enter Kerberos master key: Enter Kerberos master key:
Current Kerberos master key version is 1. Current Kerberos master key version is 1.
Master key entered. BEWARE! Master key entered. BEWARE!
Generating 'mideon-new-srvtab'.... Generating 'grunt-new-srvtab'....
</verb></tscreen> </verb></tscreen>
<p>Now, this command only generates a temporary file <p>Now, this command only generates a temporary file
which must be renamed to <tt>srvtab</tt> so that all the 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 server can pick it up. Use the <tt>mv</tt> command to move it
into place: into place on the original system:
<tscreen><verb> <tscreen><verb>
mideon# mv mideon-new-srvtab srvtab grunt# mv grunt-new-srvtab srvtab
</verb></tscreen> </verb></tscreen>
<sect1> <p>If the file is for a client system, and the network is not
<heading>Testing it all out</heading> deemed safe, then copy the <tt>&lt;client&gt;-new-srvtab</tt> to
removeable media and transport it by secure physical means. Be
<p>First we have to start the kerberos daemon: 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> <tscreen><verb>
mideon# kerberos & grumble# mv grumble-new-srvtab srvtab
[1] 774 grumble# chmod 600 srvtab
mideon# Kerberos server starting </verb></tscreen>
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE! <sect1>
<heading>Populating the database</heading>
Current Kerberos master key version is 1 <p>We now have to add some user entries into the database.
Local realm: BSC.NO First lets create an entry for the user <it>jane</it>. Use
</verb></tscreen> the <tt>kdb_edit</tt> command to do this:
Now we can try using the <tt>kinit</tt> command to get
tokens for the id <it>md</it> that we created above:
<tscreen><verb> <tscreen><verb>
mideon# kinit md grunt# kdb_edit
Kerberos Initialization for "md"
Kerberos Password:
</verb></tscreen>
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
Issued Expires Principal
Mar 23 21:06:52 Mar 24 05:06:52 krbtgt.BSC.NO@BSC.NO
</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:
<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:
<tscreen><verb>
mideon# kdb_edit
Opening database... Opening database...
Enter Kerberos master key: Enter Kerberos master key:
@ -260,70 +254,227 @@ Master key entered. BEWARE!
Previous or default values are in [brackets] , Previous or default values are in [brackets] ,
enter return to leave the same, or new value. enter return to leave the same, or new value.
Principal name: md Principal name: jane
Instance: root Instance:
md.admin not found, Create [y] ?
Principal: md, Instance: admin, kdc_key_ver: 1 <Not found>, Create [y] ? y
New Password:
New Password: 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 Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ? Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ? Attributes [ 0 ] ?
Edit O.K. Edit O.K.
Principal name: Principal name: <---- null entry here will cause an exit
</verb></tscreen> </verb></tscreen>
Now try getting tokens for it to make sure it works: <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> <tscreen><verb>
mideon# kinit md.root grunt# kerberos &
Kerberos Initialization for "md.root" grunt# Kerberos server starting
Kerberos Password: Sleep forever on error
</verb></tscreen> Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
And list them to check expiry times: Master key entered. BEWARE!
Current Kerberos master key version is 1
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
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> <tscreen><verb>
mideon# klist grunt$ kinit jane
Ticket file: /tmp/tkt0 MIT Project Athena (grunt.grondar.za)
Principal: md.root@BSC.NO Kerberos Initialization for "jane"
Password:
</verb></tscreen>
<p>Try listing the tokens using <tt>klist</tt> to see if we really have them:
<tscreen><verb>
grunt$ klist
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
Issued Expires Principal Issued Expires Principal
Mar 23 21:08:47 Mar 23 22:08:47 krbtgt.BSC.NO@BSC.NO Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA
mideon# </verb></tscreen>
</verb></tscreen>
Now we need to add the user to root's <tt>.klogin</tt> file: <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> <tscreen><verb>
mideon# cat /root/.klogin grunt$ passwd
md.root@BSC.NO realm GRONDAR.ZA
</verb></tscreen> Old password for jane:
New Password for jane:
Verifying password
New Password for jane:
Password changed.
</verb></tscreen>
Now try doing the <tt>su</tt>: <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> <tscreen><verb>
[md@mideon.bsc.no 10407] su grunt# kdb_edit
Kerberos Password: Opening database...
Warning: tgt not verified.
</verb></tscreen>
and take a look at what tokens we have: 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: root
<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 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
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> <tscreen><verb>
mideon# klist grunt# kinit jane.root
Ticket file: /tmp/tkt_root_1250 MIT Project Athena (grunt.grondar.za)
Principal: md.root@BSC.NO Kerberos Initialization for "jane.root"
Password:
</verb></tscreen>
<p>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>Now try doing the <tt>su</tt>:
<tscreen><verb>
[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 Issued Expires Principal
Mar 23 22:09:59 Mar 23 22:19:59 krbtgt.BSC.NO@BSC.NO May 2 20:43:12 May 3 04:43:12 krbtgt.GRONDAR.ZA@GRONDAR.ZA
mideon# </verb></tscreen>
</verb></tscreen>
Notice that with this setup each user has their own entry <sect1>
for <tt>su</tt>'ing to root (the <it>user</it>.root entry <heading>Using other commands</heading>
in kerberos). This can allow you to give root access to
multiple users without the need to share a common root <p>In an earlier example, we created a principal called <tt>jane</tt>
password. 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>&lt;principal&gt;.&lt;instance&gt;</em> of the form
<em>&lt;username&gt;.</em><tt>root</tt> will allow that
<em>&lt;username&gt;</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:
<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>
[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>.
For example, Jane now logs into another system, using Kerberos:
<tscreen><verb>
[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.
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>
[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.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
[jane@grunt 10578]
</verb></tscreen>