1Ticket management 2================= 3 4On many systems, Kerberos is built into the login program, and you get 5tickets automatically when you log in. Other programs, such as ssh, 6can forward copies of your tickets to a remote host. Most of these 7programs also automatically destroy your tickets when they exit. 8However, MIT recommends that you explicitly destroy your Kerberos 9tickets when you are through with them, just to be sure. One way to 10help ensure that this happens is to add the :ref:`kdestroy(1)` command 11to your .logout file. Additionally, if you are going to be away from 12your machine and are concerned about an intruder using your 13permissions, it is safest to either destroy all copies of your 14tickets, or use a screensaver that locks the screen. 15 16 17Kerberos ticket properties 18-------------------------- 19 20There are various properties that Kerberos tickets can have: 21 22If a ticket is **forwardable**, then the KDC can issue a new ticket 23(with a different network address, if necessary) based on the 24forwardable ticket. This allows for authentication forwarding without 25requiring a password to be typed in again. For example, if a user 26with a forwardable TGT logs into a remote system, the KDC could issue 27a new TGT for that user with the network address of the remote system, 28allowing authentication on that host to work as though the user were 29logged in locally. 30 31When the KDC creates a new ticket based on a forwardable ticket, it 32sets the **forwarded** flag on that new ticket. Any tickets that are 33created based on a ticket with the forwarded flag set will also have 34their forwarded flags set. 35 36A **proxiable** ticket is similar to a forwardable ticket in that it 37allows a service to take on the identity of the client. Unlike a 38forwardable ticket, however, a proxiable ticket is only issued for 39specific services. In other words, a ticket-granting ticket cannot be 40issued based on a ticket that is proxiable but not forwardable. 41 42A **proxy** ticket is one that was issued based on a proxiable ticket. 43 44A **postdated** ticket is issued with the invalid flag set. After the 45starting time listed on the ticket, it can be presented to the KDC to 46obtain valid tickets. 47 48Ticket-granting tickets with the **postdateable** flag set can be used 49to obtain postdated service tickets. 50 51**Renewable** tickets can be used to obtain new session keys without 52the user entering their password again. A renewable ticket has two 53expiration times. The first is the time at which this particular 54ticket expires. The second is the latest possible expiration time for 55any ticket issued based on this renewable ticket. 56 57A ticket with the **initial flag** set was issued based on the 58authentication protocol, and not on a ticket-granting ticket. 59Application servers that wish to ensure that the user's key has been 60recently presented for verification could specify that this flag must 61be set to accept the ticket. 62 63An **invalid** ticket must be rejected by application servers. 64Postdated tickets are usually issued with this flag set, and must be 65validated by the KDC before they can be used. 66 67A **preauthenticated** ticket is one that was only issued after the 68client requesting the ticket had authenticated itself to the KDC. 69 70The **hardware authentication** flag is set on a ticket which required 71the use of hardware for authentication. The hardware is expected to 72be possessed only by the client which requested the tickets. 73 74If a ticket has the **transit policy** checked flag set, then the KDC 75that issued this ticket implements the transited-realm check policy 76and checked the transited-realms list on the ticket. The 77transited-realms list contains a list of all intermediate realms 78between the realm of the KDC that issued the first ticket and that of 79the one that issued the current ticket. If this flag is not set, then 80the application server must check the transited realms itself or else 81reject the ticket. 82 83The **okay as delegate** flag indicates that the server specified in 84the ticket is suitable as a delegate as determined by the policy of 85that realm. Some client applications may use this flag to decide 86whether to forward tickets to a remote host, although many 87applications do not honor it. 88 89An **anonymous** ticket is one in which the named principal is a 90generic principal for that realm; it does not actually specify the 91individual that will be using the ticket. This ticket is meant only 92to securely distribute a session key. 93 94 95.. _obtain_tkt: 96 97Obtaining tickets with kinit 98---------------------------- 99 100If your site has integrated Kerberos V5 with the login system, you 101will get Kerberos tickets automatically when you log in. Otherwise, 102you may need to explicitly obtain your Kerberos tickets, using the 103:ref:`kinit(1)` program. Similarly, if your Kerberos tickets expire, 104use the kinit program to obtain new ones. 105 106To use the kinit program, simply type ``kinit`` and then type your 107password at the prompt. For example, Jennifer (whose username is 108``jennifer``) works for Bleep, Inc. (a fictitious company with the 109domain name mit.edu and the Kerberos realm ATHENA.MIT.EDU). She would 110type:: 111 112 shell% kinit 113 Password for jennifer@ATHENA.MIT.EDU: <-- [Type jennifer's password here.] 114 shell% 115 116If you type your password incorrectly, kinit will give you the 117following error message:: 118 119 shell% kinit 120 Password for jennifer@ATHENA.MIT.EDU: <-- [Type the wrong password here.] 121 kinit: Password incorrect 122 shell% 123 124and you won't get Kerberos tickets. 125 126By default, kinit assumes you want tickets for your own username in 127your default realm. Suppose Jennifer's friend David is visiting, and 128he wants to borrow a window to check his mail. David needs to get 129tickets for himself in his own realm, EXAMPLE.COM. He would type:: 130 131 shell% kinit david@EXAMPLE.COM 132 Password for david@EXAMPLE.COM: <-- [Type david's password here.] 133 shell% 134 135David would then have tickets which he could use to log onto his own 136machine. Note that he typed his password locally on Jennifer's 137machine, but it never went over the network. Kerberos on the local 138host performed the authentication to the KDC in the other realm. 139 140If you want to be able to forward your tickets to another host, you 141need to request forwardable tickets. You do this by specifying the 142**-f** option:: 143 144 shell% kinit -f 145 Password for jennifer@ATHENA.MIT.EDU: <-- [Type your password here.] 146 shell% 147 148Note that kinit does not tell you that it obtained forwardable 149tickets; you can verify this using the :ref:`klist(1)` command (see 150:ref:`view_tkt`). 151 152Normally, your tickets are good for your system's default ticket 153lifetime, which is ten hours on many systems. You can specify a 154different ticket lifetime with the **-l** option. Add the letter 155**s** to the value for seconds, **m** for minutes, **h** for hours, or 156**d** for days. For example, to obtain forwardable tickets for 157``david@EXAMPLE.COM`` that would be good for three hours, you would 158type:: 159 160 shell% kinit -f -l 3h david@EXAMPLE.COM 161 Password for david@EXAMPLE.COM: <-- [Type david's password here.] 162 shell% 163 164.. note:: 165 166 You cannot mix units; specifying a lifetime of 3h30m would 167 result in an error. Note also that most systems specify a 168 maximum ticket lifetime. If you request a longer ticket 169 lifetime, it will be automatically truncated to the maximum 170 lifetime. 171 172 173.. _view_tkt: 174 175Viewing tickets with klist 176-------------------------- 177 178The :ref:`klist(1)` command shows your tickets. When you first obtain 179tickets, you will have only the ticket-granting ticket. The listing 180would look like this:: 181 182 shell% klist 183 Ticket cache: /tmp/krb5cc_ttypa 184 Default principal: jennifer@ATHENA.MIT.EDU 185 186 Valid starting Expires Service principal 187 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU 188 shell% 189 190The ticket cache is the location of your ticket file. In the above 191example, this file is named ``/tmp/krb5cc_ttypa``. The default 192principal is your Kerberos principal. 193 194The "valid starting" and "expires" fields describe the period of time 195during which the ticket is valid. The "service principal" describes 196each ticket. The ticket-granting ticket has a first component 197``krbtgt``, and a second component which is the realm name. 198 199Now, if ``jennifer`` connected to the machine ``daffodil.mit.edu``, 200and then typed "klist" again, she would have gotten the following 201result:: 202 203 shell% klist 204 Ticket cache: /tmp/krb5cc_ttypa 205 Default principal: jennifer@ATHENA.MIT.EDU 206 207 Valid starting Expires Service principal 208 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU 209 06/07/04 20:22:30 06/08/04 05:49:19 host/daffodil.mit.edu@ATHENA.MIT.EDU 210 shell% 211 212Here's what happened: when ``jennifer`` used ssh to connect to the 213host ``daffodil.mit.edu``, the ssh program presented her 214ticket-granting ticket to the KDC and requested a host ticket for the 215host ``daffodil.mit.edu``. The KDC sent the host ticket, which ssh 216then presented to the host ``daffodil.mit.edu``, and she was allowed 217to log in without typing her password. 218 219Suppose your Kerberos tickets allow you to log into a host in another 220domain, such as ``trillium.example.com``, which is also in another 221Kerberos realm, ``EXAMPLE.COM``. If you ssh to this host, you will 222receive a ticket-granting ticket for the realm ``EXAMPLE.COM``, plus 223the new host ticket for ``trillium.example.com``. klist will now 224show:: 225 226 shell% klist 227 Ticket cache: /tmp/krb5cc_ttypa 228 Default principal: jennifer@ATHENA.MIT.EDU 229 230 Valid starting Expires Service principal 231 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU 232 06/07/04 20:22:30 06/08/04 05:49:19 host/daffodil.mit.edu@ATHENA.MIT.EDU 233 06/07/04 20:24:18 06/08/04 05:49:19 krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU 234 06/07/04 20:24:18 06/08/04 05:49:19 host/trillium.example.com@EXAMPLE.COM 235 shell% 236 237Depending on your host's and realm's configuration, you may also see a 238ticket with the service principal ``host/trillium.example.com@``. If 239so, this means that your host did not know what realm 240trillium.example.com is in, so it asked the ``ATHENA.MIT.EDU`` KDC for 241a referral. The next time you connect to ``trillium.example.com``, 242the odd-looking entry will be used to avoid needing to ask for a 243referral again. 244 245You can use the **-f** option to view the flags that apply to your 246tickets. The flags are: 247 248===== ========================= 249 F Forwardable 250 f forwarded 251 P Proxiable 252 p proxy 253 D postDateable 254 d postdated 255 R Renewable 256 I Initial 257 i invalid 258 H Hardware authenticated 259 A preAuthenticated 260 T Transit policy checked 261 O Okay as delegate 262 a anonymous 263===== ========================= 264 265Here is a sample listing. In this example, the user *jennifer* 266obtained her initial tickets (**I**), which are forwardable (**F**) 267and postdated (**d**) but not yet validated (**i**):: 268 269 shell% klist -f 270 Ticket cache: /tmp/krb5cc_320 271 Default principal: jennifer@ATHENA.MIT.EDU 272 273 Valid starting Expires Service principal 274 31/07/05 19:06:25 31/07/05 19:16:25 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU 275 Flags: FdiI 276 shell% 277 278In the following example, the user *david*'s tickets were forwarded 279(**f**) to this host from another host. The tickets are reforwardable 280(**F**):: 281 282 shell% klist -f 283 Ticket cache: /tmp/krb5cc_p11795 284 Default principal: david@EXAMPLE.COM 285 286 Valid starting Expires Service principal 287 07/31/05 11:52:29 07/31/05 21:11:23 krbtgt/EXAMPLE.COM@EXAMPLE.COM 288 Flags: Ff 289 07/31/05 12:03:48 07/31/05 21:11:23 host/trillium.example.com@EXAMPLE.COM 290 Flags: Ff 291 shell% 292 293 294Destroying tickets with kdestroy 295-------------------------------- 296 297Your Kerberos tickets are proof that you are indeed yourself, and 298tickets could be stolen if someone gains access to a computer where 299they are stored. If this happens, the person who has them can 300masquerade as you until they expire. For this reason, you should 301destroy your Kerberos tickets when you are away from your computer. 302 303Destroying your tickets is easy. Simply type kdestroy:: 304 305 shell% kdestroy 306 shell% 307 308If :ref:`kdestroy(1)` fails to destroy your tickets, it will beep and 309give an error message. For example, if kdestroy can't find any 310tickets to destroy, it will give the following message:: 311 312 shell% kdestroy 313 kdestroy: No credentials cache file found while destroying cache 314 shell% 315