Using MIT's Kerberos Server with AFS
This was posted by Joe Jackson of Transarc to the Info-AFS mailing list not
long ago. This isn't supported, as I recall. He provided this, and I do here,
merely as a convenience.
Using MIT's Kerberos Server with AFS
AFS Product Support
Transarc Corporation
Fourth Draft
February 7, 1994
This document describes how to replace the authentication functions of
the AFS kaserver with the MIT Kerberos V4 server. Please note that
this process is not supported by Transarc Corporation, but is provided
as a courtesy. Please read this document in its entirety before
proceeding with installation. Contact your Customer Support
Specialist if you have any questions or comments concerning this
document.
Issues
- Transarc recommends that you follow the AFS Installation Guide to
install AFS in the standard manner, starting the AFS kaserver when
appropriate. Once your cell has been set up with the kaserver in
place, you can then follow the directions below to replace the AFS
kaserver with the MIT Kerberos server.
- If your Kerberos realm name and AFS cell name do not match, you need
the AFS servers from version 3.3a or later. Earlier versions fail to
recognize the tokens granted from a differently named Kerberos realm.
(Note that Kerberos realm names are always uppercase and AFS cell
names are lowercase. Matching names are identical disregarding the
difference in case.)
- Once the MIT kerberos server is installed, don't use "klog" to
authenticate to AFS. Instead, use "kinit", providing your username
and password. Then use "aklog" to obtain an AFS token based on the
ticket-granting ticket created by "kinit".
Similarly, users will need the MIT version of "kpasswd" to change
their passwords. System administrators use "kadmin" instead of "kas"
to create and modify user accounts.
- If desired, you can run both the MIT kerberos server and the AFS
kaserver in parallel. Should you choose to do this, any changes made
in one database should be made in the other to keep them in sync. If
you choose to run only the MIT server, administration will be simpler
since you will have only a single database. Generally, there is no
need to run both servers.
- The kaserver emulates some features of the kerberos server by
responding to requests sent to the kerberos UDP port (750). If you
wish to run both servers on the same machine, start kerberos first so
it can begin listening to the port for requests. If you start
kerberos while the kaserver is running, the port will already be in
use and kerberos will fail immediately.
When you start the kaserver after kerberos, the kaserver will warn you
that it was not able to bind to the UDP port. This warning can be
ignored since the primary functions of the kaserver are serviced
through an Rx RPC port (7004). For example, the "klog" and "kas"
programs use Rx to communicate with the kaserver.
Tools
The procedure given below uses several standard commands provided with
AFS and with Kerberos. In additional, three special-purpose tools are
needed to complete the steps. You will have to obtain the sources for
these tools and compile them as outlined in this section.
- ext_srvtab
- The ext_srvtab command is supplied with the standard Kerberos
distribution, but a modified version is needed. The command takes
an instance name as an argument, checking to see if the name is
valid. Unfortunately, ext_srvtab doesn't think that the instance
"your\.cell\.name" is valid! Disable the bad check by changing
line 78 of ext_srvtab.c from:
if (!k_isinst(argv[i])) {
to:
if (0 && !k_isinst(argv[i])) {
The source file can be found in the "admin" subdirectory of the
Kerberos distribution. Once you make the change, recompile and
reinstall as usual.
- asetkey
- The asetkey command replaces the AFS "bos setkey" command. It
reads the "afs" key from the output of ext_srvtab and places it
into /usr/afs/etc/KeyFile. The sources can be obtained via AFS or
via anonymous FTP:
/afs/grand.central.org/pub/afs-contrib/tools/athena/ (AFS)
grand.central.org:/pub/afs-contrib/tools/athena/ (Anon FTP)
The Makefile will need to be modified to locate the AFS and
Kerberos libraries and include files.
- aklog
- The aklog command replaces the AFS klog command. Using the ticket-
granting ticket obtained with "kinit", it creates an AFS token.
The sources can be found in the same directory as for asetkey.
Steps
- Stop all the kaservers
- For each database server, issue:
% bos stop kaserver
- Make a kerberos entry for the principal named "afs" with the instance "your.cell.name"
- For example, at Stanford University the entry looks like:
afs.ir\.stanford\.edu@STANFORD.EDU
The backslashes on the dots before "stanford" and "edu" are needed
because the period is a delimiter between the principal name and
instance. Use either krb_edit or kadmin to create the entry.
Choose a long and secure password; you will not need to re-enter it.
Notice the key version number (kvno). It is probably 1.
- Use the ext_srvtab program you modified above to extract the afs key
- % ext_srvtab -n your.cell.name
Only the instance name is given on the command line. This will
create a file called your.cell.name-new-srvtab. This file holds
the value of your new afs "superuser" key.
- Put the afs key in /usr/afs/etc/KeyFile
- % asetkey add <kvno> <file> <principal>
The required arguments are:
- kvno
- version number of the key assigned in Step 2
- file
- your.cell.name-new-srvtab
- principal
- "afs.your\.cell\.name@YOUR.REALM" (quotes are needed)
Continuing the Stanford University example, the command would be:
asetkey add 1 ir.stanford.edu-new-srvtab "afs.ir\.stanford\.edu@STANFORD.EDU"
- Put the realm name in /usr/afs/etc/krb.conf
- The first line of this file is read to find the name of the
Kerberos realm that will issue AFS tokens for your cell. You can
simply create a symbolic link to /etc/krb.conf if you'd like. In
our example, the file would begin with:
STANFORD.EDU
- Deal with the AFS kaserver
- If you do not want to run the AFS kaserver in parallel, delete the kaserver instance on each database machine:
-
% bos delete -server -instance kaserver
- If you want to still run the AFS kaserver in parallel, restart the kaserver on each database machine:
-
% bos start -server -instance kaserver
Make sure that the key files on each fileserver machine match each
other and match the "afs" kaserver entry. The "upserver" and
"upclient" instances normally update /usr/afs/etc/KeyFile within
five minutes of a change.
For each file server, quickly issue these commands:
% bos setauth -server off
% bos listkeys -server
(look at the "ascii" string for the key you just added)
% bos setauth -server on
Assuming all the keys look the same, set the "afs" entry in the
kaserver to match the new key:
% kas setkey -name afs -new_key "" -kvno
Support
This is not at all supported by Transarc, or by me (and probably not by Joe either).
Derrick Brashear (shadow+@andrew.cmu.edu)
Last change: 4/29/94