svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
kerberos(7)
kerberos(7) Standards, Environments, and Macros kerberos(7)
NAME
kerberos - overview of Solaris Kerberos implementation
DESCRIPTION
The Solaris Kerberos implementation, hereafter sometimes shortened to
"Kerberos," authenticates clients in a network environment, allowing
for secure transactions. (A client may be a user or a network service.)
Kerberos validates the identity of a client and the authenticity of
transferred data. Kerberos is a single-sign-on system, meaning that a
user needs to provide a password only at the beginning of a session.
The Solaris Kerberos implementation is based on the Kerberos(TM) system
developed at MIT, and is compatible with Kerberos V5 systems over het‐
erogeneous networks.
Kerberos works by granting clients tickets, which uniquely identify a
client, and which have a finite lifetime. A client possessing a ticket
is automatically validated for network services for which it is enti‐
tled; for example, a user with a valid Kerberos ticket may rlogin into
another machine running Kerberos without having to identify itself. Be‐
cause each client has a unique ticket, its identity is guaranteed.
To obtain tickets, a client must first initialize the Kerberos session,
either by using the kinit(1) command or a PAM module. (See
pam_krb5(7)). kinit prompts for a password, and then communicates with
a Key Distribution Center (KDC). The KDC returns a Ticket-Granting
Ticket (TGT) and prompts for a confirmation password. If the client
confirms the password, it can use the Ticket-Granting Ticket to obtain
tickets for specific network services. Because tickets are granted
transparently, the user need not worry about their management. Current
tickets may be viewed by using the klist(1) command.
Tickets are valid according to the system policy set up at installation
time. For example, tickets have a default lifetime for which they are
valid. A policy may further dictate that privileged tickets, such as
those belonging to root, have very short lifetimes. Policies may allow
some defaults to be overruled; for example, a client may request a
ticket with a lifetime greater or less than the default.
Tickets can be renewed using kinit. Tickets are also forwardable, al‐
lowing you to use a ticket granted on one machine on a different host.
Tickets can be destroyed by using kdestroy(1). It is a good idea to in‐
clude a call to kdestroy in your .logout file.
Under Kerberos, a client is referred to as a principal. A principal
takes the following form:
primary/instance@REALM
primary A user, a host, or a service.
instance A qualification of the primary. If the primary is a host —
indicated by the keyword host— then the instance is the
fully-qualified domain name of that host. If the primary is
a user or service, then the instance is optional. Some in‐
stances, such as admin or root, are privileged.
realm The Kerberos equivalent of a domain; in fact, in most cases
the realm is directly mapped to a DNS domain name. Kerberos
realms are given in upper-case only. For examples of prin‐
cipal names, see the EXAMPLES.
By taking advantage of the General Security Services API (GSS-API),
Kerberos offers, besides user authentication, two other types of secu‐
rity service: integrity, which authenticates the validity of transmit‐
ted data, and privacy, which encrypts transmitted data. Developers can
take advantage of the GSS-API through the use of the RPCSEC_GSS API in‐
terface (see rpcsec_gss(3C)).
EXAMPLES
Example 1 Examples of valid principal names
The following are examples of valid principal names:
joe
joe/admin
joe@ENG.EXAMPLE.COM
joe/admin@ENG.EXAMPLE.COM
rlogin/bigmachine.eng.example.com@ENG.EXAMPLE.COM
host/bigmachine.eng.example.com@ENG.EXAMPLE.COM
The first four cases are user principals. In the first two cases, it is
assumed that the user joe is in the same realm as the client, so no
realm is specified. Note that joe and joe/admin are different princi‐
pals, even if the same user uses them; joe/admin has different privi‐
leges from joe. The fifth case is a service principal, while the final
case is a host principal. The word host is required for host princi‐
pals. With host principals, the instance is the fully qualified host‐
name. Note that the words admin and host are reserved keywords.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
box; cbp-1 | cbp-1 l | l . ATTRIBUTE TYPE ATTRIBUTE VALUE = Availabil‐
ity security/kerberos-5 = Stability Pass-through committed
SEE ALSO
kdestroy(1), kinit(1), klist(1), kpasswd(1), krb5.conf(5),
krb5envvar(7)
Managing Kerberos in Oracle Solaris 11.4
NOTES
Source code for open source software components in Oracle Solaris can
be found at https://www.oracle.com/downloads/opensource/solaris-source-
code-downloads.html.
This software was built from source available at:
https://github.com/oracle/solaris-userland
The original community source was downloaded from:
http://web.mit.edu/kerberos/dist/krb5/1.20/krb5-1.20.2.tar.gz
Further information about this software can be found on the open source
community website at http://web.mit.edu/kerberos/.
Solaris 11.4 21 Jun 2021 kerberos(7)