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

[Rex, Martin]

Martin Rex wrote:
> 
> 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).

Or so I thought ...

The Microsoft Windows W2K8-R2 / Active Directory side
of the game is not very much fun.


1.) enctype issue. I am seeing what looks like an
    aes256-cts sticky-ness AS_REP combined with an
    rc4-hmac sticky-ness for TGS_REP, causing either
    "kinit -k" or security context establishment to fail.

    After using KTPASS.EXE to set&create a keytab with a random
    password, i.e (+rndpass -crypto AES256-SHA1) "kinit -k"
    can successfully acquire a TGT (etype aes256-cts)

    Trying to establish a security context with itself
    (using the keytab and the TGT acquired by "kinit -k")
    gss_init_sec_context() receives a service ticket with the
    etype "rc4-hmac" and gss_accept_sec_context() fails
    because there is no rc4-hmac key in the keytab.

    Now what puzzles me: I've set a random password with KTPASS.EXE
    for exactly one specific etype (AES256-SHA1) and the account
    has the property "Store password using reversible encryption"
    *DISABLED*, so intuitively, it should be impossible for AD
    to create anything else than a aes256-cts ticket to that
    account/service, shouldn't it?

    Probable Workaround: I can use "+randpass -crypto ALL" to
    create a keytab with keys of all enctypes
    It creates 5 Keytab entries with des-cbc-crc, des-cbc-md5,
    rc4-hmac, aes256-cts, aes128-cts) and the two single-DES
    keytabs are created even though I have des enctypes
    disabled for that account in the account properties...)
    With service keys for all enctypes in the keytab.
    authentication may succeed for all Kerberos protocol
    exchanges, no matter what goofy etypes selections
    W2K8-AD might come up with in various situations,
    I assume.

    For interop with a considerable variety of
    Kerberos peers, a keytab with as many etypes as
    possible might be preferable anyway for the
    final usage scenario that I have in mind.


2.) salt issue:  W2K8-R2 KTPASS.EXE is probably buggy

    KTPASS.EXE fails to update the salt in AD when creating a
    keytab with a vanilla Kerberos Principal Name (the keytab
    entries are created with the correct salt though (visible
    when adding the "/dumpsalt" parameter to KTPASS.EXE)
    The resulting configuration is non-functional, of course.
    "kinit -k" fails.

    Supplying KTPASS with an explicit salt (/rawsalt) causes
    KTPASS.EXE to crash when the string is empty and causes
    it to wedge in a tight loop spilling out nonsense when the
    supplied salt is what it should be for that vanilla
    Kerberos principal.

    Workaround, call KTPASS.EXE once with a lone forward slash
    character prefixed to the vanilla principal name, which
    succeeds in writing the correct Salt into the AD, and
    then call KTPASS.EXE again without that forward slash
    in front of the vanilla Kerberos Principal name to
    create a usable keytab for that Principal.


So now I'm able to use krb5-1.9.1 on linux with
an account in an W2K8-R2 and my GSSTEST succeeds local
security context establishments with itself.


I am confused by some strange gss_compare_name() failures
in 1.9.1 libgssapi_krb5.so reported by GSSTEST that I have
never seen before with any libraries.  The printable and hexdump
inputs and outputs of the names for which gss_compare_name()
fails are clean.  It seems to affect MN to non-MN comparisons.


So I'm going back to work now on the actual gssapi client
and server "apps" that I originally wanted to give to
colleagues in order to show them "how simple it is"
to retrofit Kerberos-SSO into a specific existing
client-server scenario.  I hope that the rest is
really as simple as I light-heartedly claimed
the entire "proof-of-concept" to be...  :-/


-Martin