Multiple Realms and Multiple TGTs under MIT Kerberos for Windows

Solution 1:

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.

Solution 2:

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

Solution 3:

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.

Solution 4:

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!

Tags:

Kerberos

Recent Posts