Kerberos: kinit on Windows 8.1 leads to empty ticket cache

Question

I installed Kerberos for Windows on a new set-up Windows 8.1 machine.

• Domain: not set
• Workgroup: WORKGROUP

I edited the krb5.ini file in C:\ProgramData\MIT\Kerberos5 directory like this:

[libdefaults]
  default_realm = HSHADOOPCLUSTER.DE

[realms]
  HSHADOOPCLUSTER.DE = {
    admin_server = had-job.server.de
    kdc = had-job.server.de
  }

After a restart, I made a kinit -kt daniel.keytab daniel to authenticate me against the Realm via console. Also getting a ticket by user and password via the Kerberos Ticket Manager seems to work fine, as the ticket is shown in the UI.

What I'm wondering about is, that when I call a klist I get an empty list back, which says something like cached tickets: 0:

This seems not normal to me, as my Ubuntu computer shows valid tickets by klist after a kinit.

What am I doing wrong? Is there some more configuration to do? Sometimes I read about a ksetup tool, but I don't know which settings here are neccessary and which not...

============================================================

After I set

[libdefaults] 
  ... 
  default_ccache_name = FILE:C:/ProgramData/Kerberos/krb5cc_%{uid}

in my krb5.conf, the kinit command via console and via Kerberos Ticket Manager creates a file in the specified path. So far everything looks good.

But: The kinit command creates tickets with very different file names (long vs. short), depending if I run the console as "admin" (short name) or not (long name), see the screenshot below. The Kerberos Ticket Manager only shows one of the tickets:

• If run as admin:
  • Shows the ticket I created via admin console
  • Creates ticket files with short file names
• If run as normal:
  • Shows the ticket I created via "normal" console
  • Creates ticket files with long file names

The klist command still doesn't show the cached tickets, independent if console was opened as admin or not.

Answer 1

The MIT Kerberos documentation states that...

There are several kinds of credentials cache supported in the MIT Kerberos library. Not all are supported on every platform ...

• FILE caches are the simplest and most portable. A simple flat file format is used to store one credential after another. This is the default...
  
• API is only implemented on Windows. It communicates with a server process that holds the credentials in memory...
  
  The default credential cache name is determined by ...
  
• The KRB5CCNAMEenvironment variable...
  
• The default_ccache_name profile variable in [libdefaults]
  
• The hardcoded default, DEFCCNAME

But AFAIK, on Windows the hard-coded default cache is API: and that's what you can manage with the UI. kinit also uses that protocol by default.

I personally never could use klist to use that protocol, even with the "standard" syntax i.e. either
  klist -c API:
or
  set KRB5CCNAME=API:
  klist

On the other hand, if you point KRB5CCNAME to a FILE:***** then you can kinit then klist the ticket; but it will not show in the UI and will not be available to web browsers and the like.

---

If klist command doesn't show the keys even after setting environment variable like KRB5CCNAME (i.e. set KRB5CCNAME=C:\kerberos_cache\cache\krb5cache, its a file not a directory. You'll have to create parent directory manually), then chances are that the klist command that you're running is not from MIT Kerberos Windows installation in C:\Program Files\MIT\Kerberos\bin but rather the klist command from Windows itself in C:\Windows\system32.

You can check that out by running which klist if you have cygwin tools. In this case, simplest solution is to copy klist.exe into MIT Kerberos installation's bin directory as a new file i.e. klist_mit.exe. Cache entries should be shown if you run klist_mit command.