diff options
Diffstat (limited to 'doc/html/_sources/user/tkt_mgmt.txt')
| -rw-r--r-- | doc/html/_sources/user/tkt_mgmt.txt | 314 |
1 files changed, 314 insertions, 0 deletions
diff --git a/doc/html/_sources/user/tkt_mgmt.txt b/doc/html/_sources/user/tkt_mgmt.txt new file mode 100644 index 000000000000..9ec7f1e7ca3e --- /dev/null +++ b/doc/html/_sources/user/tkt_mgmt.txt @@ -0,0 +1,314 @@ +Ticket management +================= + +On many systems, Kerberos is built into the login program, and you get +tickets automatically when you log in. Other programs, such as ssh, +can forward copies of your tickets to a remote host. Most of these +programs also automatically destroy your tickets when they exit. +However, MIT recommends that you explicitly destroy your Kerberos +tickets when you are through with them, just to be sure. One way to +help ensure that this happens is to add the :ref:`kdestroy(1)` command +to your .logout file. Additionally, if you are going to be away from +your machine and are concerned about an intruder using your +permissions, it is safest to either destroy all copies of your +tickets, or use a screensaver that locks the screen. + + +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 the +forwardable ticket. This allows for authentication forwarding without +requiring a password to be typed in again. For example, if a user +with a forwardable TGT logs into a remote system, the KDC could issue +a new TGT for that user with the network address of the remote system, +allowing authentication on that host to work as though the user were +logged in locally. + +When the KDC creates a new ticket based on a forwardable ticket, it +sets the **forwarded** flag on that new ticket. Any tickets that are +created based on a ticket with the forwarded flag set will also have +their forwarded flags set. + +A **proxiable** ticket is similar to a forwardable ticket in that it +allows a service to take on the identity of the client. Unlike a +forwardable ticket, however, a proxiable ticket is only issued for +specific services. In other words, a ticket-granting ticket cannot be +issued 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 the +starting time listed on the ticket, it can be presented to the KDC to +obtain valid tickets. + +Ticket-granting tickets with the **postdateable** flag set can be used +to obtain postdated service tickets. + +**Renewable** tickets can be used to obtain new session keys without +the user entering their password again. A renewable ticket has two +expiration times. The first is the time at which this particular +ticket expires. The second is the latest possible expiration time for +any ticket issued based on this renewable ticket. + +A ticket with the **initial flag** set was issued based on the +authentication protocol, and not on a ticket-granting ticket. +Application servers that wish to ensure that the user's key has been +recently presented for verification could specify that this flag must +be 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 be +validated by the KDC before they can be used. + +A **preauthenticated** ticket is one that was only issued after the +client requesting the ticket had authenticated itself to the KDC. + +The **hardware authentication** flag is set on a ticket which required +the use of hardware for authentication. The hardware is expected to +be possessed only by the client which requested the tickets. + +If a ticket has the **transit policy** checked flag set, then the KDC +that issued this ticket implements the transited-realm check policy +and checked the transited-realms list on the ticket. The +transited-realms list contains a list of all intermediate realms +between the realm of the KDC that issued the first ticket and that of +the one that issued the current ticket. If this flag is not set, then +the application server must check the transited realms itself or else +reject the ticket. + +The **okay as delegate** flag indicates that the server specified in +the ticket is suitable as a delegate as determined by the policy of +that realm. Some client applications may use this flag to decide +whether to forward tickets to a remote host, although many +applications do not honor it. + +An **anonymous** ticket is one in which the named principal is a +generic principal for that realm; it does not actually specify the +individual that will be using the ticket. This ticket is meant only +to securely distribute a session key. + + +.. _obtain_tkt: + +Obtaining tickets with kinit +---------------------------- + +If your site has integrated Kerberos V5 with the login system, you +will get Kerberos tickets automatically when you log in. Otherwise, +you may need to explicitly obtain your Kerberos tickets, using the +:ref:`kinit(1)` 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 your +password at the prompt. For example, Jennifer (whose username is +``jennifer``) works for Bleep, Inc. (a fictitious company with the +domain name mit.edu and the Kerberos realm ATHENA.MIT.EDU). She would +type:: + + shell% kinit + Password for jennifer@ATHENA.MIT.EDU: <-- [Type jennifer's password here.] + shell% + +If you type your password incorrectly, kinit will give you the +following error message:: + + shell% kinit + Password for jennifer@ATHENA.MIT.EDU: <-- [Type the wrong password here.] + kinit: Password incorrect + shell% + +and you won't get Kerberos tickets. + +By default, kinit assumes you want tickets for your own username in +your default realm. Suppose Jennifer's friend David is visiting, and +he wants to borrow a window to check his mail. David needs to get +tickets for himself in his own realm, EXAMPLE.COM. He would type:: + + shell% kinit david@EXAMPLE.COM + Password for david@EXAMPLE.COM: <-- [Type david's password here.] + shell% + +David would then have tickets which he could use to log onto his own +machine. Note that he typed his password locally on Jennifer's +machine, but it never went over the network. Kerberos on the local +host performed the authentication to the KDC in the other realm. + +If you want to be able to forward your tickets to another host, you +need to request forwardable tickets. You do this by specifying the +**-f** option:: + + shell% kinit -f + Password for jennifer@ATHENA.MIT.EDU: <-- [Type your password here.] + shell% + +Note that kinit does not tell you that it obtained forwardable +tickets; you can verify this using the :ref:`klist(1)` command (see +:ref:`view_tkt`). + +Normally, your tickets are good for your system's default ticket +lifetime, which is ten hours on many systems. You can specify a +different ticket lifetime with the **-l** option. Add the letter +**s** to the value for seconds, **m** for minutes, **h** for hours, or +**d** for days. For example, to obtain forwardable tickets for +``david@EXAMPLE.COM`` that would be good for three hours, you would +type:: + + shell% kinit -f -l 3h david@EXAMPLE.COM + Password for david@EXAMPLE.COM: <-- [Type david's password here.] + shell% + +.. note:: + + You cannot mix units; specifying a lifetime of 3h30m would + result in an error. Note also that most systems specify a + maximum ticket lifetime. If you request a longer ticket + lifetime, it will be automatically truncated to the maximum + lifetime. + + +.. _view_tkt: + +Viewing tickets with klist +-------------------------- + +The :ref:`klist(1)` command shows your tickets. When you first obtain +tickets, you will have only the ticket-granting ticket. The listing +would look like this:: + + shell% klist + Ticket cache: /tmp/krb5cc_ttypa + Default principal: jennifer@ATHENA.MIT.EDU + + Valid starting Expires Service principal + 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU + shell% + +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 ``daffodil.mit.edu``, +and then typed "klist" again, she would have gotten the following +result:: + + shell% klist + Ticket cache: /tmp/krb5cc_ttypa + Default principal: jennifer@ATHENA.MIT.EDU + + Valid starting Expires Service principal + 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU + 06/07/04 20:22:30 06/08/04 05:49:19 host/daffodil.mit.edu@ATHENA.MIT.EDU + shell% + +Here's what happened: when ``jennifer`` used ssh to connect to the +host ``daffodil.mit.edu``, the ssh program presented her +ticket-granting ticket to the KDC and requested a host ticket for the +host ``daffodil.mit.edu``. The KDC sent the host ticket, which ssh +then presented to the host ``daffodil.mit.edu``, and she was allowed +to log in without typing her password. + +Suppose your Kerberos tickets allow you to log into a host in another +domain, such as ``trillium.example.com``, which is also in another +Kerberos realm, ``EXAMPLE.COM``. If you ssh to this host, you will +receive a ticket-granting ticket for the realm ``EXAMPLE.COM``, plus +the new host ticket for ``trillium.example.com``. klist will now +show:: + + shell% klist + Ticket cache: /tmp/krb5cc_ttypa + Default principal: jennifer@ATHENA.MIT.EDU + + Valid starting Expires Service principal + 06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU + 06/07/04 20:22:30 06/08/04 05:49:19 host/daffodil.mit.edu@ATHENA.MIT.EDU + 06/07/04 20:24:18 06/08/04 05:49:19 krbtgt/EXAMPLE.COM@ATHENA.MIT.EDU + 06/07/04 20:24:18 06/08/04 05:49:19 host/trillium.example.com@EXAMPLE.COM + shell% + +Depending on your host's and realm's configuration, you may also see a +ticket with the service principal ``host/trillium.example.com@``. If +so, this means that your host did not know what realm +trillium.example.com is in, so it asked the ``ATHENA.MIT.EDU`` KDC for +a referral. The next time you connect to ``trillium.example.com``, +the odd-looking entry will be used to avoid needing to ask for a +referral again. + +You can use the **-f** option to view the flags that apply to your +tickets. 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 *jennifer* +obtained her initial tickets (**I**), which are forwardable (**F**) +and postdated (**d**) but not yet validated (**i**):: + + shell% klist -f + Ticket cache: /tmp/krb5cc_320 + Default principal: jennifer@ATHENA.MIT.EDU + + Valid starting Expires Service principal + 31/07/05 19:06:25 31/07/05 19:16:25 krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU + Flags: FdiI + shell% + +In the following example, the user *david*'s tickets were forwarded +(**f**) to this host from another host. The tickets are reforwardable +(**F**):: + + shell% klist -f + Ticket cache: /tmp/krb5cc_p11795 + Default principal: david@EXAMPLE.COM + + Valid starting Expires Service principal + 07/31/05 11:52:29 07/31/05 21:11:23 krbtgt/EXAMPLE.COM@EXAMPLE.COM + Flags: Ff + 07/31/05 12:03:48 07/31/05 21:11:23 host/trillium.example.com@EXAMPLE.COM + Flags: Ff + shell% + + +Destroying tickets with kdestroy +-------------------------------- + +Your Kerberos tickets are proof that you are indeed yourself, and +tickets could be stolen if someone gains access to a computer where +they are stored. If this happens, the person who has them can +masquerade as you until they expire. For this reason, you should +destroy your Kerberos tickets when you are away from your computer. + +Destroying your tickets is easy. Simply type kdestroy:: + + shell% kdestroy + shell% + +If :ref:`kdestroy(1)` fails to destroy your tickets, it will beep and +give an error message. For example, if kdestroy can't find any +tickets to destroy, it will give the following message:: + + shell% kdestroy + kdestroy: No credentials cache file found while destroying cache + shell% |