1 '\" te
   2 .\"  Copyright (c) 2008, Sun Microsystems, Inc. All Rights Reserved
   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 .\" 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 .\" 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 .TH KERBEROS 5 "Oct 1, 2008"
   7 .SH NAME
   8 kerberos \- overview of Solaris Kerberos implementation
   9 .SH DESCRIPTION
  10 .sp
  11 .LP
  12 The Solaris Kerberos implementation, hereafter sometimes shortened to
  13 "Kerberos," authenticates clients in a network environment, allowing for secure
  14 transactions. (A client may be a user or a network service.) Kerberos validates
  15 the identity of a client and the authenticity of transferred data. Kerberos is
  16 a \fIsingle-sign-on\fR system, meaning that a user needs to provide a password
  17 only at the beginning of a session. The Solaris Kerberos implementation is
  18 based on the Kerberos(TM) system developed at \fBMIT\fR, and is compatible with
  19 Kerberos V5 systems over heterogeneous networks.
  20 .sp
  21 .LP
  22 Kerberos works by granting clients \fItickets\fR, which uniquely identify a
  23 client, and which have a finite lifetime. A client possessing a ticket is
  24 automatically validated for network services for which it is entitled; for
  25 example, a user with a valid Kerberos ticket may rlogin into another machine
  26 running Kerberos without having to identify itself. Because each client has a
  27 unique ticket, its identity is guaranteed.
  28 .sp
  29 .LP
  30 To obtain tickets, a client must first initialize the Kerberos session, either
  31 by using the \fBkinit\fR(1) command or a \fBPAM\fR module. (See
  32 \fBpam_krb5\fR(5)). \fBkinit\fR prompts for a password, and then communicates
  33 with a \fIKey Distribution Center\fR (\fBKDC\fR). The \fBKDC\fR returns a
  34 \fITicket-Granting Ticket\fR (\fBTGT\fR) and prompts for a confirmation
  35 password. If the client confirms the password, it can use the Ticket-Granting
  36 Ticket to obtain tickets for specific network services. Because tickets are
  37 granted transparently, the user need not worry about their management. Current
  38 tickets may be viewed by using the \fBklist\fR(1) command.
  39 .sp
  40 .LP
  41 Tickets are valid according to the system \fIpolicy\fR set up at installation
  42 time. For example, tickets have a default lifetime for which they are valid. A
  43 policy may further dictate that privileged tickets, such as those belonging to
  44 root, have very short lifetimes. Policies may allow some defaults to be
  45 overruled; for example, a client may request a ticket with a lifetime greater
  46 or less than the default.
  47 .sp
  48 .LP
  49 Tickets can be renewed using \fBkinit\fR. Tickets are also \fIforwardable\fR,
  50 allowing you to use a ticket granted on one machine on a different host.
  51 Tickets can be destroyed by using \fBkdestroy\fR(1). It is a good idea to
  52 include a call to \fBkdestroy\fR in your \fB\&.logout\fR file.
  53 .sp
  54 .LP
  55 Under Kerberos, a client is referred to as a \fIprincipal\fR. A principal takes
  56 the following form:
  57 .sp
  58 .in +2
  59 .nf
  60 primary/instance@REALM
  61 .fi
  62 .in -2
  63 .sp
  64 
  65 .sp
  66 .ne 2
  67 .na
  68 \fBprimary\fR
  69 .ad
  70 .RS 12n
  71 A user, a host, or a service.
  72 .RE
  73 
  74 .sp
  75 .ne 2
  76 .na
  77 \fBinstance\fR
  78 .ad
  79 .RS 12n
  80 A qualification of the primary. If the primary is a host \(em indicated by the
  81 keyword \fBhost\fR\(em then the instance is the fully-qualified domain name of
  82 that host. If the primary is a user or service, then the instance is optional.
  83 Some instances, such as \fBadmin\fR or \fBroot\fR, are privileged.
  84 .RE
  85 
  86 .sp
  87 .ne 2
  88 .na
  89 \fBrealm\fR
  90 .ad
  91 .RS 12n
  92 The Kerberos equivalent of a domain; in fact, in most cases the realm is
  93 directly mapped to a \fBDNS\fR domain name. Kerberos realms are given in
  94 upper-case only. For examples of principal names, see the EXAMPLES.
  95 .RE
  96 
  97 .sp
  98 .LP
  99 By taking advantage of the General Security Services \fBAPI\fR (\fBGSS-API\fR),
 100 Kerberos offers, besides user authentication, two other types of security
 101 service: \fIintegrity\fR, which authenticates the validity of transmitted data,
 102 and \fIprivacy\fR, which encrypts transmitted data. Developers can take
 103 advantage of the \fBGSS-API\fR through the use of the RPCSEC_GSS \fBAPI\fR
 104 interface (see \fBrpcsec_gss\fR(3NSL)).
 105 .SH EXAMPLES
 106 .LP
 107 \fBExample 1 \fRExamples of valid principal names
 108 .sp
 109 .LP
 110 The following are examples of valid principal names:
 111 
 112 .sp
 113 .in +2
 114 .nf
 115         joe
 116         joe/admin
 117         joe@ENG.ACME.COM
 118         joe/admin@ENG.ACME.COM
 119         rlogin/bigmachine.eng.acme.com@ENG.ACME.COM
 120         host/bigmachine.eng.acme.com@ENG.ACME.COM
 121 .fi
 122 .in -2
 123 .sp
 124 
 125 .sp
 126 .LP
 127 The first four cases are \fIuser principals\fR. In the first two cases, it is
 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,
 130 even if the same user uses them; \fBjoe/admin\fR has different privileges from
 131 \fBjoe\fR. The fifth case is a \fIservice principal\fR, while the final case is
 132 a \fIhost principal\fR. The word \fBhost\fR is required for host principals.
 133 With host principals, the instance is the fully qualified hostname. Note that
 134 the words \fBadmin\fR and \fBhost\fR are reserved keywords.
 135 
 136 .SH SEE ALSO
 137 .sp
 138 .LP
 139 \fBkdestroy\fR(1), \fBkinit\fR(1), \fBklist\fR(1), \fBkpasswd\fR(1),
 140 \fBkrb5.conf\fR(4), \fBkrb5envvar\fR(5)
 141 .sp
 142 .LP
 143 \fISystem Administration Guide: Security Services\fR
 144 .SH NOTES
 145 .sp
 146 .LP
 147 In previous releases of the Solaris operating system, the Solaris Kerberos
 148 implementation was referred to as the "Sun Enterprise Authentication Mechanism"
 149 (SEAM).
 150 .sp
 151 .LP
 152 If you enter your username and \fBkinit\fR responds with this message:
 153 .sp
 154 .in +2
 155 .nf
 156 Principal unknown (kerberos)
 157 .fi
 158 .in -2
 159 .sp
 160 
 161 .sp
 162 .LP
 163 you have not been registered as a Kerberos user. See your system administrator
 164 or the \fISystem Administration Guide: Security Services\fR.