help: getting a TGT with a keytab
Olga Kornievskaia
I'm a newbie so please excuse me if I'm doing something totally stupid.
I'm trying to make 'kinit' get a TGT for a principal with a keytab.
I'm running K5 KDC with a test realm. Here is what I've done:
1. Created a principal:
addpric -randkey alice
2. Added this principal to a keytab:
ktadd -k /tmp/alice.keytab alice
3. Tried to use kinit to get a TGT:
kinit -k -t /tmp/alice.keytab alice@REALM
... but kinit tells me:
kinit: Bad encryption type while getting initial credentials
When I look at the logs generated by KDC, it looks like it
successfully generated a TGT for principal alice.
Can anybody tell me what I'm doing wrong?
Actually, eventually I'm trying to write a service that needs to get a TGT
so that it can talk to other Kerberos-secured services. In my code I'm
using function: krb5_get_in_tkt_with_keytab. It looks like the function
that I should be using. As the 3rd argument, this function takes
encryption type. If I set it to NULL, then I get the same error as kinit.
However, if I specify ENCTYPE_DES_CBC_CRC as the encryption type. Then it
no longer complains about bad encryption, but says: 'Decrypt integrity
check failed'. I haven't yet found a way to set which checksum kerberos
should use. But it might not be what's causing the failure.
Any suggestions would be really appreciated,
Thanks,
-Olga
Donn Cave
I'm guessing that your Kerberos version is 1.1, not 1.0. I have
seen this problem with 1.1 clients, and was able to fix it with
the following lines in /etc/krb5.conf:
[libdefaults]
default_realm = (your realm is already here)
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
That's about the same as your encryption type parameter, so at worst
it will spare you the nuisance of having to hard-wire that in your
software. I'm not sure this isn't more or less a bug in 1.1 - we're
using des-cbc-crc because it really is the default, and it seems silly
to have to explicitly specify that default just for the benefit of
get_in_tkt_with_keytab(). If the MIT software could agree on one
default, that would be nice.
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
Jeffrey Altman
Donn Cave <do...@u.washington.edu> wrote:
: I'm guessing that your Kerberos version is 1.1, not 1.0. I have
: seen this problem with 1.1 clients, and was able to fix it with
: the following lines in /etc/krb5.conf:
:
: [libdefaults]
: default_realm = (your realm is already here)
: default_tkt_enctypes = des-cbc-crc
: default_tgs_enctypes = des-cbc-crc
:
: That's about the same as your encryption type parameter, so at worst
: it will spare you the nuisance of having to hard-wire that in your
: software. I'm not sure this isn't more or less a bug in 1.1 - we're
: using des-cbc-crc because it really is the default, and it seems silly
: to have to explicitly specify that default just for the benefit of
: get_in_tkt_with_keytab(). If the MIT software could agree on one
: default, that would be nice.
I believe this bug has been fixed in 1.2.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * kermit-...@kermit-project.org
Mary Cronk
... but kinit tells me:
> kinit: Bad encryption type while getting initial credentials
>
> When I look at the logs generated by KDC, it looks like it
> successfully generated a TGT for principal alice.
>
> Can anybody tell me what I'm doing wrong?
>
>
This is the same problem I am having with a host (CISCO Router). However,
this error is also written to the logs on the kerberos server.
I am running MIT Kerberos V 1.06. Also, I have the following lines in
/etc/krb.conf :
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
This is what the CISCO documentation also suggests.
CISCO claims they have tested with this version of MIT Kerberos V
successfully.
Mary Cronk
Binghamton University Computer Center
Steve Langasek
> I'm guessing that your Kerberos version is 1.1, not 1.0. I have
> seen this problem with 1.1 clients, and was able to fix it with
> the following lines in /etc/krb5.conf:
> [libdefaults]
> default_realm = (your realm is already here)
> default_tkt_enctypes = des-cbc-crc
> default_tgs_enctypes = des-cbc-crc
> That's about the same as your encryption type parameter, so at worst
> it will spare you the nuisance of having to hard-wire that in your
> software. I'm not sure this isn't more or less a bug in 1.1 - we're
> using des-cbc-crc because it really is the default, and it seems silly
> to have to explicitly specify that default just for the benefit of
> get_in_tkt_with_keytab(). If the MIT software could agree on one
> default, that would be nice.
Ah, thank you for this timely post. These changes to krb5.conf also fix
the problem I was having trying to use keytabs for kadmin authentication.
:)
Why are these not the default options in 1.1.1? Is this a bug/oversight,
or are there reasons why these enctypes should not be enabled?
Thanks,
Steve Langasek
postmodern programmer
Ken Raeburn
one or the other.)
Olga Kornievskaia <ag...@engin.umich.edu> writes:
> I'm a newbie so please excuse me if I'm doing something totally stupid.
> I'm trying to make 'kinit' get a TGT for a principal with a keytab.
> I'm running K5 KDC with a test realm. Here is what I've done:
> 1. Created a principal:
> addpric -randkey alice
> 2. Added this principal to a keytab:
> ktadd -k /tmp/alice.keytab alice
> 3. Tried to use kinit to get a TGT:
> kinit -k -t /tmp/alice.keytab alice@REALM
>
> ... but kinit tells me:
> kinit: Bad encryption type while getting initial credentials
Check krb5.conf on the client side against kdc.conf, and make sure
they have compatible ideas about what encryption types are permitted.
Check against what's in the database too.
What code base are you using? Version 1.0.x of the MIT code didn't
cope with unknown cryptosystems being listed in places the code really
had no business looking. E.g., if you got a DES session key for
talking to a service with a 3DES service key, the client code would
complain, even though it could never make use of the service key even
if it understood the cryptosystem type.
Ken
Jeffrey Altman
Steve Langasek <vor...@dodds.net> wrote:
This is indeed a bug in 1.1.x. The get_in_tkt_...() functions
were ignoring the enctypes specified by the KDC. The defaults in
1.1.x and higher are to use 3des and not des. This is fixed in