ka-forwarder(8) [debian man page]
KA-FORWARDER(8) AFS Command Reference KA-FORWARDER(8) NAME
ka-forwarder - Forward AFS Authentication Server requests to another server SYNOPSIS
ka-forwarder [-p <port>] <server>[/<port>] [...] DESCRIPTION
ka-forwarder listens for requests for an AFS Authentication Server and forwards them to a remove fakeka server. fakeka is a server that answers AFS Authentication Server protocol requests using a regular Kerberos KDC and is provided with some Kerberos 5 implementations. fakeka has to run on the same host as the Kerberos KDC, however, and AFS clients send all native AFS authentication requests to the AFS database servers. If you don't want to run your Kerberos KDCs and your AFS database servers on the same host, run ka-forwarder on the AFS database servers and point it to fakeka running on the Kerberos KDCs. ka-forwarder takes one or more servers to which to forward the requests. The default port on the remote server to which to forward the command is 7004, but a different port can be specified by following the server name with a slash ("/") and the port number. If multiple servers are given, ka-forwarder will send queries to each server in turn in a round-robin fashion. CAUTIONS
Due to the way that ka-forwarder distinguishes from client requests and server responses, any messages from one of the servers to which ka- forwarder is forwarding will be considered a reply rather than a command and will not be forwarded. This means that the servers running fakeka will not be able to use native AFS authentication requests and rely on ka-forwarder to send the requests to the right server. ka-forwarder does not background itself. It should either be run in the background via the shell, or run via the Basic OverSeer Server (see bosserver(8)). OPTIONS
-p <port> By default, ka-forwarder listens to the standard AFS Authentication Server port (7004). To listen to a different port, specify it with the -p option. EXAMPLES
Forward AFS Authentication Server requests to the fakeka servers on kdc1.example.com and kdc2.example.com: % ka-forwarder kdc1.example.com kdc2.example.com & Note the "&" to tell the shell to run this command in the background. PRIVILEGE REQUIRED
ka-forwarder only has to listen to port 7004 and therefore does not require any special privileges unless a privileged port is specified with the -p option. SEE ALSO
bosserver(8), fakeka(8), kaserver(8) COPYRIGHT
Copyright 2006 Russ Allbery <rra@stanford.edu> This documentation is covered by the IBM Public License Version 1.0. This man page was written by Russ Allbery for OpenAFS. OpenAFS 2012-03-26 KA-FORWARDER(8)
Check Out this Related Man Page
ASETKEY(8) AFS Command Reference ASETKEY(8) NAME asetkey - Add a key from a keytab to an AFS KeyFile SYNOPSIS asetkey add <kvno> <keyfile> <principal> asetkey add <kvno> <key> asetkey delete <kvno> asetkey list DESCRIPTION The asetkey command is used to add a key to an AFS KeyFile from a Kerberos keytab. It is similar to bos addkey 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. asetkey delete can be used to delete a key (similar to bos removekeys), and asetkey list will list the keys in a KeyFile (similar to bos listkeys). asetkey is used when authentication for an AFS cell is provided by a Kerberos 5 KDC rather than kaserver. The key for the "afs" or "afs/cell name" 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 "ktadd" function of the kadmin command) and then, on each AFS database server and file server, adding that key to the KeyFile with asetkey add. The kvno chosen should match the kvno in the Kerberos KDC (checked with kvno or the "getprinc" function of kadmin). principal should be the name of the AFS principal in the keytab, which must be either "afs" or "afs/cell name". asetkey 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 /etc/openafs/server directory, it is conventional to run asetkey add only on the control machine and then let the Update Server propagate the new KeyFile to all other systems. CAUTIONS AFS currently only supports des-cbc-crc:v4 Kerberos keys. Make sure, when creating the keytab with "ktadd", you pass "-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 "ktadd", 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 asetkey, 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 "ktadd" 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 asetkey on each server. EXAMPLES The following commands create a new keytab for the principal "afs" and then import the key into the KeyFile. Note the kvno in the output from "ktadd". % 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 "afs/cell name" instead of "afs", 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 key should be an 8 byte hex representation. PRIVILEGE REQUIRED The issuer must be able to read (for asetkey list) and write (for asetkey add and asetkey delete) the KeyFile, normally /etc/openafs/server/KeyFile. In practice, this means that the issuer must be the local superuser "root" on the AFS file server or database server. For asetkey add, the issuer must also be able to read the specified keytab file. SEE ALSO KeyFile(5), bos_addkey(8), bos_listkeys(8), bos_removekey(8), kadmin(8), kvno(1) COPYRIGHT Copyright 2006 Russ Allbery <rra@stanford.edu> This documentation is covered by the IBM Public License Version 1.0. This man page was written by Russ Allbery for OpenAFS. OpenAFS 2012-03-26 ASETKEY(8)