ktadd behaviour - Kerberos

This is a discussion on ktadd behaviour - Kerberos ; - 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: ktadd behaviour

  1. ktadd behaviour

    - 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..
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: ktadd behaviour

    > - 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.


    You're focusing on the wrong thing here. The number of keytypes is
    really immaterial.

    When you use ktadd, a new _key_ is being created. This means that the
    user's password is being changed at the same time (well, when you use
    ktadd, there's no guarantee that you will end up with a key which
    necessarily corresponds to a password). When you do a ktadd, you're
    doing an implicit "cpw -randkey".

    What you might want to do is use ktutil to create a keytab which corresponds
    to the password you want to use for that account (look at "addent" inside
    of ktutil).

    --Ken
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: ktadd behaviour

    Thanks Ken (I actually thought that only kvno was changed during ktadd).
    I have just tried the addent subcommand of ktutil, and it did the job.

    Regards - Andrei.

    On 10/17/06, Ken Hornstein (Contractor) wrote:
    >
    > > - 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.

    >
    > You're focusing on the wrong thing here. The number of keytypes is
    > really immaterial.
    >
    > When you use ktadd, a new _key_ is being created. This means that the
    > user's password is being changed at the same time (well, when you use
    > ktadd, there's no guarantee that you will end up with a key which
    > necessarily corresponds to a password). When you do a ktadd, you're
    > doing an implicit "cpw -randkey".
    >
    > What you might want to do is use ktutil to create a keytab which
    > corresponds
    > to the password you want to use for that account (look at "addent" inside
    > of ktutil).
    >
    > --Ken
    >

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread