Question

I’m struggling with a Windows application which uses MIT Kerberos for authentication.

If a user logs on to Windows with a domain user account, klist shows that he gets the expected tickets from the AD, including this one:

#1>     Client: jalf @ TESTREALM.COM
        Server: krbtgt/TESTREALM.COM @ TESTREALM.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 1/12/2012 9:46:27 (local)
        End Time:   1/12/2012 19:46:27 (local)
        Renew Time: 1/19/2012 9:46:27 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)

However, when we try to use this ticket in our application, the Kerberos library does not seem to find that one.

Here’s a simplified version of the relevant code:

// Open the MSLSA cache
krb5_cc_resolve(kcontext, "MSLSA:", &mslsa_ccache);
// Create a cursor for traversing the cache
krb5_cc_start_seq_get(kcontext, mslsa_ccache, &cursor);
// Check all the credentials in the cache
while (!(code = krb5_cc_next_cred(kcontext, mslsa_ccache, &cursor, &creds)))  {
    // Find the one with the INITIAL flag set
    if ( creds.ticket_flags & TKT_FLG_INITIAL ) {
        // ticket found
        krb5_free_cred_contents(kcontext, &creds);
        break;
    }
    krb5_free_cred_contents(kcontext, &creds);
}

krb5_cc_end_seq_get(kcontext, mslsa_ccache, &cursor);

But for whatever reason, we never enter the // ticket found part.
Running the code in the debugger, I can see that it finds several of the other tickets shown by klist, but for some reason it never finds the one we’re interested in.

Can anyone explain this behavior, or how to get around it? Naively, I’d expect the output from klist to match the results of iterating over the cache with krb5_cc_next_cred.

I’m relatively new to Kerberos, and inherited this code from a coworker who left, so it’s possible that I’m missing some vital fundamental piece of information.

Answer 1

You probably do not have access to the session key in the LSA. Only SSPI can access. You can try this

Cause 2: This exception is thrown when using native ticket cache on some Windows platforms. Microsoft has added a new feature in which they no longer export the session keys for Ticket-Granting Tickets (TGTs). As a result, the native TGT obtained on Windows has an “empty” session key and null EType. The effected platforms include: Windows Server 2003, Windows 2000 Server Service Pack 4 (SP4) and Windows XP SP2.

Solution 2: You need to update the Windows registry to disable this new feature. The registry key allowtgtsessionkey should be added–and set correctly–to allow session keys to be sent in the Kerberos Ticket-Granting Ticket.

On the Windows Server 2003 and Windows 2000 SP4, here is the required registry setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01  ( default is 0 )

By default, the value is 0; setting it to “0x01” allows a session key to be included in the TGT.
Here is the location of the registry setting on Windows XP SP2:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

Java’s GSS impl fails here too. This is recommended by Oracle. You may suffer from the same problem with MIT Kerberos.

This change goes in effect after a reboot only.