Since Kerberos tickets are only validated after 20 minutes (for Kerberos service ticket, TGS), an attacker has more than enough time to access data and/or resources. If not, the attacker can always generate a new “Golden” TGT. Audit Kerberos Authentication Service determines whether to generate audit events for Kerberos authentication ticket-granting ticket (TGT) requests. If you configure this policy setting, an audit event is generated after a Kerberos authentication TGT request. Success audits record successful attempts and Failure audits record unsuccessful attempts.
On many systems, Kerberos is built into the login program, and you gettickets automatically when you log in. Other programs, such as ssh,can forward copies of your tickets to a remote host. Most of theseprograms also automatically destroy your tickets when they exit.However, MIT recommends that you explicitly destroy your Kerberostickets when you are through with them, just to be sure. One way tohelp ensure that this happens is to add the kdestroy commandto your .logout file. Additionally, if you are going to be away fromyour machine and are concerned about an intruder using yourpermissions, it is safest to either destroy all copies of yourtickets, or use a screensaver that locks the screen.
While processing a TGS request for the target server%1, the account%2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of%3). The requested etypes were%4. The accounts available etypes were%5. Changing or resetting the password of%6 will generate a proper key. While processing an AS request for target service krbtgt, the account Administrator did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes: 18 3. The accounts available etypes: 23 -133 -128. Changing or resetting the password of Administrator will generate a proper key.
Kerberos ticket properties¶
There are various properties that Kerberos tickets can have:
If a ticket is forwardable, then the KDC can issue a new ticket(with a different network address, if necessary) based on theforwardable ticket. This allows for authentication forwarding withoutrequiring a password to be typed in again. For example, if a userwith a forwardable TGT logs into a remote system, the KDC could issuea new TGT for that user with the netword address of the remote system,allowing authentication on that host to work as though the user werelogged in locally.
When the KDC creates a new ticket based on a forwardable ticket, itsets the forwarded flag on that new ticket. Any tickets that arecreated based on a ticket with the forwarded flag set will also havetheir forwarded flags set.
A proxiable ticket is similar to a forwardable ticket in that itallows a service to take on the identity of the client. Unlike aforwardable ticket, however, a proxiable ticket is only issued forspecific services. In other words, a ticket-granting ticket cannot beissued based on a ticket that is proxiable but not forwardable.
A proxy ticket is one that was issued based on a proxiable ticket.
A postdated ticket is issued with the invalid flag set. After thestarting time listed on the ticket, it can be presented to the KDC toobtain valid tickets.
Ticket-granting tickets with the postdateable flag set can be usedto obtain postdated service tickets.
Renewable tickets can be used to obtain new session keys withoutthe user entering their password again. A renewable ticket has twoexpiration times. The first is the time at which this particularticket expires. The second is the latest possible expiration time forany ticket issued based on this renewable ticket.
A ticket with the initial flag set was issued based on theauthentication protocol, and not on a ticket-granting ticket.Application servers that wish to ensure that the user’s key has beenrecently presented for verification could specify that this flag mustbe set to accept the ticket.
An invalid ticket must be rejected by application servers.Postdated tickets are usually issued with this flag set, and must bevalidated by the KDC before they can be used.
A preauthenticated ticket is one that was only issued after theclient requesting the ticket had authenticated itself to the KDC.
The hardware authentication flag is set on a ticket which requiredthe use of hardware for authentication. The hardware is expected tobe possessed only by the client which requested the tickets.
If a ticket has the transit policy checked flag set, then the KDCthat issued this ticket implements the transited-realm check policyand checked the transited-realms list on the ticket. Thetransited-realms list contains a list of all intermediate realmsbetween the realm of the KDC that issued the first ticket and that ofthe one that issued the current ticket. If this flag is not set, thenthe application server must check the transited realms itself or elsereject the ticket.
The okay as delegate flag indicates that the server specified inthe ticket is suitable as a delegate as determined by the policy ofthat realm. Some client applications may use this flag to decidewhether to forward tickets to a remote host, although manyapplications do not honor it.
An anonymous ticket is one in which the named principal is ageneric principal for that realm; it does not actually specify theindividual that will be using the ticket. This ticket is meant onlyto securely distribute a session key.
Obtaining tickets with kinit¶
Scom Alert No Key To Generate Kerberos Ticket
If your site has integrated Kerberos V5 with the login system, youwill get Kerberos tickets automatically when you log in. Otherwise,you may need to explicitly obtain your Kerberos tickets, using thekinit program. Similarly, if your Kerberos tickets expire,use the kinit program to obtain new ones.
To use the kinit program, simply type kinit and then type yourpassword at the prompt. For example, Jennifer (whose username isjennifer) works for Bleep, Inc. (a fictitious company with thedomain name mit.edu and the Kerberos realm ATHENA.MIT.EDU). She wouldtype:
If you type your password incorrectly, kinit will give you thefollowing error message:
No Key To Generate Kerberos Tickets
and you won’t get Kerberos tickets.
By default, kinit assumes you want tickets for your own username inyour default realm. Suppose Jennifer’s friend David is visiting, andhe wants to borrow a window to check his mail. David needs to gettickets for himself in his own realm, EXAMPLE.COM. He would type:
David would then have tickets which he could use to log onto his ownmachine. Note that he typed his password locally on Jennifer’smachine, but it never went over the network. Kerberos on the localhost performed the authentication to the KDC in the other realm.
If you want to be able to forward your tickets to another host, youneed to request forwardable tickets. You do this by specifying the-f option:
Note that kinit does not tell you that it obtained forwardabletickets; you can verify this using the klist command (seeViewing tickets with klist).
Normally, your tickets are good for your system’s default ticketlifetime, which is ten hours on many systems. You can specify adifferent ticket lifetime with the -l option. Add the letters to the value for seconds, m for minutes, h for hours, ord for days. For example, to obtain forwardable tickets for[email protected] that would be good for three hours, you wouldtype:
Note
You cannot mix units; specifying a lifetime of 3h30m wouldresult in an error. Note also that most systems specify amaximum ticket lifetime. If you request a longer ticketlifetime, it will be automatically truncated to the maximumlifetime.
Viewing tickets with klist¶
The klist command shows your tickets. When you first obtaintickets, you will have only the ticket-granting ticket. The listingwould look like this:
The ticket cache is the location of your ticket file. In the aboveexample, this file is named /tmp/krb5cc_ttypa. The defaultprincipal is your Kerberos principal.
The “valid starting” and “expires” fields describe the period of timeduring which the ticket is valid. The “service principal” describeseach ticket. The ticket-granting ticket has a first componentkrbtgt, and a second component which is the realm name.
Now, if jennifer connected to the machine daffodil.mit.edu,and then typed “klist” again, she would have gotten the followingresult:
Here’s what happened: when jennifer used ssh to connect to thehost daffodil.mit.edu, the ssh program presented herticket-granting ticket to the KDC and requested a host ticket for thehost daffodil.mit.edu. The KDC sent the host ticket, which sshthen presented to the host daffodil.mit.edu, and she was allowedto log in without typing her password.
Suppose your Kerberos tickets allow you to log into a host in anotherdomain, such as trillium.example.com, which is also in anotherKerberos realm, EXAMPLE.COM. If you ssh to this host, you willreceive a ticket-granting ticket for the realm EXAMPLE.COM, plusthe new host ticket for trillium.example.com. klist will nowshow:
Depending on your host’s and realm’s configuration, you may also see aticket with the service principal host/trillium.example.com@. Ifso, this means that your host did not know what realmtrillium.example.com is in, so it asked the ATHENA.MIT.EDU KDC fora referral. The next time you connect to trillium.example.com,the odd-looking entry will be used to avoid needing to ask for areferral again.
You can use the -f option to view the flags that apply to yourtickets. The flags are:
F | Forwardable |
f | forwarded |
P | Proxiable |
p | proxy |
D | postDateable |
d | postdated |
R | Renewable |
I | Initial |
i | invalid |
H | Hardware authenticated |
A | preAuthenticated |
T | Transit policy checked |
O | Okay as delegate |
a | anonymous |
Here is a sample listing. In this example, the user jenniferobtained her initial tickets (I), which are forwardable (F)and postdated (d) but not yet validated (i):
In the following example, the user david‘s tickets were forwarded(f) to this host from another host. The tickets are reforwardable(F):
Destroying tickets with kdestroy¶
Your Kerberos tickets are proof that you are indeed yourself, andtickets could be stolen if someone gains access to a computer wherethey are stored. If this happens, the person who has them canmasquerade as you until they expire. For this reason, you shoulddestroy your Kerberos tickets when you are away from your computer.
Destroying your tickets is easy. Simply type kdestroy:
If kdestroy fails to destroy your tickets, it will beep andgive an error message. For example, if kdestroy can’t find anytickets to destroy, it will give the following message: