freebsd-nq/share/doc/handbook/kerberos.sgml

481 lines
15 KiB
Plaintext
Raw Normal View History

<!-- $Id: kerberos.sgml,v 1.1.1.1 1995/04/28 16:19:59 jfieber Exp $ -->
1995-04-28 16:19:59 +00:00
<!-- The FreeBSD Documentation Project -->
<sect><heading>Kerberos</heading>
<p><em>Contributed by &a.mark; (based on contribution by &a.md;).</em>
1995-04-28 16:19:59 +00:00
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.
1995-04-28 16:19:59 +00:00
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.
1995-04-28 16:19:59 +00:00
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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt# cd /etc/kerberosIV
grunt# ls
README krb.conf krb.realms
</verb></tscreen>
1995-04-28 16:19:59 +00:00
<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>.
1995-04-28 16:19:59 +00:00
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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt# cat krb.conf
GRONDAR.ZA
GRONDAR.ZA grunt.grondar.za admin server
1995-04-28 16:19:59 +00:00
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.gov
</verb></tscreen>
<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.
1995-04-28 16:19:59 +00:00
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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
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
1995-04-28 16:19:59 +00:00
</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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt# kdb_init
Realm name [default ATHENA.MIT.EDU ]: GRONDAR.ZA
1995-04-28 16:19:59 +00:00
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:
</verb></tscreen>
1995-04-28 16:19:59 +00:00
<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.
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt# kstash
1995-04-28 16:19:59 +00:00
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
</verb></tscreen>
<p>This saves the encrypted master password in
<tt>/etc/kerberosIV/master_key</tt>.
1995-04-28 16:19:59 +00:00
<sect1>
<heading>Making it all run</heading>
1995-04-28 16:19:59 +00:00
<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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt# kdb_edit
1995-04-28 16:19:59 +00:00
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: passwd
Instance: grunt
1995-04-28 16:19:59 +00:00
<Not found>, Create [y] ? y
1995-04-28 16:19:59 +00:00
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- enter RANDOM here
Verifying password
1995-04-28 16:19:59 +00:00
New Password: <---- enter RANDOM here
Random password [y] ? y
1995-04-28 16:19:59 +00:00
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: rcmd
Instance: 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
1995-04-28 16:19:59 +00:00
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- null entry here will cause an exit
</verb></tscreen>
1995-04-28 16:19:59 +00:00
<sect1>
<heading>Creating the server file</heading>
1995-04-28 16:19:59 +00:00
<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.
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt# ext_srvtab grunt
1995-04-28 16:19:59 +00:00
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
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>
1995-04-28 16:19:59 +00:00
<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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grumble# mv grumble-new-srvtab srvtab
grumble# chmod 600 srvtab
</verb></tscreen>
1995-04-28 16:19:59 +00:00
<sect1>
<heading>Populating the database</heading>
1995-04-28 16:19:59 +00:00
<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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
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
1995-04-28 16:19:59 +00:00
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: 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
1995-04-28 16:19:59 +00:00
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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt$ kinit jane
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane"
Password:
</verb></tscreen>
1995-04-28 16:19:59 +00:00
<p>Try listing the tokens using <tt>klist</tt> to see if we really have them:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt$ klist
Ticket file: /tmp/tkt245
Principal: jane@GRONDAR.ZA
1995-04-28 16:19:59 +00:00
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.GRONDAR.ZA@GRONDAR.ZA
</verb></tscreen>
1995-04-28 16:19:59 +00:00
<p>Now try changing the password using <tt>passwd</tt> to check if the
kpasswd daemon can get authorisation to the Kerberos database:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
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:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt# kdb_edit
1995-04-28 16:19:59 +00:00
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
1995-04-28 16:19:59 +00:00
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
1995-04-28 16:19:59 +00:00
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!
1995-04-28 16:19:59 +00:00
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>
grunt# kinit jane.root
MIT Project Athena (grunt.grondar.za)
Kerberos Initialization for "jane.root"
Password:
</verb></tscreen>
1995-04-28 16:19:59 +00:00
<p>Now we need to add the user to root's <tt>.klogin</tt> file:
1995-04-28 16:19:59 +00:00
<tscreen><verb>
grunt# cat /root/.klogin
jane.root@GRONDAR.ZA
</verb></tscreen>
1995-04-28 16:19:59 +00:00
<p>Now try doing the <tt>su</tt>:
1995-04-28 16:19:59 +00:00
<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
1995-04-28 16:19:59 +00:00
Issued Expires Principal
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:
1995-04-28 16:19:59 +00:00
<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:
1995-04-28 16:19:59 +00:00
<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>.
1995-04-28 16:19:59 +00:00
For example, Jane now logs into another system, using Kerberos:
1995-04-28 16:19:59 +00:00
<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.
1995-04-28 16:19:59 +00:00
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:
1995-04-28 16:19:59 +00:00
<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.
1995-04-28 16:19:59 +00:00
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
[jane@grunt 10578]
</verb></tscreen>