share/man/man5/kerberos.5

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