need help -- kinit (1.9.1) fails to process keytab

[Rex, Martin]

Greg Hudson wrote:
> 
> Martin Rex wrote:
> >
> > I've tried everything I can reasonably think of, but kinit -k
> > always fails with the non-sensical error message
> > "kinit: Key table entry not found while getting initial credentials"
> 
> You can probably get a better picture of the problem by setting the
> environment variable KRB5_TRACE to a filename (or just /dev/stdout) for
> the kinit command.

Thanks -- KRB5_TRACE ... and there was light!

(I really had expected "-V" to do what KRB5_TRACE does,
 or a strong hint to KRB5_TRACE on "kinit -h" output.)


> 
> This error message ought to name the principal it didn't find, but for
> complicated reasons the more specific message gets lost in 
> some (common) configurations.

(Beware: I know very little about KDC interals and lower level
 Kerberos protocol, so some of my conclusions may be wrong).


Douglas is correct that W2K8R2-AD uses aes256-cts
(while W2K3-AD uses rc4-hmac),

I would have expected that by using Microsoft KTPASS.EXE with
an explict "-crypt RC5-HMAC-NT" parameter that I would force
one specific key+etype into the KDB (and nothing else), but
KRB5_TRACE for kinit says that W2K8-AD sticks to aes256-cts
no matter what.

(btw. I'm using KTPASS.EXE from&on W2K8R2 PDC).

Using KTPASS.EXE "/SETPASS /PASS *" produces keytabs that
will not work (dunno why) for both enctypes HMAC-RC4 and AES256.

Using only "+rndpass" with AES256 works, HMAC-RC4 don't work either.

Can I somehow force the Account to use an rc4-hmac key exclusively,
or will I have to fill the keytab with entries for every possible
enctype for interop with XP/2003 _and_ Vista/Win7 clients
-- or is the enctype of the server principal irrelevant to
the clients that want to authenticate to that service?

Also there seems to be a problem with the SALT, which seem to
make KTPASS.EXE fail for principal names that are not SPNs
(do not contain a forward slash).  The salt value appears to be
something stores seperately on the KDC/AD, because it is
created by KTPASS.EXE on the windows machine and appears
in plaintext of the kinit KRB5_TRACE on the linux machine.
KTPASS.EXE seems to set the salt (and only then use it correctly)
when it succeeds setting the SPN in its operation, and fails
otherwise (and always fails with slash-less principals).

The (k)vno==0 shown by kinit -k KRB5_TRACE confuses me,
it always traces "keytab (vno 0, enctype aes256-cts)",
even when it succeeds and finds the key, though the keytab
only contains a key with kvno 17 (at the moment).


I think I can wiggle through the MIT Kerberos part of the
puzzle with KRB5_TRACE infos, but I'm heavily confused on
Microsoft side of the game (KTPASS.EXE/W2K8-AD).

If someone happens to have URLs into enlightening
Microsoft Online Docs or KBs, that would be great.



-Martin