DevOps | Cloud | Analytics | Open Source | Programming





How To Manage Tickets in Kerberos ?


In this post, we will explore - How To Manage Tickets in Kerberos. Ticket Management is a crucial business in the Kerberos eco-system. In Kerberos, a ticket is an encrypted data structure that contains the client's identity, a session key, and other information. Tickets are issued by the Key Distribution Center (KDC) and are used to authenticate clients to servers. In a Kerberos system -

  • Tickets can be obtained automatically when you log in using a program that integrates with Kerberos.
  • Tickets can be forwarded to remote hosts using programs such as ssh
  • Tickets are typically automatically destroyed when the program that obtained them exits
  • It is recommended to explicitly destroy tickets when you are finished using them, to ensure that they are not left behind and potentially misused
  • The kdestroy command can be added to your .logout file to automatically destroy tickets when you log out
  • If you are concerned about an intruder using your permissions, you can destroy all copies of your tickets or use a screensaver that locks the screen
 

1. Key aspects of a Kerberos Ticket : 

Some key aspects of Kerberos Ticket are as given below. It is important to be aware of them when we manage the Tickets.

  • Session keys are used for authentication and are generated and distributed by the authentication server
  • Kerberos tickets contain session keys, the name of the principal they were issued to, and an expiration time and are used to distribute session keys to the verifier
  • Tickets are encrypted using the server key and are forwarded to the verifier by the client as part of the application request
  • A key distribution center (KDC) issues two types of tickets: a master ticket (also known as a ticket granting ticket or TGT) and a service ticket
    • Ticket Granting Ticket (TGT): A TGT is issued to a client by the KDC when the client authenticates to the KDC using their password. The TGT contains the client's identity and a session key that can be used to request other tickets. A KDC issues a TGT to a client, who can then request multiple service tickets using the TGT
    • Service Ticket: A service ticket is issued to a client by the KDC when the client presents a TGT and requests access to a particular service. The service ticket contains the client's identity, a session key that can be used to authenticate to the service, and the name of the service.
  The various cycles of a Kerberos Ticket Management are as follows.  

2. Creating The Ticket :

To create a ticket in Kerberos, the client must first authenticate to the KDC using their password. This is typically done using the kinit command-line tool. Once the client has authenticated, they can request tickets for specific services by sending a request to the KDC. The KDC will then issue the appropriate ticket, which the client can use to authenticate to the requested service.

  • To obtain a TGT, a client might run the following command:

kinit
  The client would then be prompted to enter their password, and the KDC would issue a TGT if the password is correct.  

  • To request a service ticket for a specific service, the client could use the kinit command with the -S option and the name of the service:

kinit -S service/host.example.com
  The KDC would then issue a service ticket that the client could use to authenticate to the specified service.  

  • To create a ticket with a specific lifetime, you can use the -l option followed by the desired lifetime in seconds, minutes, hours, or days.

    kinit -l 180m [email protected]
This command would create a ticket for the user jane in the realm EXAMPLE.COM with a lifetime of 180 minutes (three hours). Alternatively, you could specify the lifetime in seconds:


    kinit -l 10800 [email protected]
This command would create a ticket for the user sarah in the realm EXAMPLE.NET with a lifetime of 10,800 seconds (three hours).

   

  • To create a forwardable ticket, use the -f option. With a forwardable ticket, the user can log in to a second system and then use programs such as telnet to access a third system without having to enter their password again
The below creates a forwardable ticket with a lifetime of three hours for the user "xyz" in the realm ABC.ORG


 kinit -f -l 3h [email protected]
   

3. Viewing The Existing Tickets :

  • The klist command displays your current Kerberos tickets The ticket cache is the location of the file containing your tickets The default principal is your Kerberos username and realm The "valid starting" and "expires" fields show the time period during which the ticket is valid The "service principal" field describes each ticket, with the first component indicating the type of ticket (e.g. krbtgt for a ticket granting ticket) and the second component indicating the realm name
There are various Flags that you can use along with the klist command -

  • F: Forwardable - indicates that the ticket can be forwarded to another host
  • f: forwarded - indicates that the ticket has already been forwarded
  • P: Proxiable - indicates that the ticket can be used as a proxy for another user
  • p: proxy - indicates that the ticket is being used as a proxy for another user
  • D: postDateable - indicates that the ticket can be used after its expiration date
  • d: postdated - indicates that the ticket is being used after its expiration date
  • R: Renewable - indicates that the ticket can be renewed for another period of time
  • I: Initial - indicates that the ticket was issued by the authentication server
  • i: invalid - indicates that the ticket is no longer valid
  • H: Hardware authenticated - indicates that the ticket was authenticated by hardware, such as a smart card
  • A: preAuthenticated - indicates that the ticket was pre-authenticated by another method, such as a one-time password
  • T: Transit policy checked - indicates that the transit policy has been checked for this ticket
  • O: Okay as delegate - indicates that the ticket can be used to act as a delegate for another user
  • a: anonymous - indicates that the ticket is for an anonymous user
  When you first obtain tickets, you will have only the ticket-granting ticket. The listing would look like this:


$ klist 

Ticket cache: /tmp/krb5cc\_ttypa Default principal: [email protected]

Valid starting Expires Service principal 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/[email protected]
  The ticket cache is the location of your ticket file. In the above example, this file is named /tmp/krb5cc_ttypa. The default principal is your Kerberos principal. The "valid starting" and "expires" fields describe the period of time during which the ticket is valid. The "service principal" describes each ticket. The ticket-granting ticket has a first component krbtgt, and a second component which is the realm name. Now, if jennifer connected to the machine server1.example.com, and then typed "klist" again, she would have gotten the following result:


$ klist 

Ticket cache: /tmp/krb5cc\_ttypa Default principal: [email protected]

Valid starting Expires Service principal 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/[email protected] 06/07/04 20:22:30 06/08/04 05:49:19 host/[email protected]
Here's what happened: when jennifer used ssh to connect to the host server1.example.com, the ssh program presented her ticket-granting ticket to the KDC and requested a host ticket for the host server1.example.com. The KDC sent the host ticket, which ssh then presented to the host server1.example.com, and she was allowed to log in without typing her password. If jennifer wanted to log into a host in another domain, such as server2.example.com, which is also in another Kerberos realm, EXAMPLE.COM, she would need to request a ticket-granting ticket for the realm EXAMPLE.COM, as well as a new host ticket for server2.example.com. Upon successfully logging into the host, klist would show both of these tickets.


$ klist 

Ticket cache: /tmp/krb5cc\_ttypa Default principal: [email protected]

Valid starting Expires Service principal 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/[email protected] 06/07/04 20:22:30 06/08/04 05:49:19 host/[email protected] 06/07/04 20:24:18 06/08/04 05:49:19 krbtgt/[email protected] 06/07/04 20:24:18 06/08/04 05:49:19 host/
  Here is an example of how to use the klist command with the -e and -a options. In this example, the klist command shows that the user has a ticket-granting ticket (TGT) with the service principal krbtgt/[email protected]. The TGT has a session key and ticket encrypted with the AES256 encryption type. The TGT is also valid for use with the IP addresses :::1 (IPv6 loopback) and 127.0.0.1 (IPv4 loopback). The user also has a host ticket with the service principal `host/server1


$ klist -e -a
Ticket cache: FILE:/tmp/krb5cc\_1000
Default principal: [email protected]

Valid starting Expires Service principal
01/01/2022 10:00 01/01/2022 20:00 krbtgt/[email protected]
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Addresses: IPv6:::1, IPv4:127.0.0.1
01/01/2022 10:01 01/01/2022 20:00 host/[email protected]
Etype (skey, tkt): aes128-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96
Addresses: IPv4:10.0.0.1, IPv4:192.168.0.1
   

4. Destroying Kerberos Tickets :

You can destroy your Kerberos tickets by using the kdestroy command. But do note - It is important to note that destroying your tickets will not log you out of any systems that you are currently logged into. You will need to log out of those systems manually. To use the kdestroy command, simply type kdestroy at the command prompt. This will remove all your Kerberos tickets and log you out of the Kerberos system. Note that you will need to run the kinit command again to obtain new tickets if you want to use Kerberos services after running kdestroy. It is important to note that the kdestroy command only removes your tickets from your local system. If you have forwarded your tickets to another host, they will still be valid on that host until they expire. To fully log out of the Kerberos system, you will need to run kdestroy on all hosts where you have tickets.  

  • To destroy all tickets in the default ticket cache -

$ kdestroy
 

  • To destroy all tickets in the cache, specify a specific ticket cache to destroy tickets from by using the -c option. e.g. To destroy all tickets in the cache /tmp/krb5cc_xyz, you would type:

$ kdestroy -c /tmp/krb5cc\_xyz
    Hope this helps.    

Additional Posts you might want to read from this Blog -

   


How to request a ticket from a Kerberos server ,How to renew a ticket before it expires ,How to destroy a ticket when it is no longer needed ,How to view the details of a ticket, including its expiration time and the services it allows access to ,How to troubleshoot issues with ticket management, such as receiving an "invalid ticket" error ,How to use klist, a command-line tool for managing tickets in Kerberos ,How to use the Ticket Granting Service (TGS) to request tickets for specific network services ,How to configure ticket lifetime and renewal settings in the Kerberos server ,where are kerberos tickets stored on the local system ,kinit ,mit kerberos ticket manager ,kerberos authentication ,mit kerberos ticket manager windows download ,kerberos commands ,klist ,kerberos keytab ,Kerberos tickets , ticket management , Kerberos authentication , kinit , klist , kdestroy , Managing Kerberos tickets ,Using kinit to obtain tickets ,Viewing tickets with klist ,Destroying tickets with kdestroy ,Forwarding tickets with kinit ,Setting ticket lifetime with kinit ,Displaying encryption types with klist ,Protecting against ticket theft ,Managing Kerberos tickets ,Secure ticket management in Kerberos ,Obtaining, viewing, and destroying tickets in Kerberos ,Using kinit and kdestroy to manage tickets in Kerberos ,How to protect your Kerberos tickets from unauthorized access ,Best practices for managing tickets in Kerberos ,Secure ticket management in a Kerberos environment ,Where does Kerberos store tickets? ,How do I create a ticket in Kerberos? ,What is ticket in Kerberos? ,What are the two types of tickets issued in Kerberos? ,