Multiple Realms and Multiple TGTs under MIT Kerberos for Windows

My local computer uses Windows 7 Pro and belongs to realm LR, managed by AD servers. I login to my computer while attached to that realm's network. I can view the TGT with MIT Kerberos for Windows ver. 4.0.1.

I want to access resources on a foreign realm, FR. There is no Kerberos trust between LR and FR, but they allow TCP traffic between one another. I request a TGT for FR with its KDC (Red Hat IdM / FreeIPA) and successfully enter my password when challenged. Again, I can view the TGT with MIT Kerberos for Windows ver. 4.0.1. I can now access resources in FR over SSH without being asked for a password, despite originating from LR.

The problem is when I get the TGT for FR, the TGT for my LR principal disappears. Only the FR TGT is visible in MIT Kerberos. If I lock my computer and then unlock with my password, now the FR TGT is gone, replaced by a new LR TGT.

It seems MIT Kerberos for Windows can only store one TGT at a time. Each TGT completely works for its realm for all intents and purposes. How can I configure MIT Kerberos to let me have two TGTs at once, one for each realm? Is it possible to "compartmentalize" with multiple client instances, each pointing to a different KRB5_CONFIG and local keytab? If I cannot, is there an alternative Windows implementation of client-side Kerberos 5 that will, even when there are no inter-realm trusts?

P.S. - I don't want a trust. Can't get a trust.

UPDATE: I left out some of these details earlier because I thought it might confuse the issue. But based on Brad's answer, it might be warranted. I expect most local software would use the built-in Windows implementation of Kerberos and always use the LR keytab.

However, power users like me use heimdal under Cygwin to SSH into FR. I expect anything going through Cygwin DLLs to use heimdal and never see the LR TGT (which it doesn't, at least not by default). I explicitly kinit and move on.

The tricky part comes in for non-power users I have to support who don't use Cygwin but do use PuTTY. PuTTY does let you specify both the library path and DLL for which GSSAPI implementation to use. For instance, I'm configuring SSH sessions to use MIT Kerberos DLLs instead of built-in Windows DLLs. I was hopeful there was a DLL out there that either never tried to find the LR TGT (like heimdal) or allowed multiple TGTs from multiple realms. It doesn't have to have a GUI window like MIT Kerberos, but it helps.

Well I won't say it CAN'T be done with Windows, but I will say that the limitation is session based. The problem then, is that for each session Windows caches one ticket. When you lock your computer then unlock it another session is initiated and a new key is requested from the KDC. The same thing happens when you log off then on to your computer again. This method is actually how user permissions are determined for server sessions as well, meaning the key/ticket can be cached so that every server resource or session you initiate doesn't have to ask you for your password, but I've never heard/read/researched of it to be able to cache more than one.

Now, you probably already know that given your knowledge that you've displayed in your question, so I'll say that based off the fact that Windows stores the key you get when a TGT is issued and is session based, I don't think it's possible with JUST Windows. The MIT Kerberos for Windows may have a way to initiate two sessions under one user, but even then, I'm not sure how the resources you are accessing would know which ticket/key pair to use. Does that make sense?

Please see this for a description of how Windows stores TGTs/key pairs.

Very good question by the way.

OK, I've come up with a working solution that needs some more polish, so might not work in all environments.

This works with:

1. MIT Kerberos for Windows 4.0.1 with Windows support tools (KSETUP.EXE, KTPASS.EXE)
2. PuTTY 0.63
3. Windows 7 SP1

I was looking in the MIT Kerberos source and came across the README for Windows. Of particular interest was the different values for Credentials Cache. It espouses a default value of API:, but I surprisingly found my registry using MSLSA: instead.

I played around with different values of ccname under HKEY_CURRENT_USER\Software\MIT\Kerberos5. I tried MEMORY: at first, which lead to some interesting behavior. When opening a PuTTY session, my MIT Kerberos Ticket Manager window would restore and come to the foreground, asking me to enter credentials. Wow! That never happened before, but alas, PuTTY would reject it. The value that did the trick for me was FILE:C:\Some\Full\File\Path. I'm not exactly sure how to secure access to the specified file, so I'll leave that as an exercise for the reader. I got the same window-to-the-foreground behavior, only PuTTY liked it this time. The Ticket Manager window also finally both displayed the LR and FR tickets. The tickets were proven to be forwardable and would survive multiple Windows Lock/Unlocks. NOTE: be sure to completely Exit and restart the Ticket Manager inbetween registry edits. I haven't tried out a ccname of API: yet.

I don't know if this makes a difference or not, but I also played around with KSETUP before this started working. At first, a parameterless KSETUP would just show me information about the LR. I added some info about the FR on my local workstation.

ksetup /AddKdc FOREIGN.REALM KDC.FOREIGN.REALM
ksetup /AddRealmFlags FOREIGN.REALM TcpSupported Delegate NcSupported

To me, it looks a bit like there's actually a bug in Kerberos for Windows.

I found the following:

If I use the "get ticket" option in the KfW 4.0.1 window, it Just Works(TM); I can hit the "Get ticket" button, and acquire additional tickets to the original tickets that I got when I log on.

If I hit the "make default" option in the KfW window, then from that point on every time I hit "get ticket", the new ticket will replace whatever ticket is the default, rather than add another entry to the list of known tickets. Checking the registry at that point will show that a ccname entry (as in Toddius' answer) has been added. Removing that entry will, surprisingly, restore the previous behaviour of allowing multiple tickets.

Following on to Toddius' answer, I have a co-worker in a similar situation (Windows 7 Enterprise 64-bit, joined to an AD domain, also running MIT Kerberos for Windows 4.0.1): His copy of the Kerberos Ticket Manager would only allow him to have one principal/one TGT. Whenever he would use the "Get Ticket" button to get a TGT for a different principal, the previous principal would disappear.

I reviewed the README, and most of the registry keys were set as expected, except for the ccname key at path HKEY_CURRENT_USER\Software\MIT\Kerberos5. That key was set to the value MSLSA:. Our fix was to change that to API:. More specifically, the steps were:

1. Quit the Kerberos Ticket Manager, along with all other applications (since you'll be restarting).
2. At Registry path HKEY_CURRENT_USER\Software\MIT\Kerberos5, change the ccname key to API: (A-P-I, then colon).
3. Exit regedit, and restart.
4. After logging back in, run Kerberos Ticket Manager, and use the Get Ticket button to get your non-AD principal's TGT.

With the steps above, everything worked, and me coworker is now able to see multiple principals/TGTs at once.

By the way, MIT Kerberos for Windows brings in its own set of command-line programs (like klist), and those programs support multiple credential caches. On my 64-bit system, when I run "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A" after getting multiple TGTs, I see my Active Directory principal in the MSLSA cache, and then I have one API cache for each additional principal.

P.S. This is my first entry on this site, so I wasn't able to add it as a comment to Toddius' answer. Apologies!