4 .. note:: This document was copied from **Kerberos V5 UNIX User's
5 Guide**. Currently it is under review. Please, send your
6 feedback, corrections and additions to krb5-bugs@mit.edu.
7 Your contribution is greatly appreciated.
9 On many systems, Kerberos is built into the login program, and you get
10 tickets automatically when you log in. Other programs, such as ssh,
11 can forward copies of your tickets to the. Most of these programs
12 also automatically destroy your tickets when they exit. However, MIT
13 recommends that you explicitly destroy your Kerberos tickets when you
14 are through with them, just to be sure. One way to help ensure that
15 this happens is to add the :ref:`kdestroy(1)` command to your .logout
16 file. Additionally, if you are going to be away from your machine and
17 are concerned about an intruder using your permissions, it is safest
18 to either destroy all copies of your tickets, or use a screensaver
19 that locks the screen.
22 Kerberos ticket properties
23 --------------------------
25 There are various properties that Kerberos tickets can have:
27 If a ticket is **forwardable**, then the KDC can issue a new ticket
28 with a different network address based on the forwardable ticket.
29 This allows for authentication forwarding without requiring a password
30 to be typed in again. For example, if a user with a forwardable TGT
31 logs into a remote system, the KDC could issue a new TGT for that user
32 with the netword address of the remote system, allowing authentication
33 on that host to work as though the user were logged in locally.
35 When the KDC creates a new ticket based on a forwardable ticket, it
36 sets the **forwarded** flag on that new ticket. Any tickets that are
37 created based on a ticket with the forwarded flag set will also have
38 their forwarded flags set.
40 A **proxiable** ticket is similar to a forwardable ticket in that it
41 allows a service to take on the identity of the client. Unlike a
42 forwardable ticket, however, a proxiable ticket is only issued for
43 specific services. In other words, a ticket-granting ticket cannot be
44 issued based on a ticket that is proxiable but not forwardable.
46 A **proxy** ticket is one that was issued based on a proxiable ticket.
48 A **postdated** ticket is issued with the invalid flag set. After the
49 starting time listed on the ticket, it can be presented to the KDC to
52 Tickets with the **postdateable** flag set can be used to issue
55 **Renewable** tickets can be used to obtain new session keys without
56 the user entering their password again. A renewable ticket has two
57 expiration times. The first is the time at which this particular
58 ticket expires. The second is the latest possible expiration time for
59 any ticket issued based on this renewable ticket.
61 A ticket with the **initial flag** set was issued based on the
62 authentication protocol, and not on a ticket-granting ticket. Clients
63 that wish to ensure that the user's key has been recently presented
64 for verification could specify that this flag must be set to accept
67 An **invalid** ticket must be rejected by application servers.
68 Postdated tickets are usually issued with this flag set, and must be
69 validated by the KDC before they can be used.
71 A **preauthenticated** ticket is one that was only issued after the
72 client requesting the ticket had authenticated itself to the KDC.
74 The **hardware authentication** flag is set on a ticket which required
75 the use of hardware for authentication. The hardware is expected to
76 be possessed only by the client which requested the tickets.
78 If a ticket has the **transit policy** checked flag set, then the KDC
79 that issued this ticket implements the transited-realm check policy
80 and checked the transited-realms list on the ticket. The
81 transited-realms list contains a list of all intermediate realms
82 between the realm of the KDC that issued the first ticket and that of
83 the one that issued the current ticket. If this flag is not set, then
84 the application server must check the transited realms itself or else
87 The okay as **delegate** flag indicates that the server specified in
88 the ticket is suitable as a delegate as determined by the policy of
89 that realm. A server that is acting as a delegate has been granted a
90 proxy or a forwarded TGT. This flag is a new addition to the Kerberos
91 V5 protocol and is not yet implemented on MIT servers.
93 An **anonymous** ticket is one in which the named principal is a
94 generic principal for that realm; it does not actually specify the
95 individual that will be using the ticket. This ticket is meant only
96 to securely distribute a session key. This is a new addition to the
97 Kerberos V5 protocol and is not yet implemented on MIT servers.
102 Obtaining tickets with kinit
103 ----------------------------
105 If your site has integrated Kerberos V5 with the login system, you
106 will get Kerberos tickets automatically when you log in. Otherwise,
107 you may need to explicitly obtain your Kerberos tickets, using the
108 :ref:`kinit(1)` program. Similarly, if your Kerberos tickets expire,
109 use the kinit program to obtain new ones.
111 To use the kinit program, simply type ``kinit`` and then type your
112 password at the prompt. For example, Jennifer (whose username is
113 ``jennifer``) works for Bleep, Inc. (a fictitious company with the
114 domain name mit.edu and the Kerberos realm ATHENA.MIT.EDU). She would
118 Password for jennifer@ATHENA.MIT.EDU: <-- [Type jennifer's password here.]
121 If you type your password incorrectly, kinit will give you the
122 following error message::
125 Password for jennifer@ATHENA.MIT.EDU: <-- [Type the wrong password here.]
126 kinit: Password incorrect
129 and you won't get Kerberos tickets.
131 By default, kinit assumes you want tickets for your own username in
132 your default realm. Suppose Jennifer's friend David is visiting, and
133 he wants to borrow a window to check his mail. David needs to get
134 tickets for himself in his own realm, EXAMPLE.COM [1]_. He would
137 shell% kinit david@EXAMPLE.COM
138 Password for david@EXAMPLE.COM: <-- [Type david's password here.]
141 David would then have tickets which he could use to log onto his own
142 machine. Note that he typed his password locally on Jennifer's
143 machine, but it never went over the network. Kerberos on the local
144 host performed the authentication to the KDC in the other realm.
146 If you want to be able to forward your tickets to another host, you
147 need to request forwardable tickets. You do this by specifying the
151 Password for jennifer@ATHENA.MIT.EDU: <-- [Type your password here.]
154 Note that kinit does not tell you that it obtained forwardable
155 tickets; you can verify this using the :ref:`klist(1)` command (see
158 Normally, your tickets are good for your system's default ticket
159 lifetime, which is ten hours on many systems. You can specify a
160 different ticket lifetime with the **-l** option. Add the letter
161 **s** to the value for seconds, **m** for minutes, **h** for hours, or
162 **d** for days. For example, to obtain forwardable tickets for
163 ``david@EXAMPLE.COM`` that would be good for three hours, you would
166 shell% kinit -f -l 3h david@EXAMPLE.COM
167 Password for david@EXAMPLE.COM: <-- [Type david's password here.]
170 .. note:: You cannot mix units; specifying a lifetime of 3h30m would
171 result in an error. Note also that most systems specify a
172 maximum ticket lifetime. If you request a longer ticket
173 lifetime, it will be automatically truncated to the maximum
176 .. [1] Note: the realm EXAMPLE.COM must be listed in your computer's
177 Kerberos configuration file, :ref:`krb5.conf(5)`.
182 Viewing tickets with klist
183 --------------------------
185 The :ref:`klist(1)` command shows your tickets. When you first obtain
186 tickets, you will have only the ticket-granting ticket. The listing
187 would look like this::
190 Ticket cache: /tmp/krb5cc_ttypa
191 Default principal: jennifer@ATHENA.MIT.EDU
193 Valid starting Expires Service principal
194 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
197 The ticket cache is the location of your ticket file. In the above
198 example, this file is named ``/tmp/krb5cc_ttypa``. The default
199 principal is your Kerberos principal.
201 The "valid starting" and "expires" fields describe the period of time
202 during which the ticket is valid. The "service principal" describes
203 each ticket. The ticket-granting ticket has a first component
204 ``krbtgt``, and a second component which is the realm name.
206 Now, if ``jennifer`` connected to the machine ``daffodil.mit.edu``,
207 and then typed "klist" again, she would have gotten the following
211 Ticket cache: /tmp/krb5cc_ttypa
212 Default principal: jennifer@ATHENA.MIT.EDU
214 Valid starting Expires Service principal
215 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
216 06/07/04 20:22:30 06/08/04 05:49:19 host/daffodil.mit.edu@ATHENA.MIT.EDU
219 Here's what happened: when ``jennifer`` used ssh to connect to the
220 host ``daffodil.mit.edu``, the ssh program presented her
221 ticket-granting ticket to the KDC and requested a host ticket for the
222 host ``daffodil.mit.edu``. The KDC sent the host ticket, which ssh
223 then presented to the host ``daffodil.mit.edu``, and she was allowed
224 to log in without typing her password.
226 Suppose your Kerberos tickets allow you to log into a host in another
227 domain, such as ``trillium.example.com``, which is also in another
228 Kerberos realm, ``EXAMPLE.COM``. If you ssh to this host, you will
229 receive a ticket-granting ticket for the realm ``EXAMPLE.COM``, plus
230 the new host ticket for ``trillium.example.com``. klist will now
234 Ticket cache: /tmp/krb5cc_ttypa
235 Default principal: jennifer@ATHENA.MIT.EDU
237 Valid starting Expires Service principal
238 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
239 06/07/04 20:22:30 06/08/04 05:49:19 host/daffodil.mit.edu@ATHENA.MIT.EDU
240 06/07/04 20:24:18 06/08/04 05:49:19 krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU
241 06/07/04 20:24:18 06/08/04 05:49:19 host/trillium.example.com@EXAMPLE.COM
244 Depending on your host's and realm's configuration, you may also see a
245 ticket with the service principal ``host/trillium.example.com@``. If
246 so, this means that your host did not know what realm
247 trillium.example.com is in, so it asked the ``ATHENA.MIT.EDU`` KDC for
248 a referral. The next time you connect to ``trillium.example.com``,
249 the odd-looking entry will be used to avoid needing to ask for a
252 You can use the **-f** option to view the flags that apply to your
253 tickets. The flags are:
255 ===== =========================
265 H Hardware authenticated
267 T Transit policy checked
270 ===== =========================
272 Here is a sample listing. In this example, the user *jennifer*
273 obtained her initial tickets (**I**), which are forwardable (**F**)
274 and postdated (**d**) but not yet validated (**i**)::
277 Ticket cache: /tmp/krb5cc_320
278 Default principal: jennifer@ATHENA.MIT.EDU
280 Valid starting Expires Service principal
281 31/07/05 19:06:25 31/07/05 19:16:25 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU
285 In the following example, the user *david*'s tickets were forwarded
286 (**f**) to this host from another host. The tickets are reforwardable
290 Ticket cache: /tmp/krb5cc_p11795
291 Default principal: david@EXAMPLE.COM
293 Valid starting Expires Service principal
294 07/31/05 11:52:29 07/31/05 21:11:23 krbtgt/EXAMPLE.COM@EXAMPLE.COM
296 07/31/05 12:03:48 07/31/05 21:11:23 host/trillium.example.com@EXAMPLE.COM
301 Destroying tickets with kdestroy
302 --------------------------------
304 Your Kerberos tickets are proof that you are indeed yourself, and
305 tickets can be stolen. If this happens, the person who has them can
306 masquerade as you until they expire. For this reason, you should
307 destroy your Kerberos tickets when you are away from your computer.
309 Destroying your tickets is easy. Simply type kdestroy::
314 If :ref:`kdestroy(1)` fails to destroy your tickets, it will beep and
315 give an error message. For example, if kdestroy can't find any
316 tickets to destroy, it will give the following message::
319 kdestroy: No credentials cache file found while destroying cache