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

Fri Jul 1 10:44:15 EDT 2011

On 6/30/2011 10:07 PM, Rex, Martin wrote:
>
>
> 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.

  The parameter can beset by your AD amdin for the account,
    Set the account attribute  msds-supportedEncryptionTypes
    http://msdn.microsoft.com/en-us/library/cc223853(v=prot.10).aspx
    to match what is in the keytab.

Yes, one would expect ktpass to do a better job, but it does not,
that is why we use msktutil which can set the msds-supportedEncryptionTypes
too.

The disconnect is that traditional Kerberos implementations
store keys in the KDC, and keytab. Windows store a password
and generates keys on the fly.

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

Since AD stores only one password and one kvno per account, and each
time you run ktpass the kvno gets updated. if you run ktpass twice
even withthe same password to create two keys, the kvno may be updated
and thus the first key added to the keytab is not usable.

It would be easy to try and see if the account attribute
msDS-KeyVersionNumber changes when you run ktapss.
On W7, run mmc, and add the Snap-in ADSI Edit Then find the
account, select properties, then Filters, and click on constructed
and backlinks. Unclick both of the "Show only..."

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

 From my previous note use (2) msds-supportedEncryptionTypes

Thinking more about (3) kinit/libkrb5 mods, If the libkrb5 derived the
etype field for the AS_REQ  from the enctypes of keys in the keytab and
the default_tkt_enctypes, but the etype field is meant to specify the
enctypes the client library supports, not necessarily the enctypes
in the keytab. So mods to  kinit may not be such a good idea.

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

Is irrelevant. The issue is the KDC will return a AS-REP with the
enc-part encrypted in a key that it expects the client to
find in the keytab (RFC 4120 5.4.2.) In an MIT KDC, the keys
were created when the account was added/changed  by kadmin, or
ktutil that keep the keys in the keytab in sync with the keys
in the KDC.

ktpass appears to not be keeping the types of keys in the keytab
and the msds-SupportedEncryptionTypes in sync. Sounds like a bug
with ktpass.

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

Sounds like another bug in ktapss, only being able to handle
non host principals or enctypes that don't use a salt (arcfour).

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

We and many others were confused about ktpass and thus use
msktutil to create these types of keytabs.

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

msDS-SupporetedEncryptionTypes:
http://msdn.microsoft.com/en-us/library/cc223853(v=prot.10).aspx

msDS-KeyVersionNumber:
http://msdn.microsoft.com/en-us/library/cc220292(v=prot.10).aspx

Microsoft Kerberos Protocol Enxtensions Last  changed 6/17/2011:
http://msdn.microsoft.com/en-us/library/cc233855(v=prot.13).aspx
>
>
>
> -Martin
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444