2

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.

jalf
  • 243,077
  • 51
  • 345
  • 550

1 Answers1

3

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.

Michael-O
  • 18,123
  • 6
  • 55
  • 121
  • +1, Thanks, extremely helpful. That seems to be the issue. I'll need to test it a bit more on monday, and then I'll accept the answer if all goes well. :) – jalf Jan 13 '12 at 16:03
  • Seems like it. It's still a bit shaky, but that seems to be a different issue. Sometimes fewer or no tickets seem to in the LSA cache when you log in to the Windows account. – jalf Jan 16 '12 at 19:13
  • This is fine. Windows login retrieves the TGT for your domain. Others on request. Maybe a SSPI-based solution would be better for you. Though this would mean o rewrite your code. – Michael-O Jan 17 '12 at 13:34
  • Yeah, a SSPI approach would be nice, but we're using this through a layer of other libs (XMLRPC-c which in turn calls cURL, which performs Kerberos authentication in some cases), and cURL's SSPI support seems pretty shaky. Further, this is a cross-platform app, and SSPI would obviously only be an option on Windows. I'll try playing around with it a bit more though. Thanks for your help – jalf Jan 17 '12 at 14:07
  • cURLs GSS-API is also crap on Unix. After several tricks I was able to compile on Unix but all the steps to make that work. Forget it. – Michael-O Jan 17 '12 at 15:19
  • Turns out the registry key only takes effect after a reboot. Perhaps you should add that to your answer. It tripped me up for a while. But otherwise, this seems to solve the problem – jalf Jan 18 '12 at 14:54