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.
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.
Kerberos is an optional component of FreeBSD. The easiest
way to install this software is by selecting the krb4
or
krb5
distribution in sysinstall
during the initial installation of FreeBSD. This will install
the "eBones" (KerberosIV) or "Heimdal" (Kerberos5)
implementation of Kerberos. These implementations are
included because they are developed outside the USA/Canada and
were thus available to system owners outside those countries
during the era of restrictive export controls on cryptographic
code from the USA.
Alternatively, the MIT implementation of Kerberos is available from the Ports Collection as security/krb5.
This is done on the Kerberos server only. First make sure that
you do not have any old Kerberos databases around. You should change
to the directory /etc/kerberosIV
and check that
only the following files are present:
#
cd /etc/kerberosIV
#
ls
README krb.conf krb.realms
If any additional files (such as principal.*
or master_key
) exist, then use the
kdb_destroy
command to destroy the old Kerberos
database, or if Kerberos is not running, simply delete the extra
files.
You should now edit the krb.conf
and
krb.realms
files to define your Kerberos realm.
In this case the realm will be EXAMPLE.COM
and the
server is grunt.example.com
. We edit
or create the krb.conf
file:
#
cat krb.conf
EXAMPLE.COM EXAMPLE.COM grunt.example.com admin server 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
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 center". The words admin
server
following a host's name means that host also
provides an administrative database server. For further explanation
of these terms, please consult the Kerberos manual pages.
Now we have to add grunt.example.com
to the EXAMPLE.COM
realm and also add an entry to
put all hosts in the .example.com
domain in the EXAMPLE.COM
realm. The
krb.realms
file would be updated as
follows:
#
cat krb.realms
grunt.example.com EXAMPLE.COM .example.com EXAMPLE.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU
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 specific 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 are ready to create the database. This only needs to run
on the Kerberos server (or Key Distribution Center). Issue the
kdb_init
command to do this:
#
kdb_init
Realm name [default ATHENA.MIT.EDU ]:
EXAMPLE.COM
You will be prompted for the database Master Password. It is important that you NOT FORGET this password.Enter Kerberos master key:
Now we have to save the key so that servers on the local machine
can pick it up. Use the kstash
command to do
this:
#
kstash
Enter Kerberos master key:
Current Kerberos master key version is 1. Master key entered. BEWARE!
This saves the encrypted master password in
/etc/kerberosIV/master_key
.
Two principals need to be added to the database for
each system that will be secured with Kerberos.
Their names are kpasswd
and rcmd
.
These two principals are made for each system, with the instance being
the name of the individual system.
These daemons, kpasswd and rcmd allow other systems to change Kerberos passwords and run commands like rcp(1), rlogin(1) and rsh(1).
Now let us add these entries:
#
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:
passwd
Instance:
grunt
<Not found>,Create [y] ?
y
Principal: passwd, Instance: grunt, kdc_key_ver: 1New Password:
<---- enter RANDOM here Verifying passwordNew Password:
<---- enter RANDOM hereRandom password [y] ?
y
Principal's new key version = 1Expiration 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: 1New Password:
<---- enter RANDOM here Verifying passwordNew Password:
<---- enter RANDOM hereRandom password [y] ?
Principal's new key version = 1Expiration 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
We now have to extract all the instances which define the
services on each machine. For this we use the
ext_srvtab
command. This will create a file
which must be copied or moved by secure
means 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.
#
ext_srvtab grunt
Enter Kerberos master key:
Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'....
Now, this command only generates a temporary file which must be
renamed to srvtab
so that all the servers can pick
it up. Use the mv(1) command to move it into place on
the original system:
#
mv grunt-new-srvtab srvtab
If the file is for a client system, and the network is not deemed
safe, then copy the
client-new-srvtab
to
removable media and transport it by secure physical means. Be sure to
rename it to srvtab
in the client's
/etc/kerberosIV
directory, and make sure it is
mode 600:
#
mv grumble-new-srvtab srvtab
#
chmod 600 srvtab
We now have to add some user entries into the database. First
let us create an entry for the user jane
. Use the
kdb_edit
command to do this:
#
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: 1New Password:
<---- enter a secure password here Verifying passwordNew Password:
<---- re-enter the password here Principal's new key version = 1Expiration 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
First we have to start the Kerberos daemons. Note that if you
have correctly edited your /etc/rc.conf
then this
will happen automatically when you reboot. This is only necessary on
the Kerberos server. Kerberos clients will automatically get what
they need from the /etc/kerberosIV
directory.
#
kerberos &
Kerberos server starting 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: EXAMPLE.COM#
kadmind -n &
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!
Now we can try using the kinit
command to get a
ticket for the ID jane
that we created
above:
%
kinit jane
MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane"Password:
Try listing the tokens using klist
to see if we
really have them:
%
klist
Ticket file: /tmp/tkt245 Principal: jane@EXAMPLE.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM
Now try changing the password using passwd(1) to check if the kpasswd daemon can get authorization to the Kerberos database:
%
passwd
realm EXAMPLE.COMOld password for jane:
New Password for jane:
Verifying passwordNew Password for jane:
Password changed.
Kerberos allows us to give each user
who needs root
privileges their own
separate su(1) password.
We could now add an ID which is authorized to
su(1) to root
. This is
controlled by having an instance of root
associated with a principal. Using kdb_edit
we can create the entry jane.root
in the
Kerberos database:
#
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:
root
<Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1New Password:
<---- enter a SECURE password here Verifying passwordNew Password:
<---- re-enter the password here Principal's new key version = 1Expiration 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
Now try getting tokens for it to make sure it works:
#
kinit jane.root
MIT Project Athena (grunt.example.com) Kerberos Initialization for "jane.root"Password:
Now we need to add the user to root
's
.klogin
file:
#
cat /root/.klogin
jane.root@EXAMPLE.COM
Now try doing the su(1):
%
su
Password:
and take a look at what tokens we have:
#
klist
Ticket file: /tmp/tkt_root_245 Principal: jane.root@EXAMPLE.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM
In an earlier example, we created a principal called
jane
with an instance root
.
This was based on a user with the same name as the principal, and this
is a Kerberos default; that a
<principal>.<instance>
of the form
<username>.
root
will allow
that <username>
to su(1) to
root
if the necessary entries are in the
.klogin
file in root
's
home directory:
#
cat /root/.klogin
jane.root@EXAMPLE.COM
Likewise, if a user has in their own home directory lines of the form:
%
cat ~/.klogin
jane@EXAMPLE.COM jack@EXAMPLE.COM
This allows anyone in the EXAMPLE.COM
realm
who has authenticated themselves as jane
or
jack
(via kinit
, see above)
to access to jane
's
account or files on this system (grunt
) via
rlogin(1), rsh(1) or
rcp(1).
For example, jane
now logs into another system using
Kerberos:
%
kinit
MIT Project Athena (grunt.example.com)Password:
%
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
Or jack
logs into jane
's account on the same machine
(jane
having
set up the .klogin
file as above, and the person
in charge of Kerberos having set up principal
jack with a null instance):
%
kinit
%
rlogin grunt -l jane
MIT Project Athena (grunt.example.com)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
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.