If you are working with an existing cell which uses kaserver or Kerberos v4 for authentication, please see Initializing Cell Security with kaserver for installation instructions which replace this section.
Now initialize the cell's security mechanisms. Begin by creating the following two entires in your site's Kerberos database:
A generic administrative account, called admin by convention. If you choose to assign a different name, substitute it throughout the remainder of this document.
After you complete the installation of the first machine, you can continue to have all administrators use the admin account, or you can create a separate administrative account for each of them. The latter scheme implies somewhat more overhead, but provides a more informative audit trail for administrative operations.
The entry for AFS server processes, called either
The latter form is preferred since it works regardless of whether
your cell name matches your Kerberos realm name and allows multiple
AFS cells to be served from a single Kerberos realm.
No user logs in under this identity, but it is used to encrypt the
server tickets that granted to AFS clients for presentation to
server processes during mutual authentication. (The
chapter in the OpenAFS Administration Guide about cell configuration and administration describes the
role of server encryption keys in mutual authentication.)
In Step 7, you also place the initial AFS server encryption key into the /usr/afs/etc/KeyFile file. The AFS server processes refer to this file to learn the server encryption key when they need to decrypt server tickets.
You also issue several commands that enable the new admin user to issue privileged commands in all of the AFS suites.
The following instructions do not configure all of the security mechanisms related to the AFS Backup System. See the chapter in the OpenAFS Administration Guide about configuring the Backup System.
The examples below assume you are using MIT Kerberos. Please refer to the documentation for your KDC's administrative interface if you are using a different vendor
Enter kadmin interactive mode.
# kadmin Authenticating as principal
YOUR REALMwith password Password for
You should make the
long and complex as possible, but keep in mind that administrators
need to enter it often. It must be at least six characters long.
Note that when creating the
entry, the encryption types should be restricted to des-cbc-crc:v4.
For more details regarding encryption types, see the documentation
for your Kerberos installation.
kadmin: add_principal -randkey -e des-cbc-crc:v4 afs/<
cell name> Principal "afs/
REALM" created. kadmin: add_principal admin Enter password for principal "admin@
kadmin: get_principal afs/<
cell name> Principal: afs/
cell[ ... ] Key: vno 2, DES cbc mode with CRC-32, no salt [ ... ]
Extract the newly created key for afs/
cell to a keytab on the local machine. We will use /etc/afs.keytab as the location for this keytab.
The keytab contains the key material that ensures the security of your AFS cell. You should ensure that it is kept in a secure location at all times.
kadmin: ktadd -k /etc/afs.keytab -e des-cbc-crc:v4 afs/<
cell name> Entry for principal afs/<
cell name> with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/afs.keytab
Make a note of the key version number (kvno) given in the response, as you will need it to load the key into bos in a later step
Note that each time you run ktadd a new key is generated for the item being extracted. This means that you cannot run ktadd multiple times and end up with the same key material each time.
Issue the quit command to leave kadmin interactive mode.
# ./bos adduser <
machine name> admin -noauth
asetkey requires the key version number (or kvno) of the
key. You should have made note of the kvno when creating the key
earlier. The key version number can also be found by running the
# kvno -k /etc/afs.keytab afs/<
Once the kvno is known, the key can then be extracted using asetkey
# asetkey add <
kvno> /etc/afs.keytab afs/<
bos listkeys command to verify that
the key version number for the new key in the
KeyFile file is the same as the key
version number in the Authentication Database's
entry, which you displayed in Step 3.
# ./bos listkeys <
machine name> -noauth key 0 has cksum
You can safely ignore any error messages indicating that bos failed to get tickets or that authentication failed.