Update the kerberos section, add Mark Murray <mark@grondar.za> to
the authors section. Submitted by: Mark Murray <mark@grondar.za>
This commit is contained in:
John Fieber
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
|
|
@ -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>">
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
<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>
|
||||
|
||||
<p>Now we're ready to create the database, issue the
|
||||
<tt>kdb_init</tt> command to do this:
|
||||
<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.
|
||||
|
||||
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# kdb_init
|
||||
Realm name [default CS.BERKELEY.EDU ]: BSC.NO
|
||||
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>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.
|
||||
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>
|
||||
|
||||
<sect1>
|
||||
<heading>Populating the database</heading>
|
||||
<p>This saves the encrypted master password in
|
||||
<tt>/etc/kerberosIV/master_key</tt>.
|
||||
|
||||
<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:
|
||||
<sect1>
|
||||
<heading>Making it all run</heading>
|
||||
|
||||
<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,100 +191,59 @@ 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:
|
||||
<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>
|
||||
mideon# mv mideon-new-srvtab srvtab
|
||||
</verb></tscreen>
|
||||
grunt# mv grunt-new-srvtab srvtab
|
||||
</verb></tscreen>
|
||||
|
||||
<sect1>
|
||||
<heading>Testing it all out</heading>
|
||||
|
||||
<p>First we have to start the kerberos daemon:
|
||||
<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# kerberos &
|
||||
[1] 774
|
||||
mideon# Kerberos server starting
|
||||
Sleep forever on error
|
||||
Log file is /var/log/kerberos.log
|
||||
Current Kerberos master key version is 1.
|
||||
grumble# mv grumble-new-srvtab srvtab
|
||||
grumble# chmod 600 srvtab
|
||||
</verb></tscreen>
|
||||
|
||||
Master key entered. BEWARE!
|
||||
<sect1>
|
||||
<heading>Populating the database</heading>
|
||||
|
||||
Current Kerberos master key version is 1
|
||||
Local realm: BSC.NO
|
||||
</verb></tscreen>
|
||||
|
||||
Now we can try using the <tt>kinit</tt> command to get
|
||||
tokens for the id <it>md</it> that we created above:
|
||||
<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# kinit md
|
||||
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
|
||||
grunt# kdb_edit
|
||||
Opening database...
|
||||
|
||||
Enter Kerberos master key:
|
||||
|
|
@ -260,70 +254,227 @@ Master key entered. BEWARE!
|
|||
Previous or default values are in [brackets] ,
|
||||
enter return to leave the same, or new value.
|
||||
|
||||
Principal name: md
|
||||
Instance: root
|
||||
md.admin not found, Create [y] ?
|
||||
Principal: md, Instance: admin, kdc_key_ver: 1
|
||||
New Password:
|
||||
New Password:
|
||||
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 ] ? 12
|
||||
Max ticket lifetime (*5 minutes) [ 255 ] ?
|
||||
Attributes [ 0 ] ?
|
||||
Edit O.K.
|
||||
Principal name:
|
||||
</verb></tscreen>
|
||||
Principal name: <---- null entry here will cause an exit
|
||||
</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>
|
||||
mideon# kinit md.root
|
||||
Kerberos Initialization for "md.root"
|
||||
Kerberos Password:
|
||||
</verb></tscreen>
|
||||
grunt# kerberos &
|
||||
grunt# Kerberos server starting
|
||||
Sleep forever on error
|
||||
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>
|
||||
mideon# klist
|
||||
Ticket file: /tmp/tkt0
|
||||
Principal: md.root@BSC.NO
|
||||
grunt$ kinit jane
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
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
|
||||
Mar 23 21:08:47 Mar 23 22:08:47 krbtgt.BSC.NO@BSC.NO
|
||||
mideon#
|
||||
</verb></tscreen>
|
||||
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA
|
||||
</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>
|
||||
mideon# cat /root/.klogin
|
||||
md.root@BSC.NO
|
||||
</verb></tscreen>
|
||||
grunt$ passwd
|
||||
realm GRONDAR.ZA
|
||||
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>
|
||||
[md@mideon.bsc.no 10407] su
|
||||
Kerberos Password:
|
||||
Warning: tgt not verified.
|
||||
</verb></tscreen>
|
||||
grunt# kdb_edit
|
||||
Opening database...
|
||||
|
||||
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>
|
||||
mideon# klist
|
||||
Ticket file: /tmp/tkt_root_1250
|
||||
Principal: md.root@BSC.NO
|
||||
grunt# kinit jane.root
|
||||
MIT Project Athena (grunt.grondar.za)
|
||||
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
|
||||
Mar 23 22:09:59 Mar 23 22:19:59 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>
|
||||
|
||||
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.
|
||||
<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:
|
||||
|
||||
<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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue