aboutsummaryrefslogtreecommitdiff
path: root/handbook/kerberos.sgml
diff options
context:
space:
mode:
Diffstat (limited to 'handbook/kerberos.sgml')
-rw-r--r--handbook/kerberos.sgml523
1 files changed, 337 insertions, 186 deletions
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>&lt;client&gt;-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>&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:
- 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>