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.
The MIT Kerberos documentation states that...
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. eitherklist -c API:
or
set KRB5CCNAME=API:
klist
On the other hand, if you point
KRB5CCNAME
to aFILE:*****
then you cankinit
thenklist
the ticket; but it will not show in the UI and will not be available to web browsers and the like.