Kerberos: kinit on Windows 8.1 leads to empty ticket cache - windows-authentication

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.