From: Ben Kaduk Date: Fri, 12 Oct 2012 16:05:30 +0000 (-0400) Subject: Remove unused texinfo sources X-Git-Tag: krb5-1.11-alpha1~69 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=612d64fa15ec1efe1bdd0001b62ff1eabab64da5;p=thirdparty%2Fkrb5.git Remove unused texinfo sources Now that the users guide make rules are removed, some of the texinfo sources are not referenced from anywhere and can be safely removed. ticket: 7408 --- diff --git a/doc/glossary.texinfo b/doc/glossary.texinfo deleted file mode 100644 index d49a56a7fb..0000000000 --- a/doc/glossary.texinfo +++ /dev/null @@ -1,64 +0,0 @@ -@table @b -@item client -an entity that can obtain a ticket. This entity is usually either a -user or a host. - -@item host -a computer that can be accessed over a network. - -@item Kerberos -in Greek mythology, the three-headed dog that guards the entrance to the -underworld. In the computing world, Kerberos is a network security -package that was developed at MIT. - -@item KDC -Key Distribution Center. A machine that issues Kerberos tickets. - -@item keytab -a @b{key tab}le file containing one or more keys. A host or service -uses a @dfn{keytab} file in much the same way as a user uses his/her -password. - -@item principal -a string that names a specific entity to which a set of credentials may -be assigned. It can have an arbitrary number of components, but -generally has three: - -@table @b -@item primary -the first part of a Kerberos @i{principal}. In the case of a user, it -is the username. In the case of a service, it is the name of the -service. - -@item instance -the second part of a Kerberos @i{principal}. It gives information that -qualifies the primary. The instance may be null. In the case of a -user, the instance is often used to describe the intended use of the -corresponding credentials. In the case of a host, the instance is the -fully qualified hostname. - -@item realm -the logical network served by a single Kerberos database and a set of -Key Distribution Centers. By convention, realm names are generally all -uppercase letters, to differentiate the realm from the internet domain. -@end table - -@noindent -The typical format of a typical Kerberos principal is -primary/instance@@REALM. - -@item service -any program or computer you access over a network. Examples of services -include ``host'' (a host, @i{e.g.}, when you use @code{telnet} and -@code{rsh}), ``ftp'' (FTP), ``krbtgt'' (authentication; -cf. @i{ticket-granting ticket}), and ``pop'' (email). - -@item ticket -a temporary set of electronic credentials that verify the identity of a -client for a particular service. - -@item TGT -Ticket-Granting Ticket. A special Kerberos ticket that permits the -client to obtain additional Kerberos tickets within the same Kerberos -realm. -@end table diff --git a/doc/user-guide.texinfo b/doc/user-guide.texinfo deleted file mode 100644 index 0dafe875c7..0000000000 --- a/doc/user-guide.texinfo +++ /dev/null @@ -1,1711 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@c %**start of header -@c guide -@setfilename krb5-user.info -@settitle Kerberos V5 UNIX User's Guide -@setchapternewpage odd @c chapter begins on next odd page -@c @setchapternewpage on @c chapter begins on next page -@c @smallbook @c Format for 7" X 9.25" paper -@documentencoding UTF-8 -@c %**end of header -@copying -Copyright @copyright{} 1985-2010 by the Massachusetts Institute of Technology. -@end copying - -@paragraphindent 0 -@iftex -@parskip 6pt plus 6pt -@end iftex - -@dircategory Kerberos -@direntry -* krb5-user: (krb5-user). Kerberos V5 UNIX User's Guide -@end direntry - -@include definitions.texinfo -@set EDITION 1.0 - -@finalout @c don't print black warning boxes - -@titlepage -@title @value{PRODUCT} UNIX User's Guide -@subtitle Release: @value{RELEASE} -@subtitle Document Edition: @value{EDITION} -@subtitle Last updated: @value{UPDATED} -@author @value{COMPANY} - -@page -@vskip 0pt plus 1filll -@insertcopying -@end titlepage - -@comment node-name, next, previous, up -@node Top, Introduction, (dir), (dir) - -@ifinfo -This file describes how to use the @value{PRODUCT} client programs. - -@insertcopying -@end ifinfo - -@c The master menu is updated using emacs19's M-x texinfo-all-menus-update -@c function. Don't forget to run M-x texinfo-every-node-update after -@c you add a new section or subsection, or after you've rearranged the -@c comand before each @section or @subsection! All you need to enter -@c is: -@c -@c @section New Section Name -@c -@c M-x texinfo-every-node-update will take care of calculating the -@c node's forward and back pointers. -@c -@c --------------------------------------------------------------------- - -@menu -* Introduction:: -* Kerberos V5 Tutorial:: -* Kerberos V5 Reference:: -* Kerberos Glossary:: -* Copyright:: -@end menu - -@node Introduction, Kerberos V5 Tutorial, Top, Top -@chapter Introduction - -@ifset CYGNUS -@value{PRODUCT} is based on the Kerberos V5 authentication system -developed at MIT. -@end ifset -@ifset MIT -Kerberos V5 is an authentication system developed at MIT. -@end ifset -Kerberos is named for the three-headed watchdog from Greek mythology, -who guarded the entrance to the underworld. - -Under Kerberos, a client (generally either a user or a service) sends a -request for a ticket to the @i{Key Distribution Center} (KDC). The KDC -creates a @dfn{ticket-granting ticket} (TGT) for the client, encrypts it -using the client's password as the key, and sends the encrypted TGT back -to the client. The client then attempts to decrypt the TGT, using its -password. If the client successfully decrypts the TGT (@i{i.e.}, if the -client gave the correct password), it keeps the decrypted TGT, which -indicates proof of the client's identity. - -The TGT, which expires at a specified time, permits the client to obtain -additional tickets, which give permission for specific services. The -requesting and granting of these additional tickets is user-transparent. - -Since Kerberos negotiates authenticated, and optionally encrypted, -communications between two points anywhere on the internet, it provides -a layer of security that is not dependent on which side of a firewall -either client is on. Since studies have shown that half of the computer -security breaches in industry happen from @i{inside} firewalls, -@value{COMPANY}'s @value{PRODUCT} plays a vital role in maintaining your -network security. - -The @value{PRODUCT} package is designed to be easy to use. Most of the -commands are nearly identical to UNIX network programs you already -use. @value{PRODUCT} is a @dfn{single-sign-on} system, which means -that you have to type your password only once per session, and Kerberos -does the authenticating and encrypting transparently. - -@menu -* What is a Ticket?:: -* What is a Kerberos Principal?:: -@end menu - -@node What is a Ticket?, What is a Kerberos Principal?, Introduction, Introduction -@section What is a Ticket? - -Your Kerberos @dfn{credentials}, or ``@dfn{tickets}'', are a set of -electronic information that can be used to verify your identity. Your -Kerberos tickets may be stored in a file, or they may exist only in -memory. - -The first ticket you obtain is a @dfn{ticket-granting ticket}, which -permits you to obtain additional tickets. These additional tickets give -you permission for specific services. The requesting and granting of -these additional tickets happens transparently. - -A good analogy for the ticket-granting ticket is a three-day ski pass -that is good at four different resorts. You show the pass at whichever -resort you decide to go to (until it expires), and you receive a lift -ticket for that resort. Once you have the lift ticket, you can ski all -you want at that resort. If you go to another resort the next day, you -once again show your pass, and you get an additional lift ticket for the -new resort. The difference is that the @value{PRODUCT} programs notice -that you have the weekend ski pass, and get the lift ticket for you, so -you don't have to perform the transactions yourself. - -@node What is a Kerberos Principal?, , What is a Ticket?, Introduction -@section What is a Kerberos Principal? - -A Kerberos @dfn{principal} is a unique identity to which Kerberos can -assign tickets. Principals can have an arbitrary number of -components. Each component is separated by a component separator, -generally `/'. The last component is the realm, separated from the -rest of the principal by the realm separator, generally `@@'. If there -is no realm component in the principal, then it will be assumed that -the principal is in the default realm for the context in which it is -being used. - -Traditionally, a principal is divided into three parts: the -@dfn{primary}, the @dfn{instance}, and the @dfn{realm}. The format of -a typical Kerberos V5 principal is @code{primary/instance@@REALM}. - -@itemize @bullet -@item The @dfn{primary} is the first part of the principal. In the case -of a user, it's the same as your username. For a host, the primary is -the word @code{host}. - -@item The @dfn{instance} is an optional string that qualifies the -primary. The instance is separated from the primary by a slash -(@code{/}). In the case of a user, the instance is usually null, but a -user might also have an additional principal, with an instance called -@samp{admin}, which he/she uses to administrate a database. The -principal @code{@value{RANDOMUSER1}@@@value{PRIMARYREALM}} is completely -separate from the principal -@code{@value{RANDOMUSER1}/admin@@@value{PRIMARYREALM}}, with a separate -password, and separate permissions. In the case of a host, the instance -is the fully qualified hostname, e.g., -@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}. - -@item The @dfn{realm} is your Kerberos realm. In most cases, your -Kerberos realm is your domain name, in upper-case letters. For example, -the machine @code{@value{RANDOMHOST1}.@value{SECONDDOMAIN}} would be in -the realm @code{@value{SECONDREALM}}. -@end itemize - -@node Kerberos V5 Tutorial, Kerberos V5 Reference, Introduction, Top -@chapter Kerberos V5 Tutorial - -This tutorial is intended to familiarize you with the @value{PRODUCT} -client programs. We will represent your prompt as ``@code{shell%}''. -So an instruction to type the ``@kbd{ls}'' command would be represented as -follows: - -@need 600 -@smallexample -@group -@b{shell%} ls -@end group -@end smallexample - -In these examples, we will use sample usernames, such as -@code{@value{RANDOMUSER1}} and @code{@value{RANDOMUSER2}}, sample -hostnames, such as @code{@value{RANDOMHOST1}} and -@code{@value{RANDOMHOST2}}, and sample domain names, such as -@code{@value{PRIMARYDOMAIN}} and @code{@value{SECONDDOMAIN}}. When you -see one of these, substitute your username, hostname, or domain name -accordingly. - -@menu -* Setting Up to Use Kerberos V5:: -* Ticket Management:: -* Password Management:: -* Kerberos V5 Applications:: -@end menu - -@node Setting Up to Use Kerberos V5, Ticket Management, Kerberos V5 Tutorial, Kerberos V5 Tutorial -@section Setting Up to Use @value{PRODUCT} - -Your system administrator will have installed the @value{PRODUCT} -programs in whichever directory makes the most sense for your system. -We will use @code{@value{ROOTDIR}} throughout this guide to refer to the -top-level directory @value{PRODUCT} directory. We will therefor use -@code{@value{BINDIR}} to denote the location of the @value{PRODUCT} user -programs. In your installation, the directory name may be different, -but whatever the directory name is, you should make sure it is included -in your path. You will probably want to put it @i{ahead of} the -directories @code{/bin} and @code{/usr/bin} so you will get the -@value{PRODUCT} network programs, rather than the standard UNIX -versions, when you type their command names. - -@node Ticket Management, Password Management, Setting Up to Use Kerberos V5, Kerberos V5 Tutorial -@section 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 -@code{rsh}, @code{rcp}, @code{telnet}, and @code{rlogin}, can forward -copies of your tickets to the remote host. Most of these programs also -automatically destroy your tickets when they exit. However, -@value{COMPANY} 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 @code{kdestroy} command to -your @code{.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. - -@need 2000 -@menu -* Kerberos Ticket Properties:: -* Obtaining Tickets with kinit:: -* Viewing Your Tickets with klist:: -* Destroying Your Tickets with kdestroy:: -@end menu - -@node Kerberos Ticket Properties, Obtaining Tickets with kinit, Ticket Management, Ticket Management -@subsection Kerberos Ticket Properties - -@noindent -There are various properties that Kerberos tickets can have: - -If a ticket is @dfn{forwardable}, then the KDC can issue a new ticket with -a different network address 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 @dfn{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 @dfn{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 @dfn{proxy} ticket is one that was issued based on a proxiable ticket. - -A @dfn{postdated} ticket is issued with the @i{invalid} flag set. -After the starting time listed on the ticket, it can be presented to -the KDC to obtain valid tickets. - -Tickets with the @dfn{postdateable} flag set can be used to issue postdated -tickets. - -@dfn{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 @dfn{initial} flag set was issued based on the -authentication protocol, and not on a ticket-granting ticket. Clients -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 @dfn{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 @dfn{preauthenticated} ticket is one that was only issued after the -client requesting the ticket had authenticated itself to the KDC. - -The @dfn{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 @dfn{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 @dfn{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. A server that is acting as a delegate has been granted a -proxy or a forwarded TGT. This flag is a new addition to the -@value{PRODUCT} protocol and is not yet implemented on MIT servers. - -An @dfn{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. This is a new addition to the @value{PRODUCT} -protocol and is not yet implemented on MIT servers. - -@node Obtaining Tickets with kinit, Viewing Your Tickets with klist, Kerberos Ticket Properties, Ticket Management -@subsection Obtaining Tickets with kinit - -If your site is using the @value{PRODUCT} login program, you will get -Kerberos tickets automatically when you log in. If your site uses a -different login program, you may need to explicitly obtain your Kerberos -tickets, using the @code{kinit} program. Similarly, if your Kerberos -tickets expire, use the @code{kinit} program to obtain new ones. - -@need 1500 -To use the @code{kinit} program, simply type @kbd{kinit} and then type -your password at the prompt. For example, Jennifer (whose username is -@code{@value{RANDOMUSER1}}) works for Bleep, Inc. (a fictitious company -with the domain name @code{@value{PRIMARYDOMAIN}} and the Kerberos realm -@code{@value{PRIMARYREALM}}). She would type: - -@smallexample -@group -@b{shell%} kinit -@b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type @value{RANDOMUSER1}'s password here.]} -@b{shell%} -@end group -@end smallexample - -@need 1000 -If you type your password incorrectly, kinit will give you the following -error message: - -@smallexample -@group -@b{shell%} kinit -@b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type the wrong password here.]} -@b{kinit: Password incorrect} -@b{shell%} -@end group -@end smallexample - -@noindent and you won't get Kerberos tickets. - -@noindent Notice that @code{kinit} assumes you want tickets for your own -username in your default realm. -@need 1500 -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, @value{SECONDREALM}.@footnote{Note: the realm -@value{SECONDREALM} must be listed in your computer's Kerberos -configuration file, @code{/etc/krb5.conf}.} He would type: - -@smallexample -@group -@b{shell%} kinit @value{RANDOMUSER2}@@@value{SECONDREALM} -@b{Password for @value{RANDOMUSER2}@@@value{SECONDREALM}:} @i{<-- [Type @value{RANDOMUSER2}'s password here.]} -@b{shell%} -@end group -@end smallexample - -@noindent 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. - -@need 1000 -If you want to be able to forward your tickets to another host, you need -to request @dfn{forwardable} tickets. You do this by specifying the -@kbd{-f} option: - -@smallexample -@group -@b{shell%} kinit -f -@b{Password for @value{RANDOMUSER1}@@@value{PRIMARYREALM}:} @i{<-- [Type your password here.]} -@b{shell%} -@end group -@end smallexample - -@noindent -Note that @code{kinit} does not tell you that it obtained forwardable -tickets; you can verify this using the @code{klist} command -(@pxref{Viewing Your Tickets with klist}). - -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 @samp{-l} option. Add the letter -@samp{s} to the value for seconds, @samp{m} for minutes, @samp{h} for -hours, or @samp{d} for days. -@need 1500 -For example, to obtain forwardable tickets for -@code{@value{RANDOMUSER2}@@@value{SECONDREALM}} that would be good for -three hours, you would type: - -@smallexample -@group -@b{shell%} kinit -f -l 3h @value{RANDOMUSER2}@@@value{SECONDREALM} -@b{Password for @value{RANDOMUSER2}@@@value{SECONDREALM}:} @i{<-- [Type @value{RANDOMUSER2}'s password here.]} -@b{shell%} -@end group -@end smallexample - -@noindent -You cannot mix units; specifying a lifetime of @samp{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. - -@node Viewing Your Tickets with klist, Destroying Your Tickets with kdestroy, Obtaining Tickets with kinit, Ticket Management -@subsection Viewing Your Tickets with klist - -The @code{klist} command shows your tickets. When you first obtain -tickets, you will have only the ticket-granting ticket. (@xref{What is -a Ticket?}.) The listing would look like this: - -@smallexample -@group -@b{shell%} klist -Ticket cache: /tmp/krb5cc_ttypa -Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM} - -Valid starting Expires Service principal -06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM} -@b{shell%} -@end group -@end smallexample - -@noindent -The ticket cache is the location of your ticket file. In the above -example, this file is named @code{/tmp/krb5cc_ttypa}. The default -principal is your kerberos @dfn{principal}. (@pxref{What is a Kerberos -Principal?}) - -The ``valid starting'' and ``expires'' fields describe the period of -time during which the ticket is valid. The @dfn{service principal} -describes each ticket. The ticket-granting ticket has the primary -@code{krbtgt}, and the instance is the realm name. - -@need 2000 -Now, if @value{RANDOMUSER1} connected to the machine -@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, and then typed -@kbd{klist} again, she would have gotten the following result: - -@smallexample -@group -@b{shell%} klist -Ticket cache: /tmp/krb5cc_ttypa -Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM} - -Valid starting Expires Service principal -06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM} -06/07/04 20:22:30 06/08/04 05:49:19 host/@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}@@@value{PRIMARYREALM} -@b{shell%} -@end group -@end smallexample - -@noindent -Here's what happened: when @value{RANDOMUSER1} used telnet to connect -to the host @code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, the telnet -program presented her ticket-granting ticket to the KDC and requested a -host ticket for the host -@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}. The KDC sent the host -ticket, which telnet then presented to the host -@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, and she was allowed to -log in without typing her password. - -@need 3000 -Suppose your Kerberos tickets allow you to log into a host in another -domain, such as @code{@value{RANDOMHOST2}.@value{SECONDDOMAIN}}, which -is also in another Kerberos realm, @code{@value{SECONDREALM}}. If you -telnet to this host, you will receive a ticket-granting ticket for the -realm @code{@value{SECONDREALM}}, plus the new @code{host} ticket for -@code{@value{RANDOMHOST2}.@value{SECONDDOMAIN}}. @kbd{klist} will now -show: - -@smallexample -@group -@b{shell%} klist -Ticket cache: /tmp/krb5cc_ttypa -Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM} - -Valid starting Expires Service principal -06/07/04 19:49:21 06/08/04 05:49:19 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM} -06/07/04 20:22:30 06/08/04 05:49:19 host/@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}@@@value{PRIMARYREALM} -06/07/04 20:24:18 06/08/04 05:49:19 krbtgt/@value{SECONDREALM}@@@value{PRIMARYREALM} -06/07/04 20:24:18 06/08/04 05:49:19 host/@value{RANDOMHOST2}.@value{SECONDDOMAIN}@@@value{SECONDREALM} -@b{shell%} -@end group -@end smallexample - -You can use the @code{-f} option to view the @dfn{flags} that apply to -your tickets. The flags are: - -@table @b -@itemx F -@b{F}orwardable -@itemx f -@b{f}orwarded -@itemx P -@b{P}roxiable -@itemx p -@b{p}roxy -@itemx D -post@b{D}ateable -@itemx d -post@b{d}ated -@itemx R -@b{R}enewable -@itemx I -@b{I}nitial -@itemx i -@b{i}nvalid -@itemx H -@b{H}ardware authenticated -@itemx A -pre@b{A}uthenticated -@itemx T -@b{T}ransit policy checked -@itemx O -@b{O}kay as delegate -@itemx a -@b{a}nonymous -@end table - -@need 1500 -Here is a sample listing. In this example, the user @value{RANDOMUSER1} -obtained her initial tickets (@samp{I}), which are forwardable -(@samp{F}) and postdated (@samp{d}) but not yet validated (@samp{i}). -(@xref{kinit Reference}, for more information about postdated tickets.) - -@smallexample -@group -@b{shell%} klist -f -@b{Ticket cache: /tmp/krb5cc_320 -Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM} - -Valid starting Expires Service principal -31/07/05 19:06:25 31/07/05 19:16:25 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM} - Flags: FdiI -shell%} -@end group -@end smallexample - -@need 1500 -In the following example, the user @value{RANDOMUSER2}'s tickets were -forwarded (@samp{f}) to this host from another host. The tickets are -reforwardable (@samp{F}). - -@smallexample -@group -@b{shell%} klist -f -@b{Ticket cache: /tmp/krb5cc_p11795 -Default principal: @value{RANDOMUSER2}@@@value{SECONDREALM} - -Valid starting Expires Service principal -07/31/05 11:52:29 07/31/05 21:11:23 krbtgt/@value{SECONDREALM}@@@value{SECONDREALM} - Flags: Ff -07/31/05 12:03:48 07/31/05 21:11:23 host/@value{RANDOMHOST2}.@value{SECONDDOMAIN}@@@value{SECONDREALM} - Flags: Ff -shell%} -@end group -@end smallexample - -@node Destroying Your Tickets with kdestroy, , Viewing Your Tickets with klist, Ticket Management -@subsection Destroying Your Tickets with kdestroy - -Your Kerberos tickets are proof that you are indeed yourself, and -tickets can be stolen. 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. - -@need 1000 -Destroying your tickets is easy. Simply type @kbd{kdestroy}. - -@smallexample -@group -@b{shell%} kdestroy -@b{shell%} -@end group -@end smallexample - -@need 1500 -If @code{kdestroy} fails to destroy your tickets, it will beep and give -an error message. For example, if @code{kdestroy} can't find any -tickets to destroy, it will give the following message: - -@smallexample -@group -@b{shell%} kdestroy -@b{kdestroy: No credentials cache file found while destroying cache -shell%} -@end group -@end smallexample - -@node Password Management, Kerberos V5 Applications, Ticket Management, Kerberos V5 Tutorial -@section Password Management - -Your password is the only way Kerberos has of verifying your identity. -If someone finds out your password, that person can masquerade as -you---send email that comes from you, read, edit, or delete your files, -or log into other hosts as you---and no one will be able to tell the -difference. For this reason, it is important that you choose a good -password (@pxref{Password Advice}), and keep it secret. If you need to -give access to your account to someone else, you can do so through -Kerberos. (@xref{Granting Access to Your Account}.) You should -@i{never} tell your password to anyone, including your system -administrator, for any reason. You should change your password -frequently, particularly any time you think someone may have found out -what it is. - -@menu -* Changing Your Password:: -* Password Advice:: -* Granting Access to Your Account:: -@end menu - -@node Changing Your Password, Password Advice, Password Management, Password Management -@subsection Changing Your Password - -@need 2500 -To change your Kerberos password, use the @code{kpasswd} command. It -will ask you for your old password (to prevent someone else from walking -up to your computer when you're not there and changing your password), -and then prompt you for the new one twice. (The reason you have to type -it twice is to make sure you have typed it correctly.) For example, -user @code{@value{RANDOMUSER2}} would do the following: - -@smallexample -@group -@b{shell%} kpasswd -@b{Password for @value{RANDOMUSER2}:} @i{<- Type your old password.} -@b{Enter new password:} @i{<- Type your new password.} -@b{Enter it again:} @i{<- Type the new password again.} -@b{Password changed.} -@b{shell%} -@end group -@end smallexample - -@need 1800 -If @value{RANDOMUSER2} typed the incorrect old password, he would get -the following message: - -@smallexample -@group -@b{shell%} kpasswd -@b{Password for @value{RANDOMUSER2}:} @i{<- Type the incorrect old password.} -@b{kpasswd: Password incorrect while getting initial ticket -shell%} -@end group -@end smallexample - -@need 2500 -If you make a mistake and don't type the new password the same way -twice, @code{kpasswd} will ask you to try again: - -@smallexample -@group -@b{shell%} kpasswd -@b{Password for @value{RANDOMUSER2}:} @i{<- Type the old password.} -@b{Enter new password:} @i{<- Type the new password.} -@b{Enter it again:} @i{<- Type a different new password.} -@b{kpasswd: Password mismatch while reading password -shell%} -@end group -@end smallexample - -Once you change your password, it takes some time for the change to -propagate through the system. Depending on how your system is set up, -this might be anywhere from a few minutes to an hour or more. If you -need to get new Kerberos tickets shortly after changing your password, -try the new password. If the new password doesn't work, try again using -the old one. - -@node Password Advice, Granting Access to Your Account, Changing Your Password, Password Management -@subsection Password Advice - -Your password can include almost any character you can type (except -control keys and the ``enter'' key). A good password is one you can -remember, but that no one else can easily guess. Examples of @i{bad} -passwords are words that can be found in a dictionary, any common or -popular name, especially a famous person (or cartoon character), your -name or username in any form (@i{e.g.}, forward, backward, repeated -twice, @i{etc.}), your spouse's, child's, or pet's name, your birth -date, your social security number, and any sample password that appears -in this (or any other) manual. - -@need 2200 -@value{COMPANY} recommends that your password be at least 6 characters -long, and contain UPPER- and lower-case letters, numbers, and/or -punctuation marks. Some passwords that would be good if they weren't -listed in this manual include: - -@itemize @bullet -@item some initials, like ``GykoR-66.'' for ``Get your kicks on Route -66.'' - -@item an easy-to-pronounce nonsense word, like ``slaRooBey'' or -``krang-its'' - -@item a misspelled phrase, like ``2HotPeetzas!'' or ``ItzAGurl!!!'' -@end itemize - -@noindent Note: don't actually use any of the above passwords. They're -only meant to show you how to make up a good password. Passwords that -appear in a manual are the first ones intruders will try. - -@need 3800 -@value{PRODUCT} allows your system administrators to automatically -reject bad passwords, based on certain criteria, such as a password -dictionary or a minimum length. For example, if the user -@code{@value{RANDOMUSER1}}, who had a policy "strict" that required a -minimum of 8 characaters, chose a password that was less than 8 -characters, Kerberos would give an error message like the following: - -@smallexample -@group -@b{shell%} kpasswd -@b{Password for @value{RANDOMUSER1}:} @i{<- Type your old password here.} - -@value{RANDOMUSER1}'s password is controlled by the policy strict, which -requires a minimum of 8 characters from at least 3 classes (the five classes -are lowercase, uppercase, numbers, punctuation, and all other characters). - -@b{Enter new password:} @i{<- Type an insecure new password.} -@b{Enter it again:} @i{<- Type it again.} - -kpasswd: Password is too short while attempting to change password. -Please choose another password. - -@b{Enter new password:} @i{<- Type a good password here.} -@b{Enter it again:} @i{<- Type it again.} -@b{Password changed. -shell%} -@end group -@end smallexample - -@noindent Your system administrators can choose the message that is -displayed if you choose a bad password, so the message you see may be -different from the above example. - -@node Granting Access to Your Account, , Password Advice, Password Management -@subsection Granting Access to Your Account - -@need 1800 -If you need to give someone access to log into your account, you can do -so through Kerberos, without telling the person your password. Simply -create a file called @code{.k5login} in your home directory. This file -should contain the Kerberos principal (@xref{What is a Kerberos -Principal?}.) of each person to whom you wish to give access. Each -principal must be on a separate line. Here is a sample @code{.k5login} -file: - -@smallexample -@group -@value{RANDOMUSER1}@@@value{PRIMARYREALM} -@value{RANDOMUSER2}@@@value{SECONDREALM} -@end group -@end smallexample - -@noindent This file would allow the users @code{@value{RANDOMUSER1}} and -@code{@value{RANDOMUSER2}} to use your user ID, provided that they had -Kerberos tickets in their respective realms. If you will be logging -into other hosts across a network, you will want to include your own -Kerberos principal in your @code{.k5login} file on each of these hosts. - -@need 1000 -Using a @code{.k5login} file is much safer than giving out your -password, because: - -@itemize @bullet -@item You can take access away any time simply by removing the principal -from your @code{.k5login} file. - -@item Although the user has full access to your account on one -particular host (or set of hosts if your @code{.k5login} file is shared, -@i{e.g.}, over NFS), that user does not inherit your network privileges. - -@item Kerberos keeps a log of who obtains tickets, so a system -administrator could find out, if necessary, who was capable of using -your user ID at a particular time. -@end itemize - -One common application is to have a @code{.k5login} file in -@code{root}'s home directory, giving root access to that machine to the -Kerberos principals listed. This allows system administrators to allow -users to become root locally, or to log in remotely as @code{root}, -without their having to give out the root password, and without anyone -having to type the root password over the network. - -@node Kerberos V5 Applications, , Password Management, Kerberos V5 Tutorial -@section Kerberos V5 Applications - -@value{PRODUCT} is a @dfn{single-sign-on} system. This means that you -only have to type your password once, and the @value{PRODUCT} programs -do the authenticating (and optionally encrypting) for you. The way this -works is that Kerberos has been built into each of a suite of network -programs. For example, when you use a @value{PRODUCT} program to -connect to a remote host, the program, the KDC, and the remote host -perform a set of rapid negotiations. When these negotiations are -completed, your program has proven your identity on your behalf to the -remote host, and the remote host has granted you access, all in the -space of a few seconds. - -The @value{PRODUCT} applications are versions of existing UNIX network -programs with the Kerberos features added. - -@menu -* Overview of Additional Features:: -* telnet:: -* rlogin:: -* FTP:: -* rsh:: -* rcp:: -* ksu:: -@end menu - -@node Overview of Additional Features, telnet, Kerberos V5 Applications, Kerberos V5 Applications -@subsection Overview of Additional Features - -The @value{PRODUCT} @dfn{network programs} are those programs that -connect to another host somewhere on the internet. These programs -include @code{rlogin}, @code{telnet}, @code{ftp}, @code{rsh}, -@code{rcp}, and @code{ksu}. These programs have all of the original -features of the corresponding non-Kerberos @code{rlogin}, @code{telnet}, -@code{ftp}, @code{rsh}, @code{rcp}, and @code{su} programs, plus -additional features that transparently use your Kerberos tickets for -negotiating authentication and optional encryption with the remote host. -In most cases, all you'll notice is that you no longer have to type your -password, because Kerberos has already proven your identity. - -The @value{PRODUCT} network programs allow you the options of forwarding -your tickets to the remote host (if you obtained forwardable tickets -with the @code{kinit} program; @pxref{Obtaining Tickets with kinit}), and -encrypting data transmitted between you and the remote host. - -This section of the tutorial assumes you are familiar with the -non-Kerberos versions of these programs, and highlights the Kerberos -functions added in the @value{PRODUCT} package. - -@node telnet, rlogin, Overview of Additional Features, Kerberos V5 Applications -@subsection telnet - -The @value{PRODUCT} @code{telnet} command works exactly like the -standard UNIX telnet program, with the following Kerberos options added: - -@table @kbd -@itemx -f -forwards a copy of your tickets to the remote host. - -@itemx -F -forwards a copy of your tickets to the remote host, and marks them -re-forwardable from the remote host. - -@itemx -k @i{realm} -requests tickets for the remote host in the specified realm, instead of -determining the realm itself. - -@itemx -K -uses your tickets to authenticate to the remote host, but does not log -you in. - -@itemx -a -attempt automatic login using your tickets. @code{telnet} will assume -the same username unless you explicitly specify another. - -@itemx -x -turns on encryption. - -@end table - -@need 4000 -For example, if @code{@value{RANDOMUSER2}} wanted to use the standard -UNIX telnet to connect to the machine -@code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}, he would type: - -@smallexample -@group -@b{shell%} telnet @value{RANDOMHOST1}.@value{SECONDDOMAIN} -@b{Trying 128.0.0.5 ... -Connected to @value{RANDOMHOST1}.@value{SECONDDOMAIN}. -Escape character is '^]'. - -NetBSD/i386 (daffodil) (ttyp3) - -login:} @value{RANDOMUSER2} -@b{Password:} @i{<- @value{RANDOMUSER2} types his password here} -@b{Last login: Fri Jun 21 17:13:11 from @value{RANDOMHOST2}.@value{PRIMARYDOMAIN} -Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 - The Regents of the University of California. All rights reserved. - -NetBSD 1.1: Tue May 21 00:31:42 EDT 1996 - -Welcome to NetBSD! -shell%} -@end group -@end smallexample - -@noindent Note that the machine -@code{@value{RANDOMHOST1}.@value{SECONDDOMAIN}} asked for -@code{@value{RANDOMUSER2}}'s password. When he typed it, his password -was sent over the network unencrypted. If an intruder were watching -network traffic at the time, that intruder would know -@code{@value{RANDOMUSER2}}'s password. - -@need 4000 -If, on the other hand, @code{@value{RANDOMUSER1}} wanted to use the -@value{PRODUCT} telnet to connect to the machine -@code{@value{RANDOMHOST2}.@value{PRIMARYDOMAIN}}, she could forward a -copy of her tickets, request an encrypted session, and log on as herself -as follows: - -@smallexample -@group -@b{shell%} telnet -a -f -x @value{RANDOMHOST2}.@value{PRIMARYDOMAIN} -@b{Trying 128.0.0.5... -Connected to @value{RANDOMHOST2}.@value{PRIMARYDOMAIN}. -Escape character is '^]'. -[ Kerberos V5 accepts you as ``@value{RANDOMUSER1}@@@value{PRIMARYDOMAIN}'' ] -[ Kerberos V5 accepted forwarded credentials ] -What you type is protected by encryption. -Last login: Tue Jul 30 18:47:44 from @value{RANDOMHOST1}.@value{SECONDDOMAIN} -Athena Server (sun4) Version 9.1.11 Tue Jul 30 14:40:08 EDT 2002 - -shell%} -@end group -@end smallexample - -@noindent Note that @code{@value{RANDOMUSER1}}'s machine used Kerberos -to authenticate her to @code{@value{RANDOMHOST2}.@value{PRIMARYDOMAIN}}, -and logged her in automatically as herself. She had an encrypted -session, a copy of her tickets already waiting for her, and she never -typed her password. - -If you forwarded your Kerberos tickets, @code{telnet} automatically -destroys them when it exits. The full set of options to @value{PRODUCT} -@code{telnet} are discussed in the Reference section of this manual. -(@pxref{telnet Reference}) - -@need 2000 -@node rlogin, FTP, telnet, Kerberos V5 Applications -@subsection rlogin - -@need 1000 -The @value{PRODUCT} @code{rlogin} command works exactly like the -standard UNIX rlogin program, with the following Kerberos options added: - -@table @kbd -@itemx -f -forwards a copy of your tickets to the remote host. - -@itemx -F -forwards a copy of your tickets to the remote host, and marks them -re-forwardable from the remote host. - -@itemx -k @i{realm} -requests tickets for the remote host in the specified realm, instead of -determining the realm itself. - -@itemx -x -encrypts the input and output data streams (the username is sent unencrypted) - -@end table - -@need 3000 -For example, if @code{@value{RANDOMUSER2}} wanted to use the standard -UNIX rlogin to connect to the machine -@code{@value{RANDOMHOST1}.@value{SECONDDOMAIN}}, he would type: - -@smallexample -@group -@b{shell%} rlogin @value{RANDOMHOST1}.@value{SECONDDOMAIN} -l @value{RANDOMUSER2} -@b{Password:} @i{<- @value{RANDOMUSER2} types his password here} -@b{Last login: Fri Jun 21 10:36:32 from :0.0 -Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 - The Regents of the University of California. All rights reserved. - -NetBSD 1.1: Tue May 21 00:31:42 EDT 1996 - -Welcome to NetBSD! -shell%} -@end group -@end smallexample - -@noindent Note that the machine -@code{@value{RANDOMHOST1}.@value{SECONDDOMAIN}} asked for -@code{@value{RANDOMUSER2}}'s password. When he typed it, his password -was sent over the network unencrypted. If an intruder were watching -network traffic at the time, that intruder would know -@code{@value{RANDOMUSER2}}'s password. - -@need 4000 -If, on the other hand, @code{@value{RANDOMUSER1}} wanted to use -@value{PRODUCT} rlogin to connect to the machine -@code{@value{RANDOMHOST2}.@value{PRIMARYDOMAIN}}, she could forward a -copy of her tickets, mark them as not forwardable from the remote host, -and request an encrypted session as follows: - -@smallexample -@group -@b{shell%} rlogin @value{RANDOMHOST2}.@value{PRIMARYDOMAIN} -f -x -@b{This rlogin session is using DES encryption for all data transmissions. -Last login: Thu Jun 20 16:20:50 from @value{RANDOMHOST1} -Athena Server (sun4) Version 9.1.11 Tue Jul 30 14:40:08 EDT 2002 -shell%} -@end group -@end smallexample - -@noindent Note that @code{@value{RANDOMUSER1}}'s machine used Kerberos -to authenticate her to @code{@value{RANDOMHOST2}.@value{PRIMARYDOMAIN}}, -and logged her in automatically as herself. She had an encrypted -session, a copy of her tickets were waiting for her, and she never typed -her password. - -If you forwarded your Kerberos tickets, @code{rlogin} automatically -destroys them when it exits. The full set of options to @value{PRODUCT} -@code{rlogin} are discussed in the Reference section of this manual. -(@pxref{rlogin Reference}) - -@node FTP, rsh, rlogin, Kerberos V5 Applications -@subsection FTP - -@need 1000 -The @value{PRODUCT} @code{FTP} program works exactly like the standard -UNIX FTP program, with the following Kerberos features added: - -@table @kbd -@itemx -k @i{realm} -requests tickets for the remote host in the specified realm, instead of -determining the realm itself. - -@itemx -f -requests that your tickets be forwarded to the remote host. The -@kbd{-f} argument must be the last argument on the command line. - -@itemx protect @i{level} -(issued at the @code{ftp>} prompt) sets the protection level. ``Clear'' -is no protection; ``safe'' ensures data integrity by verifying the -checksum, and ``private'' encrypts the data. Encryption also ensures -data integrity. -@end table - -@need 5000 -For example, suppose @code{@value{RANDOMUSER1}} wants to get her -@code{RMAIL} file from the directory @code{~@value{RANDOMUSER1}/Mail}, -on the host @code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}}. She wants -to encrypt the file transfer. The exchange would look like the -following: - -@smallexample -@group -@b{shell%} ftp @value{RANDOMHOST1}.@value{PRIMARYDOMAIN} -Connected to @value{RANDOMHOST1}.@value{PRIMARYDOMAIN}. -220 @value{RANDOMHOST1}.@value{PRIMARYDOMAIN} FTP server (Version 5.60) ready. -334 Using authentication type GSSAPI; ADAT must follow -GSSAPI accepted as authentication type -GSSAPI authentication succeeded -200 Data channel protection level set to private. -Name (@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}:@value{RANDOMUSER1}): -232 GSSAPI user @value{RANDOMUSER1}@@@value{PRIMARYREALM} is authorized as @value{RANDOMUSER1} -230 User @value{RANDOMUSER1} logged in. -Remote system type is UNIX. -Using binary mode to transfer files. -ftp> protect private -200 Protection level set to Private. -ftp> cd ~@value{RANDOMUSER1}/MAIL -250 CWD command successful. -ftp> get RMAIL -227 Entering Passive Mode (128,0,0,5,16,49) -150 Opening BINARY mode data connection for RMAIL (361662 bytes). -226 Transfer complete. -361662 bytes received in 2.5 seconds (1.4e+02 Kbytes/s) -ftp> quit -@b{shell%} -@end group -@end smallexample - -The full set of options to @value{PRODUCT} @code{FTP} are discussed -in the Reference section of this manual. (@pxref{FTP Reference}) - -@node rsh, rcp, FTP, Kerberos V5 Applications -@subsection rsh - -The @value{PRODUCT} @code{rsh} program works exactly like the standard -UNIX rlogin program, with the following Kerberos features added: - -@table @kbd -@itemx -f -forwards a copy of your tickets to the remote host. - -@itemx -F -forwards a copy of your tickets to the remote host, and marks them -re-forwardable from the remote host. - -@itemx -k @i{realm} -requests tickets for the remote host in the specified realm, instead of -determining the realm itself. - -@itemx -x -encrypts the input and output data streams (the command line is not encrypted) - -@end table - -@need 1800 -For example, if your Kerberos tickets allowed you to run programs on the -host @* @code{@value{RANDOMHOST2}@@@value{SECONDDOMAIN}} as root, you could -run the @samp{date} program as follows: - -@smallexample -@group -@b{shell%} rsh @value{RANDOMHOST2}.@value{SECONDDOMAIN} -l root -x date -@b{This rsh session is using DES encryption for all data transmissions. -Tue Jul 30 19:34:21 EDT 2002 -shell%} -@end group -@end smallexample - -If you forwarded your Kerberos tickets, @code{rsh} automatically -destroys them when it exits. The full set of options to @value{PRODUCT} -@code{rsh} are discussed in the Reference section of this manual. -(@pxref{rsh Reference}) - -@node rcp, ksu, rsh, Kerberos V5 Applications -@subsection rcp - -@need 1000 -The @value{PRODUCT} @code{rcp} program works exactly like the standard -UNIX rcp program, with the following Kerberos features added: - -@table @kbd -@itemx -k @i{realm} -requests tickets for the remote host in the specified realm, instead of -determining the realm itself. - -@itemx -x -turns on encryption. -@end table - - -@need 1500 -For example, if you wanted to copy the file @code{/etc/motd} from the -host @code{@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}} into the current -directory, via an encrypted connection, you would simply type: - -@smallexample -@b{shell%} rcp -x @value{RANDOMHOST1}.@value{PRIMARYDOMAIN}:/etc/motd . -@end smallexample - -The @kbd{rcp} program negotiates authentication and encryption -transparently. The full set of options to @value{PRODUCT} @code{rcp} -are discussed in the Reference section of this manual. (@pxref{rcp -Reference}) - -@node ksu, , rcp, Kerberos V5 Applications -@subsection ksu - -The @value{PRODUCT} @code{ksu} program replaces the standard UNIX su -program. @code{ksu} first authenticates you to Kerberos. Depending on -the configuration of your system, @code{ksu} may ask for your Kerberos -password if authentication fails. @emph{Note that you should never type -your password if you are remotely logged in using an unencrypted -connection.} - -Once @code{ksu} has authenticated you, if your Kerberos principal -appears in the target's @code{.k5login} file (@pxref{Granting Access to -Your Account}) or in the target's @code{.k5users} file (see below), it -switches your user ID to the target user ID. - -@need 2000 -For example, @code{@value{RANDOMUSER2}} has put -@code{@value{RANDOMUSER1}}'s Kerberos principal in his @code{.k5login} -file. If @code{@value{RANDOMUSER1}} uses @code{ksu} to become -@code{@value{RANDOMUSER2}}, the exchange would look like this. (To -differentiate between the two shells, @code{@value{RANDOMUSER1}}'s -prompt is represented as @code{@value{RANDOMUSER1}%} and -@code{@value{RANDOMUSER2}}'s prompt is represented as -@code{@value{RANDOMUSER2}%}.) - -@smallexample -@group -@b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2} -@b{Account @value{RANDOMUSER2}: authorization for @value{RANDOMUSER1}@@@value{PRIMARYREALM} successful -Changing uid to @value{RANDOMUSER2} (3382) -@value{RANDOMUSER2}%} -@end group -@end smallexample - -@noindent -Note that the new shell has a copy of @code{@value{RANDOMUSER1}}'s -tickets. The ticket filename contains @code{@value{RANDOMUSER2}}'s UID -with @samp{.1} appended to it: - -@smallexample -@group -@b{@value{RANDOMUSER2}%} klist -@b{Ticket cache: /tmp/krb5cc_3382.1 -Default principal: @value{RANDOMUSER1}@@@value{PRIMARYREALM} - -Valid starting Expires Service principal -07/31/04 21:53:01 08/01/04 07:52:53 krbtgt/@value{PRIMARYREALM}@@@value{PRIMARYREALM} -07/31/04 21:53:39 08/01/04 07:52:53 host/@value{RANDOMHOST1}.@value{PRIMARYDOMAIN}@@@value{PRIMARYREALM} -@value{RANDOMUSER2}%} -@end group -@end smallexample - -@need 2500 -If @code{@value{RANDOMUSER1}} had not appeared in -@code{@value{RANDOMUSER2}}'s @code{.k5login} file (and the system was -configured to ask for a password), the exchange would have looked like -this (assuming @code{@value{RANDOMUSER2}} has taken appropriate -precautions in protecting his password): - -@smallexample -@group -@b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2} -@b{WARNING: Your password may be exposed if you enter it here and are logged - in remotely using an unsecure (non-encrypted) channel. -Kerberos password for @value{RANDOMUSER2}@@@value{PRIMARYREALM}:} @i{<- @code{@value{RANDOMUSER1}} types the wrong password here.} -@b{ksu: Password incorrect -Authentication failed. -@value{RANDOMUSER1}%} -@end group -@end smallexample - -Now, suppose @code{@value{RANDOMUSER2}} did not want to give -@code{@value{RANDOMUSER1}} full access to his account, but wanted to -give her permission to list his files and use the "more" command to view -them. He could create a @code{.k5users} file giving her permission to -run only those specific commands. - -@need 3500 -The @code{.k5users} file is like the @code{.k5login} file, except that -each principal is optionally followed by a list of commands. @code{ksu} -will let those principals execute only the commands listed, using the -@kbd{-e} option. @code{@value{RANDOMUSER2}}'s @code{.k5users} file -might look like the following: - -@smallexample -@group -@value{RANDOMUSER1}@@@value{PRIMARYREALM} /bin/ls /usr/bin/more -@value{ADMINUSER}@@@value{PRIMARYREALM} /bin/ls -@value{ADMINUSER}/admin@@@value{PRIMARYREALM} * -@value{RANDOMUSER2}@@@value{SECONDREALM} -@end group -@end smallexample - -@noindent The above @code{.k5users} file would let -@code{@value{RANDOMUSER1}} run only the commands @code{/bin/ls} and -@code{/usr/bin/more}. It would let @code{@value{ADMINUSER}} run only -the command @code{/bin/ls} if he had regular tickets, but if he had -tickets for his @code{admin} instance, -@code{@value{ADMINUSER}/admin@@@value{PRIMARYREALM}}, he would be able -to execute any command. The last line gives @code{@value{RANDOMUSER2}} -in the realm @value{SECONDREALM} permission to execute any command. -(@i{I.e.}, having only a Kerberos principal on a line is equivalent to -giving that principal permission to execute @code{*}.) This is so that -@value{RANDOMUSER2} can allow himself to execute commands when he logs -in, using Kerberos, from a machine in the realm @value{SECONDREALM}. - -@need 2500 -Then, when @code{@value{RANDOMUSER1}} wanted to list his home directory, -she would type: - -@smallexample -@group -@b{@value{RANDOMUSER1}%} ksu @value{RANDOMUSER2} -e ls ~@value{RANDOMUSER2} -@b{Authenticated @value{RANDOMUSER1}@@@value{PRIMARYREALM} -Account @value{RANDOMUSER2}: authorization for @value{RANDOMUSER1}@@@value{PRIMARYREALM} for execution of - /bin/ls successful -Changing uid to @value{RANDOMUSER2} (3382) -Mail News Personal misc bin -@value{RANDOMUSER1}%} -@end group -@end smallexample - -@noindent If @code{@value{RANDOMUSER1}} had tried to give a different -command to @code{ksu}, it would have prompted for a password as with the -previous example. - -Note that unless the @code{.k5users} file gives the target permission to -run any command, the user must use @code{ksu} with the @kbd{-e} -@i{command} option. - -@need 1000 -The @code{ksu} options you are most likely to use are: - -@table @kbd -@itemx -n @i{principal} -specifies which Kerberos principal you want to use for @code{ksu}. -(@i{e.g.}, the user @code{@value{ADMINUSER}} might want to use his -@code{admin} instance. @xref{What is a Ticket?}.) - -@itemx -c -specifies the location of your Kerberos credentials cache (ticket file). - -@itemx -k -tells @code{ksu} not to destroy your Kerberos tickets when @code{ksu} is -finished. - -@itemx -f -requests forwardable tickets. (@xref{Obtaining Tickets with kinit}.) This -is only applicable if @code{ksu} needs to obtain tickets. - -@itemx -l @i{lifetime} -sets the ticket lifetime. (@xref{Obtaining Tickets with kinit}.) This is -only applicable if @code{ksu} needs to obtain tickets. - -@itemx -z -tells @code{ksu} to copy your Kerberos tickets only if the UID you are -switching is the same as the Kerberos primary (either yours or the one -specified by the @kbd{-n} option). - -@itemx -Z -tells @code{ksu} not to copy any Kerberos tickets to the new UID. - -@itemx -e @i{command} -tells @code{ksu} to execute @i{command} and then exit. See the -description of the @code{.k5users} file above. - -@itemx -a @i{text} -(at the end of the command line) tells @code{ksu} to pass everything -after @samp{-a} to the target shell. -@end table - -The full set of options to @value{PRODUCT} @code{ksu} are discussed -in the Reference section of this manual. (@pxref{ksu Reference}) - -@node Kerberos V5 Reference, Kerberos Glossary, Kerberos V5 Tutorial, Top -@chapter Kerberos V5 Reference - -This section will include copies of the manual pages for the -@value{PRODUCT} client programs. You can read the manual entry for any -command by typing @code{man} @i{command}, where @i{command} is the name -of the command for which you want to read the manual entry. For -example, to read the @code{kinit} manual entry, you would type: - -@smallexample -@b{shell%} man kinit -@end smallexample - -Note: To be able to view the @value{PRODUCT} manual pages on line, you -may need to add the directory @code{@value{ROOTDIR}/man} to your MANPATH -environment variable. (Remember to replace @code{@value{ROOTDIR}} with -the top-level directory in which @value{PRODUCT} is installed.) For -example, if you had the the following line in your @code{.login} -file@footnote{The MANPATH variable may be specified in a different -initialization file, depending on your operating system. Some of the -files in which you might specify environment variables include -@code{.login}, @code{.profile}, or @code{.cshrc}.}: - -@smallexample -setenv MANPATH /usr/local/man:/usr/man -@end smallexample - -@noindent -and the @value{PRODUCT} man pages were in the directory -@code{/usr/@value{LCPRODUCT}/man}, you would change the line to the following: - -@smallexample -setenv MANPATH /usr/@value{LCPRODUCT}/man:/usr/local/man:/usr/man -@end smallexample - -@ifinfo -Note to info users: the manual pages are not available within this info -tree. You can read them from emacs with the command: - -@smallexample -M-x manual-entry @emph{command} -@end smallexample -@end ifinfo - -@page - -@menu -* kinit Reference:: -* klist Reference:: -* ksu Reference:: -* kdestroy Reference:: -* kpasswd Reference:: -* telnet Reference:: -* FTP Reference:: -* rlogin Reference:: -* rsh Reference:: -* rcp Reference:: -@end menu - -@node kinit Reference, klist Reference, Kerberos V5 Reference, Kerberos V5 Reference -@section kinit Reference - -@iftex -@special{psfile=kinit1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{kinit}} -@page - -@special{psfile=kinit2.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{kinit}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry kinit} to read this manual page. -@end ifinfo - -@ifhtml -@html - kinit manpage -@end html -@end ifhtml - -@node klist Reference, ksu Reference, kinit Reference, Kerberos V5 Reference -@section klist Reference - -@iftex -@special{psfile=klist1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{klist}} -@page -@end iftex - -@iftex -@special{psfile=klist2.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{klist}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry klist} to read this manual page. -@end ifinfo - -@ifhtml -@html - klist manpage -@end html -@end ifhtml - -@node ksu Reference, kdestroy Reference, klist Reference, Kerberos V5 Reference -@section ksu Reference - -@iftex -@special{psfile=ksu1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{ksu}} -@page - -@special{psfile=ksu2.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{ksu}} -@page - -@special{psfile=ksu3.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{ksu}} -@page - -@special{psfile=ksu4.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{ksu}} -@page - -@special{psfile=ksu5.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{ksu}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry ksu} to read this manual page. -@end ifinfo - -@ifhtml -@html - ksu manpage -@end html -@end ifhtml - -@node kdestroy Reference, kpasswd Reference, ksu Reference, Kerberos V5 Reference -@section kdestroy Reference - -@iftex -@special{psfile=kdestroy1.ps voffset=-700 hoffset=-60} -@centerline{Reference Manual for @code{kdestroy}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry kdestroy} to read this manual page. -@end ifinfo - -@ifhtml -@html - kdestroy manpage -@end html -@end ifhtml - -@node kpasswd Reference, telnet Reference, kdestroy Reference, Kerberos V5 Reference -@section kpasswd Reference - -@iftex -@special{psfile=kpasswd1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{kpasswd}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry kpasswd} to read this manual page. -@end ifinfo - -@ifhtml -@html - kpasswd manpage -@end html -@end ifhtml - -@node telnet Reference, FTP Reference, kpasswd Reference, Kerberos V5 Reference -@section telnet Reference - -@iftex -@special{psfile=telnet1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page - -@special{psfile=telnet2.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page - -@special{psfile=telnet3.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page - -@special{psfile=telnet4.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page - -@special{psfile=telnet5.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page - -@special{psfile=telnet6.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page - -@special{psfile=telnet7.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page - -@special{psfile=telnet8.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page - -@special{psfile=telnet9.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{telnet}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry telnet} to read this manual page. -@end ifinfo - -@ifhtml -@html - telnet manpage -@end html -@end ifhtml - -@node FTP Reference, rlogin Reference, telnet Reference, Kerberos V5 Reference -@section FTP Reference - -@iftex -@special{psfile=ftp1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page - -@special{psfile=ftp2.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page - -@special{psfile=ftp3.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page - -@special{psfile=ftp4.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page - -@special{psfile=ftp5.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page - -@special{psfile=ftp6.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page - -@special{psfile=ftp7.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page - -@special{psfile=ftp8.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page - -@special{psfile=ftp9.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{FTP}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry FTP} to read this manual page. -@end ifinfo - -@ifhtml -@html - ftp manpage -@end html -@end ifhtml - -@node rlogin Reference, rsh Reference, FTP Reference, Kerberos V5 Reference -@section rlogin Reference - -@iftex -@special{psfile=rlogin1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{rlogin}} -@page - -@special{psfile=rlogin2.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{rlogin}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry rlogin} to read this manual page. -@end ifinfo - -@ifhtml -@html - rlogin manpage -@end html -@end ifhtml - -@node rsh Reference, rcp Reference, rlogin Reference, Kerberos V5 Reference -@section rsh Reference - -@iftex -@special{psfile=rsh1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{rsh}} -@page - -@special{psfile=rsh2.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{rsh}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry rsh} to read this manual page. -@end ifinfo - -@ifhtml -@html - rsh manpage -@end html -@end ifhtml - -@node rcp Reference, , rsh Reference, Kerberos V5 Reference -@section rcp Reference - -@iftex -@special{psfile=rcp1.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{rcp}} -@page -@end iftex - -@iftex -@special{psfile=rcp2.ps voffset=-700 hoffset=-40} -@centerline{Reference Manual for @code{rcp}} -@page -@end iftex - -@ifinfo -Type @kbd{M-x manual-entry rcp} to read this manual page. -@end ifinfo - -@ifhtml -@html - rcp manpage -@end html -@end ifhtml - -@node Kerberos Glossary, Copyright, Kerberos V5 Reference, Top -@appendix Kerberos Glossary - -@include glossary.texinfo - -@node Copyright, , Kerberos Glossary, Top -@appendix Copyright - -@include copyright.texinfo - -@contents -@bye