=head1 NAME
asetkey - Add a key from a keytab to an AFS KeyFile
=head1 SYNOPSIS
=for html
B
add > > >
B add > >
B delete >
B list
=for html
=head1 DESCRIPTION
The B command is used to add a key to an AFS KeyFile from a
Kerberos keytab. It is similar to B except that it must be
run locally on the system where the KeyFile is located and it takes the
new key from the command line or a Kerberos 5 keytab rather than prompting
for the password.
B can be used to delete a key (similar to B), and B will list the keys in a KeyFile (similar
to B).
B is used when authentication for an AFS cell is provided by a
Kerberos 5 KDC rather than B. The key for the C or
C> principal in the Kerberos 5 KDC must match the key
stored in the AFS KeyFile on all AFS database servers and file servers.
This is done by creating a keytab containing that key using the standard
Kerberos commands (generally the C function of the B
command) and then, on each AFS database server and file server, adding
that key to the KeyFile with B. The I chosen should
match the kvno in the Kerberos KDC (checked with B or the
C function of B). I should be the name of
the AFS principal in the keytab, which must be either C or
C>. B can also be used to install a key
from a hex string.
In cells that use the Update Server to distribute the contents of the
F directory, it is conventional to run B only
on the control machine and then let the Update Server propagate the new
KeyFile to all other systems.
=head1 CAUTIONS
AFS currently only supports des-cbc-crc:v4 Kerberos keys. Make sure, when
creating the keytab with C, you pass C<-e des-cbc-crc:v4> to force
the encryption type. Otherwise, AFS authentication may not work.
As soon as a new keytab is created with C, new AFS service tickets
will use the new key. However, tokens formed from those service tickets
will only work if the new key is present in the KeyFile on the AFS file
server. There is therefore an outage window between when the new keytab
is created and when the key had been added to the KeyFile of all AFS
servers with B, during which newly obtained AFS tokens will not
work properly.
All of the KeyFile entries must match the key in the Kerberos KDC, but
each time C is run, it creates a new key. Either the Update Server
must be used to distribute the KeyFile to all servers or the same keytab
must be used with B on each server.
=head1 EXAMPLES
The following commands create a new keytab for the principal C and
then import the key into the KeyFile. Note the kvno in the output from
C.
% kadmin
Authenticating as principal rra/admin@stanford.edu with password.
Password for rra/admin@stanford.edu:
kadmin: ktadd -k /tmp/afs.keytab -e des-cbc-crc:v4 afs
Entry for principal afs with kvno 3, encryption type DES cbc mode
with CRC-32 added to keytab WRFILE:/tmp/afs.keytab.
kadmin: exit
% asetkey add 3 /tmp/afs.keytab afs
You may want to use C> instead of C, particularly if
you may have multiple AFS cells for a single Kerberos realm.
In the event you have been distributed a key by a Kerberos administrator
in the form of a hex string, you may use asetkey to install that.
% asetkey add 3 80b6a7cd7a9dadb6
I should be an 8 byte hex representation.
=head1 PRIVILEGE REQUIRED
The issuer must be able to read (for B) and write (for
B and B) the KeyFile, normally
F. In practice, this means that the issuer must be
the local superuser C on the AFS file server or database server.
For B, the issuer must also be able to read the specified
keytab file.
=head1 SEE ALSO
L,
L,
L,
L,
kadmin(8),
kvno(1)
=head1 COPYRIGHT
Copyright 2006 Russ Allbery
This documentation is covered by the IBM Public License Version 1.0. This
man page was written by Russ Allbery for OpenAFS.