Lab 1 - Kerberos Tickets and Keytabs

The first lab teaches how to obtain and destroy tickets as well as working with a keytab.

Obtaining a Ticket

Log in to the test system with your ETH user name and ETH password for email.

Follow the instructions here to set up a minimal Kerberos configuration.

Now run

$ kinit

After entering the correct password the command should silently succeed. Check that you have a ticket:

$ klist

The output should be something like this:

Ticket cache: KEYRING:persistent:98765:krb_ccache_6Hwk5rk
Default principal: hmuster@D.ETHZ.CH

Valid starting       Expires              Service principal
02/23/2018 09:37:36  02/23/2018 19:37:36  krbtgt/D.ETHZ.CH@D.ETHZ.CH
	renew until 03/02/2018 09:37:35


  • Where is the ticket stored? Who can use it? Answer
    The ticket is stored in a location associated with your user ID. The ticket is shared among all of your processes.
  • When does the ticket expire?
  • Until when can it be renewed?
  • What could the service principal krbtgt/D.ETHZ.CH@D.ETHZ.CH mean? Answer
    The principal is for the ticket granting service of the D domain. The service handles service ticket requests. The ticket entitles you to get service tickets.

Renewing a Ticket

Run the following command

$ krenew

and then

$ klist

You should see that the expiration time has changed but the renew until time not.

Destroying a Ticket

Run the command

$ kdestroy

This destroys the ticket. For safety reasons you do not want tickets on a system unless they are needed.


$ klist

to make sure that the ticket is gone and the command fails.

Creating a Keytab

Follow the instructions here and create a keytab file for your ETH user name and store it in the local home directory on the test system as {your ETH user name}.keytab:

If you did everything right the following command will succeed:
$ klist -k -e -t {your ETH user name}.keytab

The output should be something like this:

Keytab name: FILE:hmuster.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   9 02/23/2018 10:01:43 hmuster@D.ETHZ.CH (aes128-cts-hmac-sha1-96)
   9 02/23/2018 10:01:43 hmuster@D.ETHZ.CH (aes256-cts-hmac-sha1-96)


  • How many entries for keys does your keytab file have?
  • What could the KVNO field mean and when does it change? Answer
    For users the KVNO changes every time the password changes. It shows you how many times you have changed your password.

Obtaining a Ticket Using a Keytab

Now that you have a keytab, obtain a ticket by running

$ kinit -k -t {your ETH user name}.keytab {your ETH user name}

The command should silently succeed. Please note that you were not asked for a password.


$ klist

again. You should see that you obtained a ticket.

Tickets on Managed Systems

Open an ssh connection to and run


This is an isginf managed system and obtains a ticket for you on login. Now run

env | grep KRB5CCNAME 

and you should see that the variable KRB5CCNAME is the same as the cache in the output of klist. The env variable KRB5CCNAME tells all Kerberos related tools where the ticket cache for this process is.


  • How many tickets do you see?
  • What is the other ticket for? Answer
    Your student home is used on optimus and is accessed by CIFS with Kerberos. The other ticket is the service ticket for accessing shares at \\nas-nethz-users.
  • Log out of optimus and log in again immediately. How many tickets do you have now? Answer
    When you log out the ticket cache of this session is destroyed. When you log in again a new cache is created. Your student home directory is only unmounted after a few minutes so there was no need for a service ticket to mount it.

Page URL:
© 2024 Eidgenössische Technische Hochschule Zürich