ktadd behaviour

[Andrei Maslennikov]

  - At one of our sites we are using krb5 1.5.1 with AFS;
    in one of the system applications we need to use ktadd
    to extract and store the key of a principal which also
    has to maintain the ability to authenticate directly to
    AFS kdc-krb524-fakeka using the normal klog command.

  - Before the ktadd operation, this user has three keys stored
    in the data base. As seen with getprinc:

    Number of keys: 3
    Key: vno 34, DES cbc mode with CRC-32, no salt
    Key: vno 34, DES cbc mode with CRC-32, Version 4
    Key: vno 34, DES cbc mode with CRC-32, AFS version 3

    This is correct, as the kdc.conf contains these supported_enctypes:
    des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3

  - After the ktadd operation, the data base however contains:

    Number of keys: 1
    Key: vno 35, DES cbc mode with CRC-32, no salt

    And, obviously, klog cannot work anymore. The cpw operation
    resolves this (recreates 3 keys), but then the previously
    added keytab is no longer valid.

  - The ktadd manual says, among other things:
    "An entry for each of the principals unique encryption types is
    added, ignoring multiple keys with the same encryption type but
    different salt types".

    I would understand this statement if it would only refer to the keytab
    file, but obviously it is also valid for the data base. Ktadd clearly
    ignores v4 and afs3 salts when updating the database.

So it looks like a kind of a deadlock: we need to use ktadd, but we
still have to use klog after it (clearly kinit and afslog or aklog after
it still work after ktadd, but this is not enough for us). I wonder
whether there is any way out of this. BTW, with Heimdal these problems do
not exist, but we wish to use the MIT version..