mirror of
https://git.openafs.org/openafs.git
synced 2025-01-19 15:30:14 +00:00
832 lines
47 KiB
HTML
832 lines
47 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 4//EN">
|
||
|
|
<HTML><HEAD>
|
||
|
|
<TITLE>Administration Guide</TITLE>
|
||
|
|
<!-- Begin Header Records ========================================== -->
|
||
|
|
<!-- /tmp/idwt3570/auagd000.scr converted by idb2h R4.2 (359) ID -->
|
||
|
|
<!-- Workbench Version (AIX) on 2 Oct 2000 at 11:42:14 -->
|
||
|
|
<META HTTP-EQUIV="updated" CONTENT="Mon, 02 Oct 2000 11:42:13">
|
||
|
|
<META HTTP-EQUIV="review" CONTENT="Tue, 02 Oct 2001 11:42:13">
|
||
|
|
<META HTTP-EQUIV="expires" CONTENT="Wed, 02 Oct 2002 11:42:13">
|
||
|
|
</HEAD><BODY>
|
||
|
|
<!-- (C) IBM Corporation 2000. All Rights Reserved -->
|
||
|
|
<BODY bgcolor="ffffff">
|
||
|
|
<!-- End Header Records ============================================ -->
|
||
|
|
<A NAME="Top_Of_Page"></A>
|
||
|
|
<H1>Administration Guide</H1>
|
||
|
|
<HR><P ALIGN="center"> <A HREF="../index.htm"><IMG SRC="../books.gif" BORDER="0" ALT="[Return to Library]"></A> <A HREF="auagd002.htm#ToC"><IMG SRC="../toc.gif" BORDER="0" ALT="[Contents]"></A> <A HREF="auagd013.htm"><IMG SRC="../prev.gif" BORDER="0" ALT="[Previous Topic]"></A> <A HREF="#Bot_Of_Page"><IMG SRC="../bot.gif" BORDER="0" ALT="[Bottom of Topic]"></A> <A HREF="auagd015.htm"><IMG SRC="../next.gif" BORDER="0" ALT="[Next Topic]"></A> <A HREF="auagd026.htm#HDRINDEX"><IMG SRC="../index.gif" BORDER="0" ALT="[Index]"></A> <P>
|
||
|
|
<HR><H1><A NAME="HDRWQ355" HREF="auagd002.htm#ToC_409">Managing Server Encryption Keys</A></H1>
|
||
|
|
<P>This chapter explains how to maintain your cell's
|
||
|
|
server encryption keys, which are vital for secure communications in
|
||
|
|
AFS.
|
||
|
|
<HR><H2><A NAME="HDRWQ356" HREF="auagd002.htm#ToC_410">Summary of Instructions</A></H2>
|
||
|
|
<P>This chapter explains how to perform the following tasks by
|
||
|
|
using the indicated commands:
|
||
|
|
<BR>
|
||
|
|
<TABLE WIDTH="100%">
|
||
|
|
<TR>
|
||
|
|
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="70%">Add a new server encryption key
|
||
|
|
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="30%"><B>bos addkey</B> and <B>kas setpassword</B>
|
||
|
|
</TD></TR><TR>
|
||
|
|
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="70%">Inspect key checksums in the Authentication Database
|
||
|
|
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="30%"><B>kas examine</B>
|
||
|
|
</TD></TR><TR>
|
||
|
|
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="70%">Inspect key checksums in the <B>KeyFile</B>
|
||
|
|
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="30%"><B>bos listkeys</B>
|
||
|
|
</TD></TR><TR>
|
||
|
|
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="70%">Remove an old server encryption key
|
||
|
|
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="30%"><B>bos removekey</B>
|
||
|
|
</TD></TR></TABLE>
|
||
|
|
<HR><H2><A NAME="HDRWQ358" HREF="auagd002.htm#ToC_411">About Server Encryption Keys</A></H2>
|
||
|
|
<A NAME="IDX7246"></A>
|
||
|
|
<A NAME="IDX7247"></A>
|
||
|
|
<P>An <I>encryption key</I> is a string of octal numbers used to encrypt
|
||
|
|
and decrypt packets of information. In AFS, a <I>server encryption
|
||
|
|
key</I> is the key used to protect information being transferred between AFS
|
||
|
|
server processes and between them and their clients. A server
|
||
|
|
encryption key is essentially a password for a server process and like a user
|
||
|
|
password is stored in the Authentication Database.
|
||
|
|
<P>Maintaining your cell's server encryption keys properly is the most
|
||
|
|
basic way to protect the information in your AFS filespace from access by
|
||
|
|
unauthorized users.
|
||
|
|
<P><H3><A NAME="Header_412" HREF="auagd002.htm#ToC_412">Keys and Mutual Authentication: A Review</A></H3>
|
||
|
|
<A NAME="IDX7248"></A>
|
||
|
|
<A NAME="IDX7249"></A>
|
||
|
|
<A NAME="IDX7250"></A>
|
||
|
|
<A NAME="IDX7251"></A>
|
||
|
|
<A NAME="IDX7252"></A>
|
||
|
|
<A NAME="IDX7253"></A>
|
||
|
|
<P>Server encryption keys play a central role in the mutual authentication
|
||
|
|
between client and server processes in AFS. For a more detailed
|
||
|
|
description of mutual authentication, see <A HREF="auagd007.htm#HDRWQ75">A More Detailed Look at Mutual Authentication</A>.
|
||
|
|
<P>When a client wants to contact an AFS server, it first contacts the
|
||
|
|
<I>Ticket Granting Service</I> (TGS) module of the Authentication
|
||
|
|
Server. After verifying the client's identity (based indirectly on
|
||
|
|
the password of the human user whom the client represents), the TGS gives the
|
||
|
|
client a <I>server ticket</I>. This ticket is encrypted with the
|
||
|
|
server's encryption key. (The TGS also invents a second encryption
|
||
|
|
key, called the <I>session key</I>, to be used only for a single episode
|
||
|
|
of communication between server and client. The server ticket and
|
||
|
|
session key, together with other pieces of information, are collectively
|
||
|
|
referred to as a <I>token</I>.)
|
||
|
|
<P>The client cannot read the server ticket or token because it does not know
|
||
|
|
the server encryption key. However, the client sends it to the AFS
|
||
|
|
server along with service requests, because the ticket proves to the AFS
|
||
|
|
server processes that it has already authenticated with the TGS. AFS
|
||
|
|
servers trust the TGS to grant tickets only to valid clients. The fact
|
||
|
|
that the client possesses a ticket encrypted with the server's encryption
|
||
|
|
key proves to the server that the client is valid. On the other hand,
|
||
|
|
the client assumes that only a genuine AFS server knows the server encryption
|
||
|
|
key needed to decrypt the ticket. The server's ability to decrypt
|
||
|
|
the ticket and understand its contents proves to the client that the server is
|
||
|
|
legitimate.
|
||
|
|
<P><H3><A NAME="Header_413" HREF="auagd002.htm#ToC_413">Maintaining AFS Server Encryption Keys</A></H3>
|
||
|
|
<P>As you maintain your cell's server encryption keys, keep the
|
||
|
|
following in mind.
|
||
|
|
<UL>
|
||
|
|
<P><LI>Change the key frequently to enhance your cell's security.
|
||
|
|
Changing the key at least once a month is strongly recommended.
|
||
|
|
<A NAME="IDX7254"></A>
|
||
|
|
<P><LI>The AFS server encryption key currently in use is stored in two
|
||
|
|
places. When you add a new key, you must make changes in both places
|
||
|
|
and make them in the correct order, as instructed in <A HREF="#HDRWQ362">Adding Server Encryption Keys</A>. Failure to follow the instructions can seriously
|
||
|
|
impair cell functioning, as clients and servers become unable to
|
||
|
|
communicate. The two storage sites for the current server encryption
|
||
|
|
key are the following:
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI>The file <B>/usr/afs/etc/KeyFile</B> on the local disk of every file
|
||
|
|
server machine. The file can list more than one key, each with an
|
||
|
|
associated numerical identifier, the <I>key version number</I> or
|
||
|
|
<I>kvno</I>. A client token records the key version number of the
|
||
|
|
key used to seal it, and the server process retrieves the appropriate key from
|
||
|
|
this file when the client presents the token.
|
||
|
|
<A NAME="IDX7255"></A>
|
||
|
|
<A NAME="IDX7256"></A>
|
||
|
|
<A NAME="IDX7257"></A>
|
||
|
|
<A NAME="IDX7258"></A>
|
||
|
|
<A NAME="IDX7259"></A>
|
||
|
|
<P><LI>The <B>afs</B> entry in the Authentication Database. The
|
||
|
|
current server encryption key is in the entry's password field, just like
|
||
|
|
an individual user's scrambled password. The Authentication
|
||
|
|
Server's Ticket Granting Service (TGS) uses this key to encrypt the
|
||
|
|
tokens it gives to clients. There is only a single key in the entry,
|
||
|
|
because the TGS never needs to read existing tokens, but only to generate new
|
||
|
|
ones by using the current key.
|
||
|
|
<A NAME="IDX7260"></A>
|
||
|
|
<A NAME="IDX7261"></A>
|
||
|
|
<A NAME="IDX7262"></A>
|
||
|
|
</OL>
|
||
|
|
<P>For instructions on creating the initial <B>afs</B> entry and
|
||
|
|
<B>KeyFile</B> files as you install your cell's first server machine,
|
||
|
|
see the <I>IBM AFS Quick Beginnings</I>.
|
||
|
|
<P><LI>At any specific time, the tokens that the Authentication Server's
|
||
|
|
Ticket Granting Service gives to clients are sealed with only one of the
|
||
|
|
server encryption keys, namely the one stored in the <B>afs</B> entry in
|
||
|
|
the Authentication Database.
|
||
|
|
<P><LI>When you add a new server encryption key, you cannot immediately remove
|
||
|
|
the former key from the <B>/usr/afs/etc/KeyFile</B> file on the local disk
|
||
|
|
of every AFS server machine. Any time that you add a new key, it is
|
||
|
|
likely that some clients still have valid, unexpired tokens sealed with the
|
||
|
|
previous key. The more frequently you change the server encryption key,
|
||
|
|
the more such tickets there are likely to be. To be able to grant
|
||
|
|
service appropriately to clients with such tokens, an AFS server process must
|
||
|
|
still be able to access the server encryption key used to seal it.
|
||
|
|
<P>You can safely delete an old server encryption key only when it is certain
|
||
|
|
that no clients have tokens sealed with that key. In general, wait a
|
||
|
|
period of time at least as long as the maximum token lifetime in your
|
||
|
|
cell. By default, the maximum token lifetime for users is 25 hours
|
||
|
|
(except for users whose Authentication Database entries were created by using
|
||
|
|
the 3.0 version of AFS, for whom the default is 100 hours). You
|
||
|
|
can use the <B>-lifetime</B> argument to the <B>kas setfields</B>
|
||
|
|
command to change this default.
|
||
|
|
<P>Instructions for removing obsolete keys appear in <A HREF="#HDRWQ368">Removing Server Encryption Keys</A>.
|
||
|
|
<P><LI>You create a new AFS server encryption key in much the same way regular
|
||
|
|
users change their passwords, by providing a character string that is
|
||
|
|
converted into an encryption key automatically. See <A HREF="#HDRWQ362">Adding Server Encryption Keys</A>.
|
||
|
|
<A NAME="IDX7263"></A>
|
||
|
|
<P><LI>In addition to using server encryption keys when communicating with
|
||
|
|
clients, the server processes use them to protect communications with other
|
||
|
|
server processes. Therefore, all server machines in your cell must have
|
||
|
|
the same version of the <B>KeyFile</B> file. The easiest way to
|
||
|
|
maintain consistency (if you run the United States edition of AFS) is to use
|
||
|
|
the Update Server to distribute the contents of the system control
|
||
|
|
machine's <B>/usr/afs/etc</B> directory to all of the other server
|
||
|
|
machines. There are two implications:
|
||
|
|
<UL>
|
||
|
|
<P><LI>You must run the <B>upserver</B> process on the system control machine
|
||
|
|
and an <B>upclientetc</B> process on all other server machines that
|
||
|
|
references the system control machine. The <I>IBM AFS Quick
|
||
|
|
Beginnings</I> explains how to install both processes. For
|
||
|
|
instructions on verifying that the Update Server processes are running, see <A HREF="auagd009.htm#HDRWQ158">Displaying Process Status and Information from the BosConfig File</A>.
|
||
|
|
<A NAME="IDX7264"></A>
|
||
|
|
<P><LI>Change the <B>KeyFile</B> file only on the system control machine
|
||
|
|
(except in the types of emergencies discussed in <A HREF="#HDRWQ370">Handling Server Encryption Key Emergencies</A>). Any changes you make on other server machines are
|
||
|
|
overwritten the next time the <B>upclientetc</B> process retrieves the
|
||
|
|
contents of the system control machine's <B>/usr/afs/etc</B>
|
||
|
|
directory. By default, this happens every five minutes.
|
||
|
|
<A NAME="IDX7265"></A>
|
||
|
|
</UL>
|
||
|
|
<P>If you run the international edition of AFS, do not use the Update Server
|
||
|
|
to distribute the contents of the <B>/usr/afs/etc</B> directory,
|
||
|
|
particularly the <B>KeyFile</B> file. The data in the file is too
|
||
|
|
sensitive for transfer in unencrypted form, and because of United States
|
||
|
|
government exports regulations the international edition of AFS does not
|
||
|
|
include the necessary encryption routines in a form that the Update Server can
|
||
|
|
use. You must instead modify the file on each server machine
|
||
|
|
individually, taking care to enter the same key on every server
|
||
|
|
machine.
|
||
|
|
<P><LI>Never edit the <B>KeyFile</B> directly with a text editor.
|
||
|
|
Instead, always use the appropriate <B>bos</B> commands as instructed in <A HREF="#HDRWQ362">Adding Server Encryption Keys</A> and <A HREF="#HDRWQ368">Removing Server Encryption Keys</A>.
|
||
|
|
</UL>
|
||
|
|
<HR><H2><A NAME="HDRWQ359" HREF="auagd002.htm#ToC_414">Displaying Server Encryption Keys</A></H2>
|
||
|
|
<P>To display the server encryption keys in the
|
||
|
|
<B>/usr/afs/etc/KeyFile</B> file on any file server machine, use the
|
||
|
|
<B>bos listkeys</B> command. Use the <B>kas examine</B> command
|
||
|
|
to display the key in the Authentication Database's <B>afs</B>
|
||
|
|
entry.
|
||
|
|
<P>By default the commands do not display the actual string of octal digits
|
||
|
|
that constitute a key, but rather a <I>checksum</I>, a decimal number
|
||
|
|
derived by encrypting a constant with the key. This prevents
|
||
|
|
unauthorized users from easily accessing the actual key, which they can then
|
||
|
|
use to falsify or eavesdrop on protected communications.
|
||
|
|
<A NAME="IDX7266"></A>
|
||
|
|
<A NAME="IDX7267"></A>
|
||
|
|
The <B>bos listkeys</B> and <B>kas examine</B> commands generate the
|
||
|
|
same checksum for a given key, so displaying checksums rather than actual keys
|
||
|
|
is generally sufficient. If you suspect that the keys differ in a way
|
||
|
|
that the checksums are not revealing, then you are probably experiencing
|
||
|
|
authentication problems throughout your cell. The easiest solution is
|
||
|
|
to create a new server encryption key following the instructions in <A HREF="#HDRWQ362">Adding Server Encryption Keys</A> or <A HREF="#HDRWQ370">Handling Server Encryption Key Emergencies</A>. Another common reason to issue the
|
||
|
|
<B>bos listkeys</B> command is to display the key version numbers
|
||
|
|
currently in use, in preparation for choosing the next one; here, the
|
||
|
|
checksum is sufficient because the key itself is irrelevant.
|
||
|
|
<P>If it is important to display the actual octal digits, include the
|
||
|
|
<B>-showkey</B> argument to both the <B>bos listkeys</B> and <B>kas
|
||
|
|
examine</B> commands.
|
||
|
|
<A NAME="IDX7268"></A>
|
||
|
|
<A NAME="IDX7269"></A>
|
||
|
|
<A NAME="IDX7270"></A>
|
||
|
|
<A NAME="IDX7271"></A>
|
||
|
|
<A NAME="IDX7272"></A>
|
||
|
|
<A NAME="IDX7273"></A>
|
||
|
|
<P><H3><A NAME="HDRWQ360" HREF="auagd002.htm#ToC_415">To display the KeyFile file</A></H3>
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI>Verify that you are authenticated as a user listed in the
|
||
|
|
<B>/usr/afs/etc/UserList</B> file. If necessary, issue the <B>bos
|
||
|
|
listusers</B> command, which is fully described in <A HREF="auagd021.htm#HDRWQ593">To display the users in the UserList file</A>.
|
||
|
|
<PRE> % <B>bos listusers</B> <<VAR>machine name</VAR>>
|
||
|
|
</PRE>
|
||
|
|
<P><LI>Issue the <B>bos listkeys</B> command to display the contents of one
|
||
|
|
machine's <B>/usr/afs/etc/KeyFile</B> file.
|
||
|
|
<PRE> % <B>bos listkeys</B> <<VAR>machine name</VAR>> [<B>-showkey</B>]
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B>listk
|
||
|
|
</B><DD>Is the shortest acceptable abbreviation of <B>listkeys</B>.
|
||
|
|
<P><DT><B><VAR>machine name</VAR>
|
||
|
|
</B><DD>Names a file server machine. In the normal case, it is acceptable
|
||
|
|
to name any machine, because correct cell functioning requires that the
|
||
|
|
<B>KeyFile</B> file be the same on all of them.
|
||
|
|
<P><DT><B><B>-showkey</B>
|
||
|
|
</B><DD>Displays the octal digits that constitute each key.
|
||
|
|
</DL>
|
||
|
|
</OL>
|
||
|
|
<P>In the following example, the output displays a checksum for each server
|
||
|
|
encryption key rather than the actual octal digits. The penultimate
|
||
|
|
line indicates when an administrator last changed the file, and the final line
|
||
|
|
confirms that the output is complete.
|
||
|
|
<PRE> % <B>bos listkeys fs1.abc.com</B>
|
||
|
|
key 0 has cksum 972037177
|
||
|
|
key 1 has cksum 2825165022
|
||
|
|
Keys last changed on Wed Jan 13 11:20:29 1999.
|
||
|
|
All done.
|
||
|
|
</PRE>
|
||
|
|
<A NAME="IDX7274"></A>
|
||
|
|
<A NAME="IDX7275"></A>
|
||
|
|
<A NAME="IDX7276"></A>
|
||
|
|
<A NAME="IDX7277"></A>
|
||
|
|
<A NAME="IDX7278"></A>
|
||
|
|
<A NAME="IDX7279"></A>
|
||
|
|
<P><H3><A NAME="HDRWQ361" HREF="auagd002.htm#ToC_416">To display the afs key from the Authentication Database</A></H3>
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI>Issue the <B>kas examine</B> command to display the <B>afs</B>
|
||
|
|
entry in the Authentication Database.
|
||
|
|
<P>The Authentication Server performs its own authentication rather than
|
||
|
|
accepting your existing AFS token. By default, it authenticates your
|
||
|
|
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
|
||
|
|
administrator. Include the <B>-admin</B> argument to name an
|
||
|
|
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
|
||
|
|
entry. To verify that an entry has the flag, issue the <B>kas
|
||
|
|
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
|
||
|
|
<PRE> % <B>kas examine afs</B> [<B>-showkey</B>] \
|
||
|
|
<B>-admin</B> <<VAR>admin principal to use for authentication</VAR>>
|
||
|
|
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B><B>e</B>
|
||
|
|
</B><DD>Is the shortest acceptable abbreviation of <B>examine</B>.
|
||
|
|
<P><DT><B>afs
|
||
|
|
</B><DD>Designates the <B>afs</B> entry.
|
||
|
|
<P><DT><B><B>-showkey</B>
|
||
|
|
</B><DD>Displays the octal digits that constitute the key.
|
||
|
|
<P><DT><B>-admin
|
||
|
|
</B><DD>Names an administrative account with the <TT>ADMIN</TT> flag on its
|
||
|
|
Authentication Database entry, such as <B>admin</B>. The password
|
||
|
|
prompt echoes it as <VAR>admin_user</VAR>. Enter the appropriate password
|
||
|
|
as <VAR>admin_password</VAR>.
|
||
|
|
</DL>
|
||
|
|
</OL>
|
||
|
|
<P>In the following example, the <B>admin</B> user displays the
|
||
|
|
<B>afs</B> entry without using the <B>-showkey</B> flag. The
|
||
|
|
second line shows the key version number in parentheses and the key's
|
||
|
|
checksum. The line that begins with the string <TT>last mod</TT>
|
||
|
|
reports the date on which the indicated administrator changed the key.
|
||
|
|
There is no necessary relationship between this date and the date reported by
|
||
|
|
the <B>bos listkeys</B> command, because the latter date changes for any
|
||
|
|
type of change to the <B>KeyFile</B> file, not just a key addition.
|
||
|
|
For a description of the other lines in the output from the <B>kas
|
||
|
|
examine</B> command, see its reference page in the <I>IBM AFS
|
||
|
|
Administration Reference</I>.
|
||
|
|
<PRE> % <B>kas examine afs -admin admin</B>
|
||
|
|
Administrator's (admin) password: <VAR>admin_password</VAR>
|
||
|
|
User data for afs
|
||
|
|
key (1) cksum is 2825165022, last cpw: no date
|
||
|
|
password will never expire.
|
||
|
|
An unlimited number of unsuccessful authentications is permitted.
|
||
|
|
entry expires on never. Max ticket lifetime 100.00 hours.
|
||
|
|
last mod on Wed Jan 13 11:21:36 1999 by admin
|
||
|
|
permit password reuse
|
||
|
|
</PRE>
|
||
|
|
<HR><H2><A NAME="HDRWQ362" HREF="auagd002.htm#ToC_417">Adding Server Encryption Keys</A></H2>
|
||
|
|
<A NAME="IDX7280"></A>
|
||
|
|
<A NAME="IDX7281"></A>
|
||
|
|
<A NAME="IDX7282"></A>
|
||
|
|
<A NAME="IDX7283"></A>
|
||
|
|
<A NAME="IDX7284"></A>
|
||
|
|
<A NAME="IDX7285"></A>
|
||
|
|
<A NAME="IDX7286"></A>
|
||
|
|
<A NAME="IDX7287"></A>
|
||
|
|
<A NAME="IDX7288"></A>
|
||
|
|
<P>As noted, AFS records server encryption keys in two separate places:
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI>In the file <B>/usr/afs/etc/KeyFile</B> on the local disk of each
|
||
|
|
server machine, for use by the AFS server processes running on the machine
|
||
|
|
<P><LI>In the <B>afs</B> entry in the Authentication Database, for use by the
|
||
|
|
Ticket Granting Service (TGS) when creating tokens
|
||
|
|
</OL>
|
||
|
|
<P>To ensure that server processes and the TGS share the same AFS server
|
||
|
|
encryption key, execute all the steps in this section without
|
||
|
|
interruption.
|
||
|
|
<P>The following instructions include a step in which you restart the database
|
||
|
|
server processes (the Authentication, Backup, Protection, and Volume Location
|
||
|
|
Server processes) on all database server machines. As a database server
|
||
|
|
process starts, it reads in the server encryption key that has the highest key
|
||
|
|
version number in the <B>KeyFile</B> file and uses it to protect the
|
||
|
|
messages that it sends for synchronizing the database and maintaining
|
||
|
|
quorum. It uses the same key throughout its lifetime, which can be for
|
||
|
|
an extended period, even if you remove the key from the <B>KeyFile</B>
|
||
|
|
file. However, if one of the peer database server processes restarts
|
||
|
|
and the others do not, quorum and database synchronization break down because
|
||
|
|
the processes are no longer using the same key: the restarted process is
|
||
|
|
using the key that currently has the highest key version number, and the other
|
||
|
|
processes are still using the key they read in when they originally
|
||
|
|
started. To avoid this problem, it is safest to restart all of the
|
||
|
|
database server processes when adding a new key.
|
||
|
|
<P>After adding a new key, you can remove obsolete keys from the
|
||
|
|
<B>KeyFile</B> file to prevent it from becoming cluttered. However,
|
||
|
|
you must take care not to remove keys that client or server processes are
|
||
|
|
still using. For discussion and instructions, see <A HREF="#HDRWQ368">Removing Server Encryption Keys</A>.
|
||
|
|
<P><H3><A NAME="HDRWQ363" HREF="auagd002.htm#ToC_418">To add a new server encryption key</A></H3>
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI>Verify that you are authenticated as a user listed in the
|
||
|
|
<B>/usr/afs/etc/UserList</B> file. If necessary, issue the <B>bos
|
||
|
|
listusers</B> command, which is fully described in <A HREF="auagd021.htm#HDRWQ593">To display the users in the UserList file</A>.
|
||
|
|
<PRE> % <B>bos listusers</B> <<VAR>machine name</VAR>>
|
||
|
|
</PRE>
|
||
|
|
<P><LI><A NAME="LIWQ364"></A>Issue the <B>bos listkeys</B> command to display the key
|
||
|
|
version numbers that are already in use, as a first step in choosing the key
|
||
|
|
version number for the new key.
|
||
|
|
<PRE> % <B>bos listkeys</B> <<VAR>machine name</VAR>>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B>listk
|
||
|
|
</B><DD>Is the shortest acceptable abbreviation of <B>listkeys</B>.
|
||
|
|
<P><DT><B><VAR>machine name</VAR>
|
||
|
|
</B><DD>Names any file server machine.
|
||
|
|
</DL>
|
||
|
|
<P><LI><A NAME="LIWQ365"></A>Choose a key version number for the new key, based on the
|
||
|
|
output from Step <A HREF="#LIWQ364">2</A> and the following requirements:
|
||
|
|
<UL>
|
||
|
|
<P><LI>A key version number must be an integer between 0 (zero) and 255 to comply
|
||
|
|
with Kerberos standards. It is simplest if you keep your key version
|
||
|
|
numbers in sequence by choosing a key version number one greater than the
|
||
|
|
largest existing one.
|
||
|
|
<P><LI>Do not reuse a key version number currently found in the
|
||
|
|
<B>KeyFile</B> file, particularly if it is also the one in the
|
||
|
|
Authentication Database <B>afs</B> entry. Client processes possibly
|
||
|
|
still have tickets sealed with the key that originally had that key version
|
||
|
|
number, but the server processes start using the new key marked with that key
|
||
|
|
version number. Because the keys do not match, the server processes
|
||
|
|
refuse requests from clients who hold legitimate tokens.
|
||
|
|
</UL>
|
||
|
|
<A NAME="IDX7289"></A>
|
||
|
|
<A NAME="IDX7290"></A>
|
||
|
|
<P><LI><A NAME="LIWQ366"></A>Issue the <B>bos addkey</B> command to create a new AFS
|
||
|
|
server encryption key in the <B>KeyFile</B> file.
|
||
|
|
<P>If you run the United States edition of AFS and use the Update Server to
|
||
|
|
distribute the contents of the system control machine's
|
||
|
|
<B>/usr/afs/etc</B> directory, substitute the system control machine for
|
||
|
|
the <VAR>machine name</VAR> argument. (If you have forgotten which
|
||
|
|
machine is the system control machine, see <A HREF="auagd008.htm#HDRWQ96">To locate the system control machine</A>.)
|
||
|
|
<P>If you run the international edition of AFS or do not use the Update
|
||
|
|
Server, repeat the <B>bos addkey</B> command, substituting each server
|
||
|
|
machine in your cell for the <VAR>machine name</VAR> argument in turn.
|
||
|
|
<P>To avoid visible echoing of the string that corresponds to the new key,
|
||
|
|
omit the <B>-key</B> argument from the command line; instead enter
|
||
|
|
the string at the prompts that appear when you omit it, as shown in the
|
||
|
|
following syntax specification.
|
||
|
|
<PRE> % <B>bos addkey -server</B> <<VAR>machine name</VAR>> <B>-kvno</B> <<VAR>key version number</VAR>>
|
||
|
|
input key: <VAR>afs_password</VAR>
|
||
|
|
Retype input key: <VAR>afs_password</VAR>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B><B>addk</B>
|
||
|
|
</B><DD>Is the shortest acceptable abbreviation of <B>addkey</B>.
|
||
|
|
<P><DT><B>-server
|
||
|
|
</B><DD>Names the cell's system control machine if you are using the Update
|
||
|
|
Server, or each server machine in turn if you are not.
|
||
|
|
<P><DT><B>-kvno
|
||
|
|
</B><DD>Specifies the new key's key version number as an integer from the
|
||
|
|
range 0 (zero) through 255.
|
||
|
|
<P>Remember the number. You need to use it again in Step <A HREF="#LIWQ367">6</A>. If you are using the international edition of AFS,
|
||
|
|
be sure to type the same number each time you issue this command.
|
||
|
|
<P><DT><B><VAR>afs_password</VAR>
|
||
|
|
</B><DD>Is a character string similar to a user password, of any length from one
|
||
|
|
to about 1,000 characters. To improve security, include nonalphabetic
|
||
|
|
characters and make the string as long as is practical (you need to type it
|
||
|
|
only in this step and in Step <A HREF="#LIWQ367">6</A>). If you are using the international edition of AFS,
|
||
|
|
be sure to type the same string each time you issue this command.
|
||
|
|
<P>Do not enter an octal string directly. The BOS Server scrambles the
|
||
|
|
character string into an octal string appropriate for use as an encryption key
|
||
|
|
before recording it in the <B>KeyFile</B> file.
|
||
|
|
</DL>
|
||
|
|
<P><LI>If you are using the Update Server, wait for a few minutes while the
|
||
|
|
Update Server distributes the new <B>KeyFile</B> file to all server
|
||
|
|
machines. The maximum necessary waiting period is the largest value
|
||
|
|
provided for the <B>-t</B> argument to the <B>upclientetc</B>
|
||
|
|
process's initialization command used on any of the server machines;
|
||
|
|
the default time is five minutes.
|
||
|
|
<P>To be certain that all machines have the same <B>KeyFile</B> file,
|
||
|
|
issue the <B>bos listkeys</B> command for every file server machine and
|
||
|
|
verify that the checksum for the new key is the same on all machines.
|
||
|
|
<PRE> % <B>bos listkeys</B> <<VAR>machine name</VAR>>
|
||
|
|
</PRE>
|
||
|
|
<P>If you are not using the Update Server, try to complete Step <A HREF="#LIWQ366">4</A> within five minutes.
|
||
|
|
<A NAME="IDX7291"></A>
|
||
|
|
<A NAME="IDX7292"></A>
|
||
|
|
<P><LI><A NAME="LIWQ367"></A>Issue the <B>kas setpassword</B> command to enter the same
|
||
|
|
key in the <B>afs</B> entry in the Authentication Database.
|
||
|
|
<P>The Authentication Server performs its own authentication rather than
|
||
|
|
accepting your existing AFS token. By default, it authenticates your
|
||
|
|
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
|
||
|
|
administrator. Include the <B>-admin</B> argument to name an
|
||
|
|
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
|
||
|
|
entry. To verify that an entry has the flag, issue the <B>kas
|
||
|
|
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
|
||
|
|
<PRE> % <B>kas setpassword -name afs -kvno</B> <<VAR>kvno</VAR>> \
|
||
|
|
<B>-admin</B> <<VAR>admin principal to use for authentication</VAR>>
|
||
|
|
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
|
||
|
|
new_password: <VAR>afs_password</VAR>
|
||
|
|
Verifying, please re-enter new_password: <VAR>afs_password</VAR>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B><B>sp</B>
|
||
|
|
</B><DD>Is an acceptable alias for <B>setpassword</B> (<B>setp</B> is the
|
||
|
|
shortest acceptable abbreviation).
|
||
|
|
<P><DT><B>-name afs
|
||
|
|
</B><DD>Creates the new key in the <B>afs</B> entry.
|
||
|
|
<P><DT><B>-kvno
|
||
|
|
</B><DD>Specifies the same key version number as in Step <A HREF="#LIWQ366">4</A>.
|
||
|
|
<P><DT><B>-admin
|
||
|
|
</B><DD>Names an administrative account with the <TT>ADMIN</TT> flag on its
|
||
|
|
Authentication Database entry, such as <B>admin</B>. The password
|
||
|
|
prompt echoes it as <VAR>admin_user</VAR>. Enter the appropriate password
|
||
|
|
as <VAR>admin_password</VAR>.
|
||
|
|
<P><DT><B><VAR>afs_password</VAR>
|
||
|
|
</B><DD>Is the same character string you entered in Step <A HREF="#LIWQ366">4</A>.
|
||
|
|
</DL>
|
||
|
|
<P><LI><B>(Optional.)</B> If you want to verify that the keys you just
|
||
|
|
created in the <B>KeyFile</B> file and the Authentication Database
|
||
|
|
<B>afs</B> entry are identical and have the same key version number,
|
||
|
|
follow the instructions in <A HREF="#HDRWQ359">Displaying Server Encryption Keys</A>.
|
||
|
|
<P><LI>Issue the <B>bos restart</B> command to restart the database server
|
||
|
|
processes on all database server machines. This forces them to start
|
||
|
|
using the key in the <B>KeyFile</B> file that currently has the highest
|
||
|
|
key version number.
|
||
|
|
<P>Repeat this command in quick succession for each database server machine,
|
||
|
|
starting with the machine that has the lowest IP address.
|
||
|
|
<PRE> % <B>bos restart</B> <<VAR>machine name</VAR>> <B>buserver kaserver ptserver vlserver</B>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B><B>res</B>
|
||
|
|
</B><DD>Is the shortest acceptable abbreviation of <B>restart</B>.
|
||
|
|
<P><DT><B><VAR>machine name</VAR>
|
||
|
|
</B><DD>Names each database server machine in turn.
|
||
|
|
<P><DT><B>buserver kaserver ptserver vlserver
|
||
|
|
</B><DD>Designates the Backup Server, Authentication Server, Protection Server,
|
||
|
|
and Volume Location (VL) Server, respectively.
|
||
|
|
</DL>
|
||
|
|
</OL>
|
||
|
|
<HR><H2><A NAME="HDRWQ368" HREF="auagd002.htm#ToC_419">Removing Server Encryption Keys</A></H2>
|
||
|
|
<A NAME="IDX7293"></A>
|
||
|
|
<A NAME="IDX7294"></A>
|
||
|
|
<A NAME="IDX7295"></A>
|
||
|
|
<P>You can periodically remove old keys from the
|
||
|
|
<B>/usr/afs/etc/KeyFile</B> file to keep it to a reasonable size.
|
||
|
|
To avoid disturbing cell functioning, do not remove an old key until all
|
||
|
|
tokens sealed with the key and held by users or client processes have
|
||
|
|
expired. After adding a new key, wait to remove old keys at least as
|
||
|
|
long as the longest token lifetime you use in your cell. For
|
||
|
|
Authentication Database user entries created under AFS version 3.1 or
|
||
|
|
higher, the default token lifetime is 25 hours; for entries created under
|
||
|
|
AFS version 3.0, it is 100 hours.
|
||
|
|
<P>There is no command for removing the key from the <B>afs</B> entry in
|
||
|
|
the Authentication Database, because the key field in that entry must never be
|
||
|
|
empty. Use the <B>kas setpassword</B> command to replace the
|
||
|
|
<B>afs</B> key, but only as part of the complete procedure detailed in <A HREF="#HDRWQ363">To add a new server encryption key</A>.
|
||
|
|
<P>Never remove from the <B>KeyFile</B> file the key that is currently in
|
||
|
|
the <B>afs</B> entry in the Authentication Database. AFS server
|
||
|
|
processes become unable to decrypt the tickets that clients present to
|
||
|
|
them.
|
||
|
|
<P><H3><A NAME="HDRWQ369" HREF="auagd002.htm#ToC_420">To remove a key from the KeyFile file</A></H3>
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI>Verify that you are authenticated as a user listed in the
|
||
|
|
<B>/usr/afs/etc/UserList</B> file. If necessary, issue the <B>bos
|
||
|
|
listusers</B> command, which is fully described in <A HREF="auagd021.htm#HDRWQ593">To display the users in the UserList file</A>.
|
||
|
|
<PRE> % <B>bos listusers</B> <<VAR>machine name</VAR>>
|
||
|
|
</PRE>
|
||
|
|
<P><LI>Issue the <B>bos listkeys</B> command to display the key version
|
||
|
|
number of each key you want to remove. The output also reveals whether
|
||
|
|
it has been at least 25 hours since a new key was placed in the
|
||
|
|
<B>KeyFile</B> file. For complete instructions for the <B>bos
|
||
|
|
listkeys</B> command, see <A HREF="#HDRWQ360">To display the KeyFile file</A>.
|
||
|
|
<PRE> % <B>bos listkeys</B> <<VAR>machine name</VAR>>
|
||
|
|
</PRE>
|
||
|
|
<P><LI>Issue the <B>kas examine</B> command to verify that the key currently
|
||
|
|
in the Authentication Database's <B>afs</B> entry does not have the
|
||
|
|
same key version number as any of the keys you are removing from the
|
||
|
|
<B>KeyFile</B> file. For detailed instructions for the <B>kas
|
||
|
|
examine</B> command, see <A HREF="#HDRWQ361">To display the afs key from the Authentication Database</A>.
|
||
|
|
<PRE> % <B>kas examine afs -admin</B> <<VAR>admin principal to use for authentication</VAR>>
|
||
|
|
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
|
||
|
|
</PRE>
|
||
|
|
<A NAME="IDX7296"></A>
|
||
|
|
<A NAME="IDX7297"></A>
|
||
|
|
<P><LI>Issue the <B>bos removekey</B> command to remove one or more server
|
||
|
|
encryption keys from the <B>KeyFile</B> file.
|
||
|
|
<P>If you run the United States edition of AFS and use the Update Server to
|
||
|
|
distribute the contents of the system control machine's
|
||
|
|
<B>/usr/afs/etc</B> directory, substitute the system control machine for
|
||
|
|
the <VAR>machine name</VAR> argument. (If you have forgotten which
|
||
|
|
machine is the system control machine, see <A HREF="auagd008.htm#HDRWQ96">To locate the system control machine</A>.)
|
||
|
|
<P>If you run the international edition of AFS or do not use the Update
|
||
|
|
Server, repeat the <B>bos removekey</B> command, substituting each server
|
||
|
|
machine in your cell for the <VAR>machine name</VAR> argument in turn.
|
||
|
|
<PRE> % <B>bos removekey</B> <<VAR>machine name</VAR>> <<VAR>key version number</VAR>>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B><B>removek</B>
|
||
|
|
</B><DD>Is the shortest acceptable abbreviation of <B>removekey</B>.
|
||
|
|
<P><DT><B><VAR>machine name</VAR>
|
||
|
|
</B><DD>Names the cell's system control machine if you are using the Update
|
||
|
|
Server, or each server machine in turn if you are not.
|
||
|
|
<P><DT><B><VAR>key version number</VAR>
|
||
|
|
</B><DD>Specifies the key version number of each key to remove.
|
||
|
|
</DL>
|
||
|
|
</OL>
|
||
|
|
<HR><H2><A NAME="HDRWQ370" HREF="auagd002.htm#ToC_421">Handling Server Encryption Key Emergencies</A></H2>
|
||
|
|
<A NAME="IDX7298"></A>
|
||
|
|
<A NAME="IDX7299"></A>
|
||
|
|
<A NAME="IDX7300"></A>
|
||
|
|
<A NAME="IDX7301"></A>
|
||
|
|
<A NAME="IDX7302"></A>
|
||
|
|
<P>In rare circumstances, the AFS server processes can become unable to
|
||
|
|
decrypt the server tickets that clients or peer server processes are
|
||
|
|
presenting. Activity in your cell can come to a halt, because the
|
||
|
|
server processes believe that the tickets are forged or expired, and refuse to
|
||
|
|
execute any actions. This can happen on one machine or several;
|
||
|
|
the effect is more serious when more machines are involved.
|
||
|
|
<P>One common cause of server encryption key problems is that the
|
||
|
|
client's ticket is encrypted with a key that the server process does not
|
||
|
|
know. Usually this means that the <B>/usr/afs/etc/KeyFile</B> on
|
||
|
|
the server machine does not include the key in the <B>afs</B>
|
||
|
|
Authentication Database entry, which the Authentication Server's Ticket
|
||
|
|
Granting Service (TGS) module is using to encrypt server tickets.
|
||
|
|
<P>Another possibility is that the <B>KeyFile</B> files on different
|
||
|
|
machines do not contain the same keys. In this case, communications
|
||
|
|
among server processes themselves become impossible. For instance,
|
||
|
|
AFS's replicated database mechanism (Ubik) breaks down if the instances
|
||
|
|
of a database server process on the different database server machines are not
|
||
|
|
using the same key.
|
||
|
|
<P>The appearance of the following error message when you direct a
|
||
|
|
<B>bos</B> command to a file server machine in the local cell is one
|
||
|
|
possible symptom of server encryption key mismatch. (Note, however,
|
||
|
|
that you can also get this message if you forget to include the
|
||
|
|
<B>-cell</B> argument when directing the <B>bos</B> command to a file
|
||
|
|
server machine in a foreign cell.)
|
||
|
|
<PRE> bos: failed to contact host's bosserver (security object was passed a bad ticket).
|
||
|
|
</PRE>
|
||
|
|
<P>The solution to server encryption key emergencies is to put a new AFS
|
||
|
|
server encryption key in both the Authentication Database and the
|
||
|
|
<B>KeyFile</B> file on every server machine, so that the TGS and all
|
||
|
|
server processes again share the same key.
|
||
|
|
<P>Handling key emergencies requires some unusual actions. The reasons
|
||
|
|
for these actions are explained in the following sections; the actual
|
||
|
|
procedures appear in the subsequent instructions.
|
||
|
|
<P><H3><A NAME="HDRWQ371" HREF="auagd002.htm#ToC_422">Prevent Mutual Authentication</A></H3>
|
||
|
|
<P>It is necessary to prevent the server processes from trying
|
||
|
|
to mutually authenticate with you as you deal with a key emergency, because
|
||
|
|
they possibly cannot decrypt your token. When you do not mutually
|
||
|
|
authenticate, the server processes assign you the identity
|
||
|
|
<B>anonymous</B>. To prevent mutual authentication, use the
|
||
|
|
<B>unlog</B> command to discard your tokens and include the
|
||
|
|
<B>-noauth</B> flag on every command where it is available.
|
||
|
|
<P><H3><A NAME="Header_423" HREF="auagd002.htm#ToC_423">Disable Authorization Checking by Hand</A></H3>
|
||
|
|
<P>Because the server processes recognize you as the user
|
||
|
|
<B>anonymous</B> when you do not mutually authenticate, you must turn off
|
||
|
|
authorization checking. Only with authorization checking disabled do
|
||
|
|
the server processes allow the <B>anonymous</B> user to perform privileged
|
||
|
|
actions such as key creation.
|
||
|
|
<P>In an emergency, disable authorization checking by creating the file
|
||
|
|
<B>/usr/afs/local/NoAuth</B> by hand. In normal circumstances, use
|
||
|
|
the <B>bos setauth</B> command instead.
|
||
|
|
<P><H3><A NAME="Header_424" HREF="auagd002.htm#ToC_424">Work Quickly on Each Machine</A></H3>
|
||
|
|
<P>Disabling authorization checking is a serious security exposure,
|
||
|
|
because server processes on the affected machine perform any action for
|
||
|
|
anyone. Disable authorization checking only for as long as necessary,
|
||
|
|
completing all steps in an uninterrupted session and as quickly as
|
||
|
|
possible.
|
||
|
|
<P><H3><A NAME="Header_425" HREF="auagd002.htm#ToC_425">Work at the Console</A></H3>
|
||
|
|
<P>Working at the console of each server machine on which you disable
|
||
|
|
authorization checking ensures that no one else logs onto the console while
|
||
|
|
you are working there. It does not prevent others from connecting to
|
||
|
|
the machine remotely (using the <B>telnet</B> program, for example), which
|
||
|
|
is why it is important to work quickly. The only way to ensure complete
|
||
|
|
security is to disable network traffic, which is not a viable option in many
|
||
|
|
environments. You can improve security in general by limiting the
|
||
|
|
number of people who can connect remotely to your server machines at any time,
|
||
|
|
as recommended in <A HREF="auagd007.htm#HDRWQ74">Improving Security in Your Cell</A>.
|
||
|
|
<P><H3><A NAME="HDRWQ372" HREF="auagd002.htm#ToC_426">Change Individual KeyFile Files</A></H3>
|
||
|
|
<P>If you use the Update Server to distribute the contents of
|
||
|
|
the <B>/usr/afs/etc</B> directory, an emergency is the only time when it
|
||
|
|
is appropriate to change the <B>KeyFile</B> file on individual machines
|
||
|
|
instead. Updating each machine's file is necessary because
|
||
|
|
mismatched keys can prevent the system control machine's
|
||
|
|
<B>upserver</B> process from mutually authenticating with
|
||
|
|
<B>upclientetc</B> processes on other server machines, in which case the
|
||
|
|
<B>upserver</B> process refuses to distribute its <B>KeyFile</B> file
|
||
|
|
to them.
|
||
|
|
<P>Even if it appears that the Update Server is working correctly, the only
|
||
|
|
way to verify that is to change the key on the system control machine and wait
|
||
|
|
the standard delay period to see if the <B>upclientetc</B> processes
|
||
|
|
retrieve the key. During an emergency, it does not usually make sense
|
||
|
|
to wait the standard delay period. It is more efficient simply to
|
||
|
|
update the file on each server machine separately. Also, even if the
|
||
|
|
Update Server can distribute the file correctly, other processes can have
|
||
|
|
trouble because of mismatched keys. The following instructions add the
|
||
|
|
new key file on the system control machine first. If the Update Server
|
||
|
|
is working, then it is distributing the same change as you are making on each
|
||
|
|
server machine individually.
|
||
|
|
<P>If your cell does not use the Update Server, or uses the international
|
||
|
|
edition of AFS, you always change keys on server machines individually.
|
||
|
|
The following instructions are also appropriate for you.
|
||
|
|
<P><H3><A NAME="Header_427" HREF="auagd002.htm#ToC_427">Two Component Procedures</A></H3>
|
||
|
|
<P>There are two subprocedures used frequently in the following
|
||
|
|
instructions: disabling authorization checking and reenabling it.
|
||
|
|
For the sake of clarity, the procedures are detailed here; the
|
||
|
|
instructions refer to them as necessary.
|
||
|
|
<P><H4><A NAME="HDRWQ373">Disabling Authorization Checking in an Emergency</A></H4>
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI>Become the local superuser <B>root</B> on the machine, if you are not
|
||
|
|
already, by issuing the <B>su</B> command.
|
||
|
|
<PRE> % <B>su root</B>
|
||
|
|
Password: <VAR>root_password</VAR>
|
||
|
|
</PRE>
|
||
|
|
<A NAME="IDX7303"></A>
|
||
|
|
<P><LI><A NAME="LIWQ374"></A>Create the file <B>/usr/afs/local/NoAuth</B> to disable
|
||
|
|
authorization checking.
|
||
|
|
<PRE> # <B>touch /usr/afs/local/NoAuth</B>
|
||
|
|
</PRE>
|
||
|
|
<A NAME="IDX7304"></A>
|
||
|
|
<P><LI>Discard your tokens, in case they were sealed with an incompatible key,
|
||
|
|
which can prevent some commands from executing.
|
||
|
|
<PRE> # <B>unlog</B>
|
||
|
|
</PRE>
|
||
|
|
</OL>
|
||
|
|
<P><H4><A NAME="HDRWQ375">Reenabling Authorization Checking in an Emergency</A></H4>
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI>Become the local superuser <B>root</B> on the machine, if you are not
|
||
|
|
already, by issuing the <B>su</B> command.
|
||
|
|
<PRE> % <B>su root</B>
|
||
|
|
Password: <VAR>root_password</VAR>
|
||
|
|
</PRE>
|
||
|
|
<P><LI>Remove the <B>/usr/afs/local/NoAuth</B> file.
|
||
|
|
<PRE> # <B>rm /usr/afs/local/NoAuth</B>
|
||
|
|
</PRE>
|
||
|
|
<A NAME="IDX7305"></A>
|
||
|
|
<P><LI>Authenticate as an administrative identity that belongs to the
|
||
|
|
<B>system:administrators</B> group and is listed in the
|
||
|
|
<B>/usr/afs/etc/UserList</B> file.
|
||
|
|
<PRE> # <B>klog</B> <<VAR>admin_user</VAR>>
|
||
|
|
Password: <<VAR>admin_password</VAR>>
|
||
|
|
</PRE>
|
||
|
|
<P><LI>If appropriate, log out from the console (or close the remote connection
|
||
|
|
you are using), after issuing the <B>unlog</B> command to destroy your
|
||
|
|
tokens.
|
||
|
|
</OL>
|
||
|
|
<P><H3><A NAME="Header_430" HREF="auagd002.htm#ToC_430">To create a new server encryption key in emergencies</A></H3>
|
||
|
|
<OL TYPE=1>
|
||
|
|
<P><LI><A NAME="LIWQ376"></A><B>On the system control machine</B>, disable authorization
|
||
|
|
checking as instructed in <A HREF="#HDRWQ373">Disabling Authorization Checking in an Emergency</A>.
|
||
|
|
<P><LI><A NAME="LIWQ377"></A>Issue the <B>bos listkeys</B> command to display the key
|
||
|
|
version numbers already in use in the <B>KeyFile</B> file, as a first step
|
||
|
|
in choosing the new key's key version number.
|
||
|
|
<PRE> #<B> bos listkeys</B> <<VAR>machine name</VAR>> <B>-noauth</B>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B><B>listk</B>
|
||
|
|
</B><DD>Is the shortest acceptable abbreviation of <B>listkeys</B>.
|
||
|
|
<P><DT><B><VAR>machine name</VAR>
|
||
|
|
</B><DD>Specifies a file server machine.
|
||
|
|
<P><DT><B><B>-noauth</B>
|
||
|
|
</B><DD>Bypasses mutual authentication with the BOS Server. Include it in
|
||
|
|
case the key emergency is preventing successful mutual authentication.
|
||
|
|
</DL>
|
||
|
|
<P><LI><A NAME="LIWQ378"></A>Choose a key version number for the new key, based on what you
|
||
|
|
learned in Step <A HREF="#LIWQ377">2</A> plus the following requirements:
|
||
|
|
<UL>
|
||
|
|
<P><LI>It is best to keep your key version numbers in sequence by choosing a key
|
||
|
|
version number one greater than the largest existing one.
|
||
|
|
<P><LI>Key version numbers must be integers between 0 and 255 to comply with
|
||
|
|
Kerberos standards.
|
||
|
|
<P><LI>Do not reuse a key version number currently listed in the
|
||
|
|
<B>KeyFile</B> file.
|
||
|
|
</UL>
|
||
|
|
<A NAME="IDX7306"></A>
|
||
|
|
<P><LI><A NAME="LIWQ379"></A><B>On the system control machine</B>, issue the <B>bos
|
||
|
|
addkey</B> command to create a new AFS server encryption key in the
|
||
|
|
<B>KeyFile</B> file.
|
||
|
|
<PRE> # <B>bos addkey</B> <<VAR>machine name</VAR>> <B>-kvno</B> <<VAR>key version number</VAR>> <B>-noauth</B>
|
||
|
|
input key: <VAR>afs_password</VAR>
|
||
|
|
Retype input key: <VAR>afs_password</VAR>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B><B>addk</B>
|
||
|
|
</B><DD>Is the shortest acceptable abbreviation of <B>addkey</B>.
|
||
|
|
<P><DT><B><VAR>machine name</VAR>
|
||
|
|
</B><DD>Names the file server machine on which to define the new key in the
|
||
|
|
<B>KeyFile</B> file.
|
||
|
|
<P><DT><B>-kvno
|
||
|
|
</B><DD>Specifies the key version number you chose in Step <A HREF="#LIWQ378">3</A>, an integer in the range 0 (zero) through 255. You
|
||
|
|
must specify the same number in Steps <A HREF="#LIWQ382">7</A>, <A HREF="#LIWQ383">8</A>, and <A HREF="#LIWQ386">13</A>.
|
||
|
|
<P><DT><B><B>-noauth</B>
|
||
|
|
</B><DD>Bypasses mutual authentication with the BOS Server. Include it in
|
||
|
|
case the key emergency is preventing successful mutual authentication.
|
||
|
|
<P><DT><B><VAR>afs_password</VAR>
|
||
|
|
</B><DD>Is a character string similar to a user password, of any length from one
|
||
|
|
to about 1,000 characters. To improve security, make the string as long
|
||
|
|
as is practical, and include nonalphabetic characters.
|
||
|
|
<P>Do not type an octal string directly. The BOS Server scrambles the
|
||
|
|
character string into an octal string appropriate for use as an encryption key
|
||
|
|
before recording it in the <B>KeyFile</B> file.
|
||
|
|
<P>Remember the string. You need to use it again in Steps <A HREF="#LIWQ382">7</A>, <A HREF="#LIWQ383">8</A>, and <A HREF="#LIWQ386">13</A>.
|
||
|
|
</DL>
|
||
|
|
<P><LI><A NAME="LIWQ380"></A><B>On every database server machine in your cell</B> (other
|
||
|
|
than the system control machine), disable authorization checking as instructed
|
||
|
|
in <A HREF="#HDRWQ373">Disabling Authorization Checking in an Emergency</A>. Do not repeat the procedure on the system control
|
||
|
|
machine, if it is a database server machine, because you already disabled
|
||
|
|
authorization checking in Step <A HREF="#LIWQ376">1</A>. (If you need to learn which machines are database
|
||
|
|
server machines, use the <B>bos listhosts</B> command as described in <A HREF="auagd008.htm#HDRWQ95">To locate database server machines</A>.)
|
||
|
|
<P><LI><A NAME="LIWQ381"></A>Wait at least 90 seconds after finishing Step <A HREF="#LIWQ380">5</A>, to allow each of the database server processes (the
|
||
|
|
Authentication, Backup, Protection and Volume Location Servers) to finish
|
||
|
|
electing a new sync site. Then issue the <B>udebug</B> command to
|
||
|
|
verify that the election worked properly. Issue the following commands,
|
||
|
|
substituting each database server machine's name for <VAR>server
|
||
|
|
machine</VAR> in turn. Include the system control machine if it is a
|
||
|
|
database server machine.
|
||
|
|
<PRE> # <B>udebug</B> <<VAR>server machine</VAR>> <B>buserver</B>
|
||
|
|
# <B>udebug</B> <<VAR>server machine</VAR>> <B>kaserver</B>
|
||
|
|
# <B>udebug</B> <<VAR>server machine</VAR>> <B>ptserver</B>
|
||
|
|
# <B>udebug</B> <<VAR>server machine</VAR>> <B>vlserver</B>
|
||
|
|
</PRE>
|
||
|
|
<P>For each process, the output from all of the database server machines must
|
||
|
|
agree on which one is the sync site for the process. It is not,
|
||
|
|
however, necessary that the same machine serves as the sync site for each of
|
||
|
|
the four processes. For each process, the output from only one machine
|
||
|
|
must include the following string:
|
||
|
|
<PRE> I am sync site ...
|
||
|
|
</PRE>
|
||
|
|
<P>The output on the other machines instead includes the following line
|
||
|
|
<PRE> I am not sync site
|
||
|
|
</PRE>
|
||
|
|
<P>and a subsequent line that begins with the string <TT>Sync host</TT> and
|
||
|
|
specifies the IP address of the machine claiming to be the sync site.
|
||
|
|
<P>If the output does not meet these requirements or seems abnormal in another
|
||
|
|
way, contact AFS Product Support for assistance.
|
||
|
|
<P><LI><A NAME="LIWQ382"></A><B>On every database server machine in your cell</B> (other
|
||
|
|
than the system control machine), issue the <B>bos addkey</B> command
|
||
|
|
described in Step <A HREF="#LIWQ379">4</A>. Be sure to use the same values for
|
||
|
|
<VAR>afs_password</VAR> and <VAR>kvno</VAR> as you used in that step.
|
||
|
|
<A NAME="IDX7307"></A>
|
||
|
|
<P><LI><A NAME="LIWQ383"></A>Issue the <B>kas setpassword</B> command to define the new
|
||
|
|
key in the Authentication Database's <B>afs</B> entry. It must
|
||
|
|
match the key you created in Step <A HREF="#LIWQ379">4</A> and Step <A HREF="#LIWQ382">7</A>.
|
||
|
|
<PRE> # <B>kas setpassword -name afs</B> <B>-kvno</B> <<VAR>key version number</VAR>> <B>-noauth</B>
|
||
|
|
new_password: <VAR>afs_password</VAR>
|
||
|
|
Verifying, please re-enter new_password: <VAR>afs_password</VAR>
|
||
|
|
</PRE>
|
||
|
|
<P>where
|
||
|
|
<DL>
|
||
|
|
<P><DT><B><B>sp</B>
|
||
|
|
</B><DD>Is an acceptable alias for <B>setpassword</B> (<B>setp</B> is the
|
||
|
|
shortest acceptable abbreviation).
|
||
|
|
<P><DT><B>-kvno
|
||
|
|
</B><DD>Is the same key version number you specified in Step <A HREF="#LIWQ379">4</A>.
|
||
|
|
<P><DT><B><VAR>afs_password</VAR>
|
||
|
|
</B><DD>Is the same character string you specified as <VAR>afs_password</VAR> in
|
||
|
|
Step <A HREF="#LIWQ379">4</A>. It does not echo visibly.
|
||
|
|
</DL>
|
||
|
|
<P><LI><A NAME="LIWQ384"></A><B>On every database server machine in your cell</B>
|
||
|
|
(including the system control machine if it is a database server machine),
|
||
|
|
reenable authorization checking as instructed in <A HREF="#HDRWQ375">Reenabling Authorization Checking in an Emergency</A>. If the system control machine is not a database
|
||
|
|
server machine, do not perform this procedure until Step <A HREF="#LIWQ385">11</A>.
|
||
|
|
<P><LI>Repeat Step <A HREF="#LIWQ381">6</A> to verify that each database server process has properly
|
||
|
|
elected a sync site after being restarted in Step <A HREF="#LIWQ384">9</A>.
|
||
|
|
<P><LI><A NAME="LIWQ385"></A><B>On the system control machine</B> (if it is not a
|
||
|
|
database server machine), reenable authorization checking as instructed in <A HREF="#HDRWQ375">Reenabling Authorization Checking in an Emergency</A>. If it is a database server machine, you already
|
||
|
|
performed the procedure in Step <A HREF="#LIWQ384">9</A>.
|
||
|
|
<P><LI><B>On all remaining (simple) file server machines</B>, disable
|
||
|
|
authorization checking as instructed in <A HREF="#HDRWQ373">Disabling Authorization Checking in an Emergency</A>.
|
||
|
|
<P><LI><A NAME="LIWQ386"></A><B>On all remaining (simple) file server machines</B>,
|
||
|
|
issue the <B>bos addkey</B> command described in Step <A HREF="#LIWQ379">4</A>. Be sure to use the same values for
|
||
|
|
<VAR>afs_password</VAR> and <VAR>kvno</VAR> as you used in that step.
|
||
|
|
<P><LI><B>On all remaining (simple) file server machines</B>, reenable
|
||
|
|
authorization checking as instructed in <A HREF="#HDRWQ375">Reenabling Authorization Checking in an Emergency</A>.
|
||
|
|
</OL>
|
||
|
|
<HR><P ALIGN="center"> <A HREF="../index.htm"><IMG SRC="../books.gif" BORDER="0" ALT="[Return to Library]"></A> <A HREF="auagd002.htm#ToC"><IMG SRC="../toc.gif" BORDER="0" ALT="[Contents]"></A> <A HREF="auagd013.htm"><IMG SRC="../prev.gif" BORDER="0" ALT="[Previous Topic]"></A> <A HREF="#Top_Of_Page"><IMG SRC="../top.gif" BORDER="0" ALT="[Top of Topic]"></A> <A HREF="auagd015.htm"><IMG SRC="../next.gif" BORDER="0" ALT="[Next Topic]"></A> <A HREF="auagd026.htm#HDRINDEX"><IMG SRC="../index.gif" BORDER="0" ALT="[Index]"></A> <P>
|
||
|
|
<!-- Begin Footer Records ========================================== -->
|
||
|
|
<P><HR><B>
|
||
|
|
<br>© <A HREF="http://www.ibm.com/">IBM Corporation 2000.</A> All Rights Reserved
|
||
|
|
</B>
|
||
|
|
<!-- End Footer Records ============================================ -->
|
||
|
|
<A NAME="Bot_Of_Page"></A>
|
||
|
|
</BODY></HTML>
|