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 [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

> - After the ktadd operation, the data base however contains:[color=blue]
>
> 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.[/color]

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 [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]

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) <kenh@cmf.nrl.navy.mil> wrote:[color=blue]
>[color=green]
> > - 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.[/color]
>
> 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
>[/color]
________________________________________________
Kerberos mailing list [email]Kerberos@mit.edu[/email]
[url]https://mailman.mit.edu/mailman/listinfo/kerberos[/url]