4213 Missing spaces in man pages

          --- old/usr/src/man/man5/kerberos.5
          +++ new/usr/src/man/man5/kerberos.5

   1    1  '\" te
   2    2  .\"  Copyright (c) 2008, Sun Microsystems, Inc. All Rights Reserved
   3    3  .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License").  You may not use this file except in compliance with the License.
   4    4  .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing.  See the License for the specific language governing permissions and limitations under the License.
   5    5  .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE.  If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
   6    6  .TH KERBEROS 5 "Oct 1, 2008"
   7    7  .SH NAME
   8    8  kerberos \- overview of Solaris Kerberos implementation
   9    9  .SH DESCRIPTION
  10   10  .sp
  11   11  .LP
  12   12  The Solaris Kerberos implementation, hereafter sometimes shortened to
  13   13  "Kerberos," authenticates clients in a network environment, allowing for secure
  14   14  transactions. (A client may be a user or a network service.) Kerberos validates
  15   15  the identity of a client and the authenticity of transferred data. Kerberos is
  16   16  a \fIsingle-sign-on\fR system, meaning that a user needs to provide a password
  17   17  only at the beginning of a session. The Solaris Kerberos implementation is
  18   18  based on the Kerberos(TM) system developed at \fBMIT\fR, and is compatible with
  19   19  Kerberos V5 systems over heterogeneous networks.
  20   20  .sp
  21   21  .LP
  22   22  Kerberos works by granting clients \fItickets\fR, which uniquely identify a
  23   23  client, and which have a finite lifetime. A client possessing a ticket is
  24   24  automatically validated for network services for which it is entitled; for
  25   25  example, a user with a valid Kerberos ticket may rlogin into another machine
  26   26  running Kerberos without having to identify itself. Because each client has a
  27   27  unique ticket, its identity is guaranteed.
  28   28  .sp
  29   29  .LP
  30   30  To obtain tickets, a client must first initialize the Kerberos session, either
  31   31  by using the \fBkinit\fR(1) command or a \fBPAM\fR module. (See
  32   32  \fBpam_krb5\fR(5)). \fBkinit\fR prompts for a password, and then communicates
  33   33  with a \fIKey Distribution Center\fR (\fBKDC\fR). The \fBKDC\fR returns a
  34   34  \fITicket-Granting Ticket\fR (\fBTGT\fR) and prompts for a confirmation
  35   35  password. If the client confirms the password, it can use the Ticket-Granting
  36   36  Ticket to obtain tickets for specific network services. Because tickets are
  37   37  granted transparently, the user need not worry about their management. Current
  38   38  tickets may be viewed by using the \fBklist\fR(1) command.
  39   39  .sp
  40   40  .LP
  41   41  Tickets are valid according to the system \fIpolicy\fR set up at installation
  42   42  time. For example, tickets have a default lifetime for which they are valid. A
  43   43  policy may further dictate that privileged tickets, such as those belonging to
  44   44  root, have very short lifetimes. Policies may allow some defaults to be
  45   45  overruled; for example, a client may request a ticket with a lifetime greater
  46   46  or less than the default.
  47   47  .sp
  48   48  .LP
  49   49  Tickets can be renewed using \fBkinit\fR. Tickets are also \fIforwardable\fR,
  50   50  allowing you to use a ticket granted on one machine on a different host.
  51   51  Tickets can be destroyed by using \fBkdestroy\fR(1). It is a good idea to
  52   52  include a call to \fBkdestroy\fR in your \fB\&.logout\fR file.
  53   53  .sp
  54   54  .LP
  55   55  Under Kerberos, a client is referred to as a \fIprincipal\fR. A principal takes
  56   56  the following form:
  57   57  .sp
  58   58  .in +2
  59   59  .nf
  60   60  primary/instance@REALM
  61   61  .fi
  62   62  .in -2
  63   63  .sp
  64   64  
  65   65  .sp
  66   66  .ne 2
  67   67  .na
  68   68  \fBprimary\fR
  69   69  .ad
  70   70  .RS 12n
  71   71  A user, a host, or a service.
  72   72  .RE
  73   73  
  74   74  .sp
  75   75  .ne 2
  76   76  .na
  77   77  \fBinstance\fR
  78   78  .ad
  79   79  .RS 12n
  80   80  A qualification of the primary. If the primary is a host \(em indicated by the
  81   81  keyword \fBhost\fR\(em then the instance is the fully-qualified domain name of
  82   82  that host. If the primary is a user or service, then the instance is optional.
  83   83  Some instances, such as \fBadmin\fR or \fBroot\fR, are privileged.
  84   84  .RE
  85   85  
  86   86  .sp
  87   87  .ne 2
  88   88  .na
  89   89  \fBrealm\fR
  90   90  .ad
  91   91  .RS 12n
  92   92  The Kerberos equivalent of a domain; in fact, in most cases the realm is
  93   93  directly mapped to a \fBDNS\fR domain name. Kerberos realms are given in
  94   94  upper-case only. For examples of principal names, see the EXAMPLES.
  95   95  .RE
  96   96  
  97   97  .sp
  98   98  .LP
  99   99  By taking advantage of the General Security Services \fBAPI\fR (\fBGSS-API\fR),
 100  100  Kerberos offers, besides user authentication, two other types of security
 101  101  service: \fIintegrity\fR, which authenticates the validity of transmitted data,
 102  102  and \fIprivacy\fR, which encrypts transmitted data. Developers can take
 103  103  advantage of the \fBGSS-API\fR through the use of the RPCSEC_GSS \fBAPI\fR
 104  104  interface (see \fBrpcsec_gss\fR(3NSL)).
 105  105  .SH EXAMPLES
 106  106  .LP
 107  107  \fBExample 1 \fRExamples of valid principal names
 108  108  .sp
 109  109  .LP
 110  110  The following are examples of valid principal names:
 111  111  
 112  112  .sp
 113  113  .in +2
 114  114  .nf
 115  115          joe
 116  116          joe/admin
 117  117          joe@ENG.ACME.COM
 118  118          joe/admin@ENG.ACME.COM

 119  119          rlogin/bigmachine.eng.acme.com@ENG.ACME.COM
 120  120          host/bigmachine.eng.acme.com@ENG.ACME.COM
 121  121  .fi
 122  122  .in -2
 123  123  .sp
 124  124  
 125  125  .sp
 126  126  .LP
 127  127  The first four cases are \fIuser principals\fR. In the first two cases, it is
 128  128  assumed that the user \fBjoe\fR is in the same realm as the client, so no realm
 129      -is specified. Note that \fBjoe\fRand \fBjoe/admin\fR are different principals,
      129 +is specified. Note that \fBjoe\fR and \fBjoe/admin\fR are different principals,
 130  130  even if the same user uses them; \fBjoe/admin\fR has different privileges from
 131  131  \fBjoe\fR. The fifth case is a \fIservice principal\fR, while the final case is
 132  132  a \fIhost principal\fR. The word \fBhost\fR is required for host principals.
 133  133  With host principals, the instance is the fully qualified hostname. Note that
 134  134  the words \fBadmin\fR and \fBhost\fR are reserved keywords.
 135  135  
 136  136  .SH SEE ALSO
 137  137  .sp
 138  138  .LP
 139  139  \fBkdestroy\fR(1), \fBkinit\fR(1), \fBklist\fR(1), \fBkpasswd\fR(1),

 140  140  \fBkrb5.conf\fR(4), \fBkrb5envvar\fR(5)
 141  141  .sp
 142  142  .LP
 143  143  \fISystem Administration Guide: Security Services\fR
 144  144  .SH NOTES
 145  145  .sp
 146  146  .LP
 147  147  In previous releases of the Solaris operating system, the Solaris Kerberos
 148  148  implementation was referred to as the "Sun Enterprise Authentication Mechanism"
 149  149  (SEAM).
 150  150  .sp
 151  151  .LP
 152  152  If you enter your username and \fBkinit\fR responds with this message:
 153  153  .sp
 154  154  .in +2
 155  155  .nf
 156  156  Principal unknown (kerberos)
 157  157  .fi
 158  158  .in -2
 159  159  .sp
 160  160  
 161  161  .sp
 162  162  .LP
 163  163  you have not been registered as a Kerberos user. See your system administrator
 164  164  or the \fISystem Administration Guide: Security Services\fR.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX